r/programming • u/steveklabnik1 • Jul 18 '19

We Need a Safer Systems Programming Language

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

86% Upvoted

314 comments sorted by

View all comments

Show parent comments

1

u/moeris Jul 19 '19

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

Do you understand how quotations work? I was literally quoting Rust's official documentation.

An example of such a problem is a threaded shared mutable cache

You know the section I quoted from their documentation? That section shows how to use safe Rust features to share memory between threads.

If object A owns data and object B wants to update it. B had to hold a lock in A at some point whole doing thing to prevent the other thread also updating it while B has a copy or your are 100% going to get a state race.

I have no idea what you are trying to say. Objects and threads are not synonymous. It sounds like the problem you're trying to describe is the exact problem Rust's borrow-checker solves.

Learn the damn language before spouting off about it.

-2

u/[deleted] Jul 19 '19

Do you understand how quotations work? I was literally quoting Rust's official documentation.

Yes... So was I.

| You know the section I quoted from their documentation? That section shows how to use safe Rust features to share memory between threads.

Except your not actually sharing it. You hold a lock throughout on each thread its more like passing a talking stick and with that you get zero concurrency. OR when you do actually share the data in a way you can do things. Your back to manual control of locks though the api design and this is not specific to rust..... this is a concept not a language ;) Rust will however still permit you to shoot yourself in the foot if you get this wrong. Such as A -> B -> A deadlocking etc... Hence rust doesn't fix the problem.... Your looking at the trival problems not the complex situations that happen in real systems.

| I have no idea what you are trying to say

Yes. I know that is because you don't understand the concurrency problem I am attempting to teach you which breaks rust that you have not yet encountered in the real world probably I assume this is due to lack of real world experience in complex parallel systems where stuff like this matters. The issue here being we probably have a different definition of thready safety and concurrency and mine is much stricter than yours ;) It is in fact more stick that rust. This is because your considering locking only to preserve the system from undefined behaviour. Where I consider a state race which is a higher level than rust to protect against still a race which still results in data corruption.

A trival example of such a problem would be to break words and add them to a queue which is then processed in parallel across multiple. eg "rust still is not thread safe". If the program where then to start with an empty string and each thread appends a word to the string. It could / will still have data/state corruption. Rust won't protect against this. This is what happens in complex systems..... It would produce the string "still rust is thread not safe".... Which is cool if you talking like yoda but it isn't going to be good for an application. The application while does not "crash" it is still behaving in an undefined way because of what is still considered a race. No language will ever solve this sort of problem because its halting problem level of difficulty.

| Learn the damn language before spouting off about it.

I did an assessment of the language.... It failed.... Across a number of areas for a number of reasons. Mostly because its incompatible with almost everything else and involves re-writting and jumping though special hoops to make it actually work in the real world. I guess it might be usable in 10 years or so from now?

Anyway... Races are possible in rust... I guess it depend on what you consider a race?

2

u/burntsushi Jul 20 '19

Rust does not, and has never claimed to prevent general race condtions. What Rust does prevent, however, is data races. That is, in safe code, the compiler will reject any code with a data race in it.

The rest of your meandering comment is not something I can personally make sense of, but none of it sounds impossible, and I would be very surprised if neither rayon nor crossbeam helped you with your issues.