[downerending]

Rust is interesting and clever, but it will not see widespread use, for pretty much the same reason that Haskell won't: It's simply too complex for Joe Coder to deal with.

C++ is likewise quite complex, but it has the huge advantage that a team of mediocre programmers can largely just keep to a simple subset of the language and bumble along. With Rust, you must learn and deal with the memory model, and it's not an easy thing.

[heavenlyblue]

There’s nothing complex about Rust memory model

[wolf550e]

I think the conclusion is that C++ is too dangerous in the hands of non-experts.

[downerending]

As far as it goes, I agree, and I rarely recommend C++ as the right language for a project.

Nonetheless, on real-world projects, a team of average programmers can make reasonable headway in C++. They'll probably write a lot of dubious and buggy code and eventually slam into the complexity wall. In Rust, they'd slam into a wall almost immediately and very noticeably. Managers won't put up with that.

[pasabagi]

I've never really dug into C++, but I've written a little bit of C, and I feel it's generally easier to write a given program in Rust than it is in C.

I can see why Rust has its reputation for difficulty - the burrow checker is a new idea, and the unfamiliar is inherently dificult. However, I think once you've spend a modicum of time, it's a fairly straightforward language, simply because the compiler almost always tells you exactly what you're doing wrong.

I don't feel like it's a particularly ergonomic language, and it's certainly hard to read (very symbol dense), but I think it's easier to learn to appease the burrow checker than it is to debug your average C program, especially if you're the sort of person (I certainly am) that produces dubious and buggy code more days than not.

[downerending]

That may be, but debugging "looks like work" in the eyes of mgmt.

The borrow checker, on the other hand, looks more like "I can't find any applicants in Little Rock who can do this stuff.".

[pasabagi]

On the other hand, I think the most important thing in making developers replaceable is the degree to which the codebase explicitly contains all the information relevant to it.

Lifetimes are an additional, important piece of information that would have previously been something a programmer would have to have an intuition for, or that would need to be put in documentation.

Now, that work is delegated to the compiler, and so, your individual developer is somewhat more fungible.

I don't know if rust is specifically the future in this regard, but I think if I was a machivellian manager, I'd be interested in replacing instances of human intuition and group knowledge with tooling, as much as possible. The burrow checker is one such tool - even if automatic garbage collection is probably a more straightforward one.