[imron]

Sure, they end up looking similar, but the point is that with C++ the developer carries the burden of making sure everything is correct and doesn't prevent you or other developers from breaking outside the bounds of what is "good" - either on purpose, or accidentally, e.g. when refactoring.

With Rust, the burden of checking all of that is shifted to the compiler, and that reduces cognitive load for the developer.

[pjmlp]

While Rust is a big help regarding memory corruption errors, you still need to watch out for the remaining 30%.

[imron]

Rust is not a panacea for all bugs, but making memory problems and data races a compile time problem rather than a runtime problem is a significant benefit.

[pjmlp]

Indeed, and if that is what makes the industry rediscover Ada and Modula-2, more the better, however care need to be taken how it is sold, and also be understood this is going to take several decades.

Anyone that cares about memory safety for userspace applications has already moved on into other languages, the problem is the foundation and those that resist no matter what.

Also the data races prevented by Rust type system only apply to multihreaded code accessing in-memory data structures, there plenty of other data races in multiprocessing scenarios.

[imron]

Your “only” clause captures the entire definition of data race - compared to the broader category of race conditions [0]

Safe rust prevents data races at compile time. It doesn’t prevent other race conditions.

And “only” preventing data races, is still a non-trivial achievement!

0: https://blog.regehr.org/archives/490

[pjmlp]

No need for the exclamation point.

Yes it is a non-trivial achievement, just I get the feeling that the advocacy for it tends to forget about the other ones.

By the way, John Regehr's example won't work if the transferXXX functions are using SQL statements without transactions across threads each with its own connection, instead of in-memory variables.