5 ms·

There's something off-putting about how Rust people communicate. Like you're talking to people selling something, or people with ulterior motives. They love tal

There's something off-putting about how Rust people communicate. Like you're talking to people selling something, or people with ulterior motives. They love talikng about memory safety as that's the only thing standing between humanity having secure and reliable software. They love external audiences, as their brand of fearmongering, virtue signaling and offering of panacea-like solutions resonates with a certain kind of risk-averse decision maker, who tend to in power in uncomfortable numbers. 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, with certain libraries allowing some escape hatches in Rust's case. Additionally the case for aliasing control leading to better and safer code that's easier to reason about just isn't really true in practice - it's so rare that, for example your function can accidentally can alias memory in strictly typed languages - and when it does it's kind of intentional. The concern pretty much only manifests in memcpy, as the ugly hack of 'strict aliasing' - assuming 2 pointers of incompatible types pointing to different bits of memory - works very well in practice. It even helps with situations people complain about in Rust, like when object A and B (both mutably borrowed) take a reference to a some common service object (which is super common) - but that sort of code simply doesn't compile in Rust. All in all, I don't dislike Rust as it is but the project's tendency to do activism trying to bully its technical skeptics into submission (which is unfortunately what all activism really is - when you lost the argument, try to louder than the other guy and paint him as reprehensible) - they focused on fixing the technical issues. There has been research into ownership schemes, some exist that are less restrictive than Rust's while offering the same safety guarantees. In my personal opinion Rust is not done on the conceptual level - by 'done' I mean Rust serving its purpose as the language it claims to be. Maybe there will be Rust 2.0 which will overhaul the ownership system completely or maybe there'll be another language that will do what Rust does but better. Edit: I wish I could claim I'm some sort of tin-foil conspiracy theorist, but I'm commenting under an article written by one of the key people behind Rust, and it reeks of this attitude.

filleduchaos 1y ago
> 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.

filleduchaos 1y ago

> 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.