We may disagree on the premise that humans are generally incapable of correct and safe manual memory management, but that's a degree of distrust I hold for myself. You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.

If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management. You wouldn't put a person who has a track record of crashing busses at the wheel of a school bus.

And Rust isn't the only memory-safe language. You can turn to Java, Go, C#, Type/JavaScript, and whole bunch of others. Rust just so happens to have ocaml tendencies and other things that make it a joy to read and write, so that's definitely preference on my part. One of these days I'll learn ocaml and possibly drop Rust :)

However, I also don't understand how people don't see the usefulness of what Rust put to the mainstream: algebraic data types, sum types, traits, etc.

I also get super annoyed when people think Rust is only chosen for "safety". Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.

Honestly, in general, I am just annoyed when people don't use the right tool for the right job. And attempts to fix the tool with more bespoke stuff on top it.

I find my experience with Erlang has helped with the (considerable) learning curve for Rust, but I still prefer Go for most use-cases.

But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.

C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)

Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).

I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.

80% of memory safety bugs in C++ are just basically "array out of bounds", for which you don't need a memory checker at all just array bounds checks which LLVM has enabled by default for Rust but you can also use it for C++.

70% of vulns in C++ are memory related but only ~10% of those would be caught by borrow checking. Most are already caught by forcing object initialisation and array bounds checking. Only use-after-free is caught by either borrow checking OR OTHER TOOLS like ARM has 4 bits in addresses that can encode if the memory location has not been pulled from under you.

So aaaaall this trouble if the borrow checker to have in some cases max 10% fewer vulnos.

I'm not going to switch to Rust/PHP just for that little memory safety bonus.

> refuse to admit there are alternatives to RAII

I'm even more curious about this. Can the author or anybody else explain what this means specifically? Can anybody list those alternatives other than GC and RC?

PS: Computer Science isn't exactly my primary professional competence.

It will be a shame if new programmers will stay away from C because of all the scaremongering regarding the consequences of not freeing some memory (in some toy, pet project) in their own computers.

The same is true for programming languages. When you have eliminated all the others for their fatal flaws, only Rust remains, so it's not "just a tool", it's the best tool (or less worse, depending on how you like the syntax).

You can read more about the technical reasons here: https://kerkour.com/rust-software-engineering-reliability

> give the same smug lectures about "safety"

I'm often confused reading articles like this, which take for granted the existence of some "rust evangelism strike force" which goes after people on the internet for not liking rust enough.

The way people talk, it sounds like there's some insanely effective marketing campaign going on to promote rust everywhere. But I haven't seen it. Certainly not any more than any other technology people get excited about for awhile, like Go. Or docker when that launched.

Where are these comments? Can anyone give some actual links to these sort of comments people say online, which don't get immediately downvoted? The way people talk, these comments must be made in such large volumes that it seems very odd I don't notice them?

Why is it better to accept harm from bad tools, especially since we are the ones harmed by those preferences?

The IDE capabilities are not nearly as advanced as they are for Java for example.

Compared to C/C++ or dynamically typed languages, sure.

I love that cargo unifies the ecosystem, no quabble over one shitty build tool over another.

I feel like the IDE story still has a long way to go.

Yea, I get smug judgement from Rust zealots for not picking the in vogue crates.

I get a lot of help too though.

People are passionate about it. That has good and bad outcomes.

In the past I had the impression that some thought that Rust was the first programming language to ever have the concept.

Some people get their egoes attached to their choices (for or against Rust).

Also there's a time and a place for all criticism. If the conversation is not fundamentally about language choice then it's very irritating to have it brought up.

In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.

There are also competent C++ programmers who misunderstand or don't know how static checking works.

I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.

"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.

C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.

Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself. Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.

Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.

Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.

Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.

We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.

At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.

Also trying to fight runtime behavior with compile time constraints cannot be a universal treatment. Trying to enforce OOP is one of such examples, and it already failed .

tl;dr: Just a tool, but "we shape our tools and then our tools shape us".

Its a good language dont get me wrong, but also a huge pita to work with.