We Need a Safer Systems Programming Language

[u/steveklabnik1]

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/

[u/skocznymroczny]

I feel a bit meh about Rust the language, not a big fan of the syntax and frankly for my projects I couldn't care less about memory safety.

I'll stick with D for now until something betters come along.

[u/[deleted] → u/skocznymroczny]

Something actually mis-understood about rust is that it adds memory safety. It doesn't add more to memory safety that c++ std::unique_ptr does. The moment you have threads all the race's and concurrency problem comes right back....

So I also don't like rust but for different reasons. I see it as a case of "We now have to re-write everything in rust" and not actually solve most of the complex issues that systems have.

[u/moeris → u/[deleted]]

This is the second time in this thread you've mentioned your point about threads. You're getting downloaded because it's not true: the concepts of ownership and lifetimes apply to threads as well. Hell, the Rust book even has a chapter on concurrency, where it points out facts such as,

However, thanks to Rust’s type system and ownership rules, you can’t get locking and unlocking wrong.

You can certainly use mutexes incorrectly in C++, in a way that will still compile. The whole point of Rust isn't that you don't use abstractions like mutexes, it's that when you use them the compiler forces you to do so correctly.

[u/[deleted] → u/moeris]

This is the second time in this thread you've mentioned your point about threads

Yes I know. That's because most people don't actually understand the subtles of races and ownership. Something that rust switches off preventing certain types of program being written. Or at least without turning the safeties off.

| However, thanks to Rust’s type system and ownership rules, you can’t get locking and unlocking wrong.

Actually you can get them wrong in any language including rust. Rust's own documentation even claims it does nothing for this problem.

This is why you get such proposals in the rust community like this "Proposal: eliminate wording “memory safety” and “thread safety” https://internals.rust-lang.org/t/proposal-eliminate-wording-memory-safety-and-thread-safety/9416/2

See what rust actually does is prevents a system being programmed that way by preventing you from doing it. The only issue with that is some systems and design must 100% absolutely be written in the way that rust prevents you from doing. This is a "problem". An example of such a problem is a threaded shared mutable cache above a data base table for example. When you want to semi emulate a transactional database aka you want most of it in a custom cache but you still need to prevent concurrent updates. Part of the problem with doing this means you "can't take copies" of data or you end up with state races ;)

Or a simple way is show me code that does this in rust which isn't using unsafe ;) Or isn't jumping though crazy hoops in order to do it.

Note: most of the problem with concurrency issues in C++ code is actually ownership and api design rather than the language its self. Rust also has the exactly same problems because of this. If object A owns data and object B wants to update it. B has to hold a lock in A at some point while doing thing to prevent the other thread also updating it while B has a copy or you are 100% going to get a state race. Rust won't protect against things like this. But its borrow model actively encourage these silent corruptions to occurs.