This argument that rust is complicated is really tiring and laughable in the face of c++'s complexity.
Rust has the biggest concession to newcomers I have ever seen offered, it will not let you compile code that contains many commonly encountered show stopping confusing as sin errors...
The person claiming this, is in the same breath claiming that a book written by experts is not worth reading. Assuming ncmncm is an expert at c++: How confusing does a language have to become for that to even happen?
Yes there are several third party package managers, which is a pretty good smell that the situation is sticky at best. Out of the three my favorite is NuGET. Unfortunately the ecosystem last I checked anyway was weaker than say rusts' or go's(at the risk of comparing apples to oranges). Python also has multiple package managers, and the worst part of python when used appropriately is it's package managers and logical layout...
Most modern programming languages have one package manager dedicated to the language, and for good reason imo.
Part of the problem is, the c++ culture is kind of like the c culture, most people would rather write their own packages from scratch then leverage a community. I don't blame the languages, they were around before git was common.
I feel like I am bashing c++... I don't mean too, it's a great language and it does have good packages(some I prefer over what is available in say Rust), but most projects I've seen not using visual c++ do the 1990s thing and don't use these tools. Maybe it's their age, never looked hard at "why", being honest.
I think what's hard for people to realize is, people who like rust usually aren't saying "is rust going to replace it"? Like cheesey blogs by hype artists say crap like that, but really having both is obviously beneficial to the programming community.
Depending on what that business software is doing I wouldn't be surprised in a few hundred thousand lines were written in something else. Microsoft (https://medium.com/@tinocaer/how-microsoft-is-adopting-rust-...), etc, are all doing this right now. But yea if you are writing low velocity, non mission critical software, no need to bother. On the other hand, there may come a point in time where that c++ project gets a boost by factoring the critical parts out of it into a safe language...
In a lot of cases I would consider a staged rewrite. Ie, I would turn what I could into dylibs going either from rust to c++ or c++ to rust. Assuming the code has structure and isn't infinite singletons and free standing functions this can make more or less sense. I'd translate the parts with the most likelihood for memory safety or thread safety issues first, so the transition could be part of the release cycle.
It would still be a lot of work, but you might see benefits at intermediate releases this way.
You are right it does not gaurantee correctness. Libraries can also provide unsafe or incorrect code. C++ lacks a package manager and a community mindset. So I trust c++ library's less than many modern programming languages...
Rust makes it so you can do this yourself for most things. It's not always convenient but it's the best I've seen so far.
I'm interested to see how automatic formal verification of rust code is going. Super interesting area, think a team at AWS is working on it, and a few other groups.
That's actually a motivating reason for why people and companys tend to like Rust . many people transition to rust because c++ has become very bloated, complex, and the rules for what happens in the language can be more complicated than x86 assembly...
Rust requires you to write correct code. And no, lots of people using modern C++ do struggle with safety, and specifically memory safety. That's why these new languages exist, and exactly why they are gaining users every single day. No matter what someone on hacker news says...
This doesn't mean c or c++ are bad or something. But, yea...
You really can become productive in safe languages. It does take some practice, but it makes you a better programmer. Someone might turn the table and claim they are more productive in memory safe languages because when they hit production they can actually pivot to new projects rather then put out concurrency/parallelism fires.
I've talked with people in the rust community about modern c++ being similar to rust. They all agreed and honestly thought it was cool. Maybe 1 out of 50 rust programmers language bash and are ignorant, those people tend to be junior and are trying to learn. Everyone else is cool.
That said rust is pretty different from c++. Most people don't compare rust to c because c is so heinously unsafe and rust being the polar opposite. Ironically, rust was indoctrinated as the second supported language to the Linux kernel, alongside C. So they have that in common...
I wouldn't make too many assumptions about the rust community, they are pretty nice smart reasonable people who tend to write c/c++ for work...
Outside of the happy path doesn't mean, inaccessible or uncommonly used. C++ is on track to be a composition of ten languages by 2030. I'm not against that in general, it's kind of liberating, but at some point in time I hope someone does decide to do some house keeping.
I mean I get what you are saying about how old stuff doesn't have adoption issues. But, rust is a pretty unique paradigm. The safety guarantees it offers aren't found in other languages without garbage collectors.
Rust is boring and technical. Boring in the "it just works and when it doesn't it's not hard to figure out why" way. You didn't say this, but for others passing by, it would be a mistake to view rust as a "shiny thing". People use it for a reason, barring syntax entirely.
Rust has the biggest concession to newcomers I have ever seen offered, it will not let you compile code that contains many commonly encountered show stopping confusing as sin errors...
The person claiming this, is in the same breath claiming that a book written by experts is not worth reading. Assuming ncmncm is an expert at c++: How confusing does a language have to become for that to even happen?