> It's just ugly and looks like design by committee.

I don't think it's ugly because it's design-by-committee, I think they intentionally made it ugly so that it's familiar to C++ people.

> I also wonder why corporations are pushing Rust.

You said it yourself: undisciplined people can't write C without introducing memory-related bugs, and it's much easier to hire undisciplined people than disciplined people.

> It is an entirely different story if a project is started with sanitizers, Valgrind and best practices.

Do you have an example of a project that is (a) built in such a way, (b) large, and (c) has a good track record on memory safety?

C programmers like to talk about discipline, but no human is more disciplined than a compiler.

Most surveys place the use of static analysis tools at about 11%, and they all go back to early 80's.

Some people are hard learners.

I think it's simply the power of defaults. If it takes an extra step then a lot of people wont do it.

> The evangelism is exhausting.

My best guess is that people who are "stuck" working in C or C++ wish they could use Rust at their Jobs.

Or that others would make the leap and get over the learning curve.

Not until it reaches the same level as Visual Studio, Android Studio, QtCreator, XCode, CUDA and SYSCL tooling for graphical applications and GPGPU.

For anything else managed languages are a much more productive option, other than writing kernel and drivers.

We get that you don't like rust. But it seems like a lot of people currently using C or C++ while like to use rust at work, and might disagree about the benefits of the language and tooling. I personally know a few friends in distinct domains who work on established C++ codebases and are in this situation.

There are also a lot of people who do not use C or C++, but use a bit of rust because it's so much easier to write fast little tools with it. I'm in this category. I even use threads sometimes, and it's reasonably easy. A crop of new unixy tools in rust seems to indicate other people also think alike.

Quite on the contrary, Rust is the ideal language to replace C and C++ where automaric memory option is a no go, like MISRA-C, kernel and device drivers.

Liking a programing language doesn't make me blind to what use cases it actually makes sense to use it, I don't see nails everywhere.

I agree.

I think you'll find that most rational advocates for any language agree that their favorite language is only strong in its subdomain.

Any compiled language is more painful than a quick scripting one for quick projects where the project complexity is low and the language overhead doesn't matter.

Rust is substantially more painful to get compiling (due to the borrow checker) and harder to debug (due to tool maturity) than C# or C++. It's much harder to use than Python. Every language has its place.

But when you are investing the time to make an efficient, high performance program... or you have limited requirements like you said -- Rust becomes a great choice.

Every langauge has its place. I'm just dreadfully excited that we have a new choice now to trade a bit more time interacting with compiler errors for high performance and stability -- when that makes sense.

Have you ever had to deal with tail latency due to memory pressure on web or backend services?

Command-line tools are also ideal for Rust because startup performance matters a lot there.

Yes, writing distributed systems since 1999.

What was done in C, C++ and Tcl, I nowadays use Java and .NET languages.

If we really need something low level that either Java or .NET cannot offer, a native library for a specific component will do, no need to throw the whole thing away and do one of those rewrite blog posts.

Tail latency due to memory pressure tends to be inherent to the nature of garbage collected languages with mutable state. This is not an issue if you have more RAM then the system needs, but often RAM is extremely scarce.

Garbage collected languages also offer means to do C like memory allocation, it is matter to use the language features and FFI capabilities, but many just learn their stacks superficially and follow Rewrite in X trendy blog posts instead.

There is a very big difference between what particular environments offer in theory (yes, you can write object pools in Java and many high-performance projects use them) and the situation in practice (there are people who spend a large chunk of their professional careers doing JVM tuning).

Idiomatic Rust avoids the situations which require JVM tuning experts. You can write a Rust service, put it into production and tail latency is very likely not going to be a problem at all.

Now you may decide that needing the occasional services of a JVM tuning expert is better overall than ownership concerns being pervasive throughout a codebase, depending on the specifics. But do accept that the trade-off exists.

Only when speaking about kernel code, drivers, and similar scenarios.

You are the one focusing in Java, and in your answer proved exactly my point of knowing stacks superficially.

Object pools aren't the only way to reduce memory footprint in Java.

A bit of FFI into host OS syscalls and it is done, or a tiny high performance native library for a custom data structures and ready for the races.

No need to throw away 25 years of tooling and libraries.

Then we can move into languages that offer exactly the same features as C++, like D, Nim, Swift, Eiffel, Ada.

I've written three of those sorts of native libraries before, and it's just awfully inconvenient compared to just using Rust to be honest.

C evangelism is exhausting too. Maybe we can stick to discussing the merits of each language instead of complaining about how people with differing opinions make us feel.

Actually I never see any occasion that a C guys jump into a well establish project and ask them to rewrite that in C.

And TBH I rarely see other popular language did the similar things either, including very popular ones like python, Java or Go.

And you even observe there is thing called "C evangelism" actually exists?

Yeah? Check out any very public discussion of Rust and to a first approxiation there's always gonna be someone talking about how we should all just be using C instead. It's also not hard to find instances in open source projects of people ascribing ulterior motives or brain damage or ineptitude or whatever to anyone using another programming language.

They don't call it C-lioning for nothing :^)

A tool that requires "discipline" from its users is strictly worse than a tool that doesn't.

I want to be able to write code without having to be "disciplined" about how I access memory. Means I can be more "disciplined" about business logic.

> It is an entirely different story if a project is started with sanitizers, Valgrind and best practices.

What are the agreed upon tools and best practices in the C community as of right now?

> I also wonder why corporations are pushing Rust.

Recruiting.