> whereas I am sure a C/C++ large project of a similar size wouldn't run out of memory

This is a common issue on large C++ projects for users with limited resources. You typically have to tinker with build settings and use a different linker etc.. to get the project building without OOMing.

> A lot of the tooling reminds me of NPM

My feeling is that you'd have the same criticism about a lot of other modern ecosystems because they allow you to pull dependencies easily. With things like vcpkg, that's also possible in C++ but even without it: nothing stops the same behavior of importing "random" code from the internet.

To be fair, you haven't explained why it's an issue to see projects being rewritten in Rust, other than it is a bit annoying to you?

For me, I had a very good experience rewriting a project in Rust (from Python). It was just an improvement in every regard (the project was easier to build and distribute, it was a good opportunity to rearchitect it, and the code ended up 20k times faster.) So, I have the opposite feeling when I see titles like these.

I also feel the opposite about the tooling. For me, cmake, npm, pip, maven, etc. all live in this realm where any invocation could become a time purgatory. The big thing that makes me like Rust is that I've never had that experience with cargo. (In fact, pip was the primary motivation to move away from Python to Rust. Everything else was just nice.)

I'm not saying this to convince you to feel otherwise, I just wanted to offer how I felt about the same topics. I grew up with C and Java, but Rust clicked after I read SICP and followed along in Racket. I could probably fill a page of small grievances about Rust's syntax if I had to.

> A lot of the tooling reminds me of NPM, and after spending a huge amount of my time fighting with NPM, I actually prefer the way C/C++/CMake handles stuff.

I guess you and me live different lives because I have spent far more time messing with ancient C/C++/CMake/Automake/Autoconf/configure/just have this particular .so file in this particular spot/copy some guys entire machine because this project only builds there/learn and entirely different language just to write build files (CMake sucks and 5 other alternatives are just lipstick on a pig) etc. etc.

I am of the opinion that half of Rusts success is based on that fact that C/C++'s tooling is annoying and ancient. People want to write code not mess with build envs.

Sure. That doesn't matter. Of course you can keep writing your C/C++ or using CMake, nobody is going to stop that. But other people's project are not going to stop adopt new tech stack because how you feel about it.

RE: memory, any self-respecting CI/CD system will allow you to compile any Rust project without out-of-memory halts.

RE: NPM, you have a right to a preference of course. I certainly don't miss the times 20 years ago when pulling in a library into a C++ project was a two-week project in itself. make and CMake work perfect right up until they don't and the last 2% cost you 98% of the time. Strategically speaking, using make/CMake is simply unjustified risk. But this is of course always written off as "skill issue!" which I gave up arguing against because the arguers apparently have never hit the dark corners. I have. I am better with Just and Cargo. And Elixir's mix / hex.

What you like as a language (or syntax) and what you roll your eyes at are obviously not technological or merit-based arguments. "Weird" I can't quite place as an argument either.

Use what you like. We all do the same. The original article lists good arguments in favor of Rust. Seems like a good case of "use the right tool for the job" to me.