5 ms·

> First of all, Rust's 'fearless concurrency' largely boils down to 'no concurrency' - Rust has about as much concurrency as Javascript - you can copy objects b

> First of all, Rust's 'fearless concurrency' largely boils down to 'no concurrency' - Rust has about as much concurrency as Javascript - you can copy objects between threads, but not share memory beyond that ...this is just blatantly false? Like it is false to the extent that I am confused as to what you could even possibly be talking about - I don't know how anyone who has actually written non-trivial programs in both languages could come to the conclusion that they have the same memory model (or much of anything in common when it comes to threads, really).

torginus 1y ago
Everything but the most rudimentary threading architectures in Rust programs basically mean that you have to design your whole program around it - annotating everything with Send and Sync, which might be sometimes impossible or impractical because you don't control the modified code, using Arc<> etc. In practice Rust doesn't make concurrency easier - it forces extremely conservative architectures or basically constantly copying everything between threads (hence my example of Js workers). Sure it's safe, but it's the nanny kind of safety, where you are basically disallowed to do something remotely challenging or interesting, instead of the bungee cord kind of safety where the framework allows you to go crazy and if you obey a few simple rules you can make sure your code will still work. People who do not work on nuclear reactors don't seek out this kind of safety by themselves - it is forced on them. The other funny thing about the Rust memory model is that it kind of assumes an environment where there's a malloc/free function pair which is stateless and global, and every allocation needs to be freed. This is absolutely not the case in low-level code, with memory pools, arenas etc. In these cases Rust either enforces unnecessary restrictions or can't really keep track of the lifetime of objects. Rust is seriously undercooked.
- vacuity 1y ago
  I could argue on technical aspects, but firstly, how do you square what you're saying with Rust code used in production codebases? Do they not do multithreading, or shared memory, or complex allocation patterns? Sure, Rust is not a silver bullet (nothing is), and it has many pain points, but the picture you're presenting is entirely incongruous with the reality of programs written in Rust.
- filleduchaos 1y ago
  Ah, I see. So by "you can copy objects between threads, but not share memory beyond that" you actually meant "you can obviously share memory beyond copying objects between threads using primitives and constructs that the language gives you but I find them bad for vaguely specified reasons so I don't want to use them and this is somehow the same thing as 'you cannot share memory beyond that'". This is of course not disingenuous in the slightest (especially the part where you bring up "using Arc", i.e. the equivalent of e.g. C++'s shared_ptr, as an example of the sort of "extremely conservative architecture" you are forced to use when writing multithreaded Rust). Anyone who deems it so is obviously just a Rust fanatic, probably. I assume mutexes are also a Rust invention to make concurrency difficult. I've never quite understood the complaints about "the nanny kind of safety", either. To put it very bluntly, they just come across to me as wanting to be nannied. I am supposed to entertain the concept of a developer so competent with ideas so clever that the rules of safe Rust simply cannot express them, and yet so nervous and unsure of their own brilliance that they cannot just...write out their case in unsafe Rust and move on. It's as if people want to be smarter than the compiler and yet also never actually have to demonstrate that they are, and it just doesn't make sense.
  - torginus 1y ago
    That's a rather mean spirited interpretation of my comment and I debated whether to respond to it, but I guess here goes: In general Rust claims to provide you with a set of safety rules that are a more comprehensive extension of C++ unique_ptr and co. so you can do write the same code, have like 10% more mental overhead because of additional safety, but in exchange you can fearlessly do anything, and know your program doesn't have memory leaks or race conditions. However that's not how it works in practice. Rust rejects all non-trivial naive multi-threaded programs. There's a zero percent chance that you can map a non-trivial C++ program to Rust without major rewrites, even though said program is 100% safe from aliasing bugs. How multi-threading actually works in Rust: You copy everything between threads, or try to adapt every structure that needs to be threaded with Sync, Send, Arc etc. Not very efficient use of ones time. Or you rely on one of the threading libraries/frameworks which makes certain styles of parallelism easier to express. These libraries usually contain giant blobs of unsafe Rust, which isn't exactly a win for the language. The TLDR version of my post is Rust still rejects a significant percentage of non-trivial but correct programs. If we were anal about it and cared about the soundness of the language, and disallowed libraries with unsafe, that number would jump even higher.

torginus 1y ago

Everything but the most rudimentary threading architectures in Rust programs basically mean that you have to design your whole program around it - annotating everything with Send and Sync, which might be sometimes impossible or impractical because you don't control the modified code, using Arc<> etc. In practice Rust doesn't make concurrency easier - it forces extremely conservative architectures or basically constantly copying everything between threads (hence my example of Js workers). Sure it's safe, but it's the nanny kind of safety, where you are basically disallowed to do something remotely challenging or interesting, instead of the bungee cord kind of safety where the framework allows you to go crazy and if you obey a few simple rules you can make sure your code will still work. People who do not work on nuclear reactors don't seek out this kind of safety by themselves - it is forced on them. The other funny thing about the Rust memory model is that it kind of assumes an environment where there's a malloc/free function pair which is stateless and global, and every allocation needs to be freed. This is absolutely not the case in low-level code, with memory pools, arenas etc. In these cases Rust either enforces unnecessary restrictions or can't really keep track of the lifetime of objects. Rust is seriously undercooked.

vacuity 1y ago
I could argue on technical aspects, but firstly, how do you square what you're saying with Rust code used in production codebases? Do they not do multithreading, or shared memory, or complex allocation patterns? Sure, Rust is not a silver bullet (nothing is), and it has many pain points, but the picture you're presenting is entirely incongruous with the reality of programs written in Rust.
filleduchaos 1y ago
Ah, I see. So by "you can copy objects between threads, but not share memory beyond that" you actually meant "you can obviously share memory beyond copying objects between threads using primitives and constructs that the language gives you but I find them bad for vaguely specified reasons so I don't want to use them and this is somehow the same thing as 'you cannot share memory beyond that'". This is of course not disingenuous in the slightest (especially the part where you bring up "using Arc", i.e. the equivalent of e.g. C++'s shared_ptr, as an example of the sort of "extremely conservative architecture" you are forced to use when writing multithreaded Rust). Anyone who deems it so is obviously just a Rust fanatic, probably. I assume mutexes are also a Rust invention to make concurrency difficult. I've never quite understood the complaints about "the nanny kind of safety", either. To put it very bluntly, they just come across to me as wanting to be nannied. I am supposed to entertain the concept of a developer so competent with ideas so clever that the rules of safe Rust simply cannot express them, and yet so nervous and unsure of their own brilliance that they cannot just...write out their case in unsafe Rust and move on. It's as if people want to be smarter than the compiler and yet also never actually have to demonstrate that they are, and it just doesn't make sense.
- torginus 1y ago
  That's a rather mean spirited interpretation of my comment and I debated whether to respond to it, but I guess here goes: In general Rust claims to provide you with a set of safety rules that are a more comprehensive extension of C++ unique_ptr and co. so you can do write the same code, have like 10% more mental overhead because of additional safety, but in exchange you can fearlessly do anything, and know your program doesn't have memory leaks or race conditions. However that's not how it works in practice. Rust rejects all non-trivial naive multi-threaded programs. There's a zero percent chance that you can map a non-trivial C++ program to Rust without major rewrites, even though said program is 100% safe from aliasing bugs. How multi-threading actually works in Rust: You copy everything between threads, or try to adapt every structure that needs to be threaded with Sync, Send, Arc etc. Not very efficient use of ones time. Or you rely on one of the threading libraries/frameworks which makes certain styles of parallelism easier to express. These libraries usually contain giant blobs of unsafe Rust, which isn't exactly a win for the language. The TLDR version of my post is Rust still rejects a significant percentage of non-trivial but correct programs. If we were anal about it and cared about the soundness of the language, and disallowed libraries with unsafe, that number would jump even higher.