Did you make it to the end of that section you linked? It's pretty clear on Rust having significant advantages here still:

"This, of course, does not eliminate all possible bugs (misuse is still possible, and often not checkable in a language like C++)—so, this idea is often paired in newer languages with heavier (and more complex) compile-time checking features, which attempt to both automate this code generation, and prohibit misuse."

I feel like most discussions touching on Rust revolve around the same lines - one person says they don’t want to use Rust (for whatever reason), a proponent starts regurgitating the selling points, the former feels misunderstood (because that all has been heard many times before), the latter snubs at taking the former as being stubborn.

I’ve been through my Rust hype phase, and I’ve been through thoughtfully applying it for web services and a greenfield messaging broker, albeit nothing systems level. With a decade or so C++ behind the belt, I don’t feel an app team is necessarily more productive over the lifecycle of the project if they pick Rust over C++, much less so if they pick it over Java.

I’ve been doing mostly low-latency JVM projects. I can extract better performance from a JVM and a given infrastructure than from Rust. Ease of development and the option to delegate the lifetimes to the GC, or just get a huge heap, is often the escape hatch you need to make through the tight deadline.

In Rust, you need just one “smart” colleague to make the project unmaintainable - wasting everyone’s time on optimizing the type signatures making it thereby impenetrable to anyone outside the team, or easy to forget the derivation a few months later on.

There was a nice suggestion on HN somewhere to distinguish between an area beneficial particularly to Rust (slow pace, settled architecture, more low-level) as opposed to the area with fewer fruits to reap for Rust where other semantics prevails.

Good points, the JVM is absolutely underrated these days imo and Rust won't always be a strictly better choice especially for established teams. From what I see though a lot of this repetitive back-and-forth starts with somebody saying that they personally prefer Rust or simply describing its advantages over other languages from their perspective, and every time there's backlash from people responding as if the author were trying to personally force them into using Rust in their own projects.

I think it's great that you can build solid projects efficiently in C++ or Java! People should be free to choose whatever works best for them; as someone who does love Rust I'm of course happy to see it gaining traction, but if the flavor of the month were to suddenly change I don't think I'd feel the need to go out of my way trying to tear the new thing down.

The real argument from that piece is that heap allocation is something to be avoided, and there are alternatives to malloc/free pairs. There are other benefits, but specifically having the compiler insert lots of frees is not one of them, for developers that prefer arena memory management for efficiency, simplicity, organization, and cache behavior.

In fact, there are lots of arena/bump allocator crates! It's not a negative point for Rust, but it solves a problem this author doesn't have.