[bfrog]

I've worked on large C++ projects. Debugging hard to find data corruption, data leaks, data races was one of the most frustrating aspect. In a 200kloc project with 10 devs, there was always a crash worthy bug. Always. Automated tests could only catch so many things. Often the crash made it to the end user, causing them to lose valuable work and time. It sucked.

By far though some of the worst issues were ones involving heap fragmentation because of all the damn heap loving C++ classes and shared_ptr wrappers.

Rust doesn't solve everything. But it solves the most time consuming parts of C++ for me. Debugging. I've yet to need a debugger for Rust, after 5 years writing many 10s of thousands of lines of it. I trust the random crate I pull in won't segfault on something asanine if it stays away from unwarranted unsafe usage.

It's a breath of fresh air to not need a GC, be able to trust most other code won't cause a crash, and that once it compiles it's most likely going to work barring any logic bugs. It saves me immense amounts of time, and mostly avoids debugging hard issues in production. Mostly.

While people sit in their debuggers adding watch points, stepping through some 3rd party lib to figure out a crash, I'm busy working on the next killer feature.

[carlmr]

I completely agree with you, I'm programming in C++ in my job and I've dabbled in Rust a bit. The issues in C++ are 90% ones that you wouldn't have in Rust

However my reply to the higher up comment was because you can't switch every project away from C++. I think it's a good idea to start most projects where you would have picked C++ in Rust now, just that it's infeasible for a lot of code, given the mountains of code that exist in C++.

Also plenty of code needs certifications that just don't exist for Rust yet.

So saying C++ is an anti-pattern is kind of correct, but it doesn't help you if you have to deal with it.