6 ms·

Everything but the most rudimentary threading architectures in Rust programs basically mean that you have to design your whole program around it - annotating ev

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.
  - vacuity 1y ago
    You're exaggerating heavily, which undermines your claims. While Rust claims to allow fearless concurrency, there is plenty of official documentation to show that the limitations are acknowledged. Anyone telling you Rust prevents memory leaks and race conditions is lying, straight up, and this is trivial to verify. You shouldn't be repeating it. Your comments on Send/Sync and unsafe are similarly exaggerated. I have to say, you must be interacting with Rust zealots beyond what I've ever seen, if this is truly your belief.
    - torginus 1y ago
      ?? Now I have to come to the defense of Rust - it does prevent memory leaks (but not space leaks where you leak memory, but it's all being referenced from somewhere). The borrow checker should also prevent race conditions (as not doing so would violate the aliasing rule) This is all provided we stay in safe Rust land, and don't do concurrency or call external APIs, but that's not a claim I'm holding against the language. This isn't the point I'm making - the issue I have is that the Rust borrow checker is not powerful enough to accept most correct programs (of real-world complexity) for various reasons. This does not mean that you can't write complex programs in Rust, it only means that most complex programs which do not have the problems Rust claims to address (successfully), have basically zero chance compiling, unleast they're written the way Rust expects them to.

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.
- vacuity 1y ago
  You're exaggerating heavily, which undermines your claims. While Rust claims to allow fearless concurrency, there is plenty of official documentation to show that the limitations are acknowledged. Anyone telling you Rust prevents memory leaks and race conditions is lying, straight up, and this is trivial to verify. You shouldn't be repeating it. Your comments on Send/Sync and unsafe are similarly exaggerated. I have to say, you must be interacting with Rust zealots beyond what I've ever seen, if this is truly your belief.
  - torginus 1y ago
    ?? Now I have to come to the defense of Rust - it does prevent memory leaks (but not space leaks where you leak memory, but it's all being referenced from somewhere). The borrow checker should also prevent race conditions (as not doing so would violate the aliasing rule) This is all provided we stay in safe Rust land, and don't do concurrency or call external APIs, but that's not a claim I'm holding against the language. This isn't the point I'm making - the issue I have is that the Rust borrow checker is not powerful enough to accept most correct programs (of real-world complexity) for various reasons. This does not mean that you can't write complex programs in Rust, it only means that most complex programs which do not have the problems Rust claims to address (successfully), have basically zero chance compiling, unleast they're written the way Rust expects them to.