6 ms·

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

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.
  - zozbot234 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) Rc<> and Arc<> can create true memory leaks where a cycle of Rc<> or Arc<> referencing one another can stay allocated in memory even when all outside references to the objects have disappeared, so the leak cannot even be collected. This is the one thing that is not allowed to occur with a tracing garbage collector as in Fil-C. (Rust also allows leaking memory explicitly, e.g. for the purpose of passing a reference to that memory to foreign code where Rust cannot observe its lifecycle. Then in order to properly drop that memory in Rust, you have to essentially recreate that allocation from scratch.) Race conditions are a logical error that has nothing to do with the borrow checker. The borrow checker can only prevent properly defined data races, which are entirely unrelated to logical race conditions.
    - torginus 1y ago
      You are right, you can absolutely cause memory leaks with Rc, I haven't considered that. However that kind of raises an interesting point - Rc<T>::clone clearly mutates something under the hood as the reference counter is shared, however its not mut. Having something in the core language that breaks the rules and causes actual problems in practice is kind of an ill omen. And I meant data races, I have stated in my previous post, that race conditions due to issues existing outside of the language, like external libraries or network requests are not the fault of Rust. Neither are logic mistakes a programmer makes.
      - zozbot234 1y ago
        Interior mutability is explicitly provided for in the language, and consistently marked under the hood via UnsafeCell<>. Thus, the compiler can always check whether interior mutability is possible, including wrt. reference counts. In practice, the &mut modifier has more to do with the absence of aliasing (much like *restrict in C) than mutability itself.
filleduchaos 1y ago
Again to be maybe overly blunt, it's rather strange to call my comment mean-spirited and then simply repeat the exact argument I called out as being wishy-washy. The crux of what you're saying seems to be > 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. You have not actually articulated any real problem with "Sync, Send, Arc, etc" beyond what just sounds like "but I don't wanna". Even leaving aside Sync and Send, which are constructs fairly unique to Rust, the fact that your other example of a construct you have to "try to adapt" your multithreaded code to use is Arc - quite literally the equivalent of std::shared_ptr - on its own casts heavy doubt on the seriousness of your complaint. Like, "oh no! I have to use an atomic reference counted smart pointer in my multithreaded program" is quite simply unserious as a complaint about a programming language. How exactly you think pointers should be shared between threads, then? Just passing raw pointers around, and taking responsibility any use-after-free bugs that arise because you know what you're doing and definitely aren't going to write one? Well guess what, you can do that in Rust, too (and I have done that in a few non-trivial projects), but you have to mark that obviously unsafe operation with `unsafe`. For some reason, this six-letter keyword is apparently enough to get people who allegedly know what they're doing to break out in hives, and I just do not understand it. And coming back to Send and Sync, if you understand what those traits are (versus just seeing them as something to slap on code to make the compiler stop screaming), then I'm sure you know that they are automatically derived traits. If you are having to explicitly implement them, it is because something in your structure is dubiously thread-safe - for instance, a raw pointer or a type that has been marked as thread-local. If you are that confident that you are handling whatever it is in a thread-safe manner, then what exactly is the big adaptation in the one-line implementation (each) of Send and Sync? If anything, this whole "I have to write new, explicit syntax expressing my intentions and this is The Worst and the same thing as not being to do anything at all" business just reminds me of dynamic typing diehards' complaints about static typing; just replace "using Sync, Send, Arc, etc" with "writing out type annotations". They also complain about compilers rejecting "non-trivial but correct programs" for the minor sin of not being properly annotated. > These libraries usually contain giant blobs of unsafe Rust, which isn't exactly a win for the language. You simply cannot put up this cowboy coder "I don't want to be nannied" argument and then start calling for a nanny because the keyword for "I have information that the compiler doesn't, so I'm taking the reins here" is `unsafe`. It is profoundly unserious. Same thing with this supposed overwhelming complexity of writing regular/safe multithreaded Rust, it really just sounds like wanting the language to pretend that multithreaded execution isn't complex and just handle everything about it for you as you write code as if it is single-threaded and have it just work, without having to think about the semantics. If you don't want to be nannied in that manner, then I don't understand how one can be so dissatisfied with that the language actually does (i.e. provides "certified safe - terms and conditions apply" constructs to express semantics the user is supposed to understand) that they resort to just copying everything instead and genuinely hold the opinion that the language is no different from JavaScript in that regard (a language that notoriously doesn't even have actual threads). And the comparison is plain dishonest no matter how you spin it.
deleted 1y ago
[deleted]
jibal 1y ago
For mean spirited I would consider > There's something off-putting about how Rust people communicate. Like you're talking to people selling something, or people with ulterior motives. Which is a radically wrong description of the tone of the OP that is purportedly the reason for the comment. And for the most impressive bit of un-self-reflective projection I've seen in a long time, there's > And the way you write is extremely rude and condescending, if you do decide to phrase your comments in such a demeaning way (which I don't ever recommend), please at least be right next time.
- torginus 1y ago
  Do you use Rust in a professional capacity? Because I do, and I do because I chose it for a project over C++. Rust is much nicer in certain ways than C++ (like cargo or the whole ecosystem of packages), but it's core idea and assumption (which imo can equivalently stated as 'the borrow checker' or 'exact aliasing control') is flawed as it is, and programmers of all skill levels struggle with it for various reasons when writing programs of real-world complexity. There are 3 kinds of ways people percieve Rust - those who see it as a cool piece of tech (which I agree with), those who see it as a practical tool, and those who see liking or not liking Rust as an ideological statement. I see it as a tool. There's a lot of statements around Rust that are true in the strict factual sense, but clearly meant to be read differently. 'Free beer at the pub tonight' is a true statement even though the full truth would be 'Free beer at the bar tonight (entry fee $200)'. 'Fearless concurrency' is among these statements meant to be interpreted as making concurrent programming easier. The true statement would be 'fearless concurrency (but you might need to rewrite your program)'.
- skeezyjefferson 1y ago
  > And for the most impressive bit of un-self-reflective projection bit shitty of you given youre having him over his tone, no?
  - jibal 1y ago
    -6 karma says what? You have no understanding of the context of this old conversation. Goodbye.

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.
- zozbot234 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) Rc<> and Arc<> can create true memory leaks where a cycle of Rc<> or Arc<> referencing one another can stay allocated in memory even when all outside references to the objects have disappeared, so the leak cannot even be collected. This is the one thing that is not allowed to occur with a tracing garbage collector as in Fil-C. (Rust also allows leaking memory explicitly, e.g. for the purpose of passing a reference to that memory to foreign code where Rust cannot observe its lifecycle. Then in order to properly drop that memory in Rust, you have to essentially recreate that allocation from scratch.) Race conditions are a logical error that has nothing to do with the borrow checker. The borrow checker can only prevent properly defined data races, which are entirely unrelated to logical race conditions.
  - torginus 1y ago
    You are right, you can absolutely cause memory leaks with Rc, I haven't considered that. However that kind of raises an interesting point - Rc<T>::clone clearly mutates something under the hood as the reference counter is shared, however its not mut. Having something in the core language that breaks the rules and causes actual problems in practice is kind of an ill omen. And I meant data races, I have stated in my previous post, that race conditions due to issues existing outside of the language, like external libraries or network requests are not the fault of Rust. Neither are logic mistakes a programmer makes.
    - zozbot234 1y ago
      Interior mutability is explicitly provided for in the language, and consistently marked under the hood via UnsafeCell<>. Thus, the compiler can always check whether interior mutability is possible, including wrt. reference counts. In practice, the &mut modifier has more to do with the absence of aliasing (much like *restrict in C) than mutability itself.

filleduchaos 1y ago

Again to be maybe overly blunt, it's rather strange to call my comment mean-spirited and then simply repeat the exact argument I called out as being wishy-washy. The crux of what you're saying seems to be > 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. You have not actually articulated any real problem with "Sync, Send, Arc, etc" beyond what just sounds like "but I don't wanna". Even leaving aside Sync and Send, which are constructs fairly unique to Rust, the fact that your other example of a construct you have to "try to adapt" your multithreaded code to use is Arc - quite literally the equivalent of std::shared_ptr - on its own casts heavy doubt on the seriousness of your complaint. Like, "oh no! I have to use an atomic reference counted smart pointer in my multithreaded program" is quite simply unserious as a complaint about a programming language. How exactly you think pointers should be shared between threads, then? Just passing raw pointers around, and taking responsibility any use-after-free bugs that arise because you know what you're doing and definitely aren't going to write one? Well guess what, you can do that in Rust, too (and I have done that in a few non-trivial projects), but you have to mark that obviously unsafe operation with `unsafe`. For some reason, this six-letter keyword is apparently enough to get people who allegedly know what they're doing to break out in hives, and I just do not understand it. And coming back to Send and Sync, if you understand what those traits are (versus just seeing them as something to slap on code to make the compiler stop screaming), then I'm sure you know that they are automatically derived traits. If you are having to explicitly implement them, it is because something in your structure is dubiously thread-safe - for instance, a raw pointer or a type that has been marked as thread-local. If you are that confident that you are handling whatever it is in a thread-safe manner, then what exactly is the big adaptation in the one-line implementation (each) of Send and Sync? If anything, this whole "I have to write new, explicit syntax expressing my intentions and this is The Worst and the same thing as not being to do anything at all" business just reminds me of dynamic typing diehards' complaints about static typing; just replace "using Sync, Send, Arc, etc" with "writing out type annotations". They also complain about compilers rejecting "non-trivial but correct programs" for the minor sin of not being properly annotated. > These libraries usually contain giant blobs of unsafe Rust, which isn't exactly a win for the language. You simply cannot put up this cowboy coder "I don't want to be nannied" argument and then start calling for a nanny because the keyword for "I have information that the compiler doesn't, so I'm taking the reins here" is `unsafe`. It is profoundly unserious. Same thing with this supposed overwhelming complexity of writing regular/safe multithreaded Rust, it really just sounds like wanting the language to pretend that multithreaded execution isn't complex and just handle everything about it for you as you write code as if it is single-threaded and have it just work, without having to think about the semantics. If you don't want to be nannied in that manner, then I don't understand how one can be so dissatisfied with that the language actually does (i.e. provides "certified safe - terms and conditions apply" constructs to express semantics the user is supposed to understand) that they resort to just copying everything instead and genuinely hold the opinion that the language is no different from JavaScript in that regard (a language that notoriously doesn't even have actual threads). And the comparison is plain dishonest no matter how you spin it.

deleted 1y ago

[deleted]

jibal 1y ago

For mean spirited I would consider > There's something off-putting about how Rust people communicate. Like you're talking to people selling something, or people with ulterior motives. Which is a radically wrong description of the tone of the OP that is purportedly the reason for the comment. And for the most impressive bit of un-self-reflective projection I've seen in a long time, there's > And the way you write is extremely rude and condescending, if you do decide to phrase your comments in such a demeaning way (which I don't ever recommend), please at least be right next time.

torginus 1y ago
Do you use Rust in a professional capacity? Because I do, and I do because I chose it for a project over C++. Rust is much nicer in certain ways than C++ (like cargo or the whole ecosystem of packages), but it's core idea and assumption (which imo can equivalently stated as 'the borrow checker' or 'exact aliasing control') is flawed as it is, and programmers of all skill levels struggle with it for various reasons when writing programs of real-world complexity. There are 3 kinds of ways people percieve Rust - those who see it as a cool piece of tech (which I agree with), those who see it as a practical tool, and those who see liking or not liking Rust as an ideological statement. I see it as a tool. There's a lot of statements around Rust that are true in the strict factual sense, but clearly meant to be read differently. 'Free beer at the pub tonight' is a true statement even though the full truth would be 'Free beer at the bar tonight (entry fee $200)'. 'Fearless concurrency' is among these statements meant to be interpreted as making concurrent programming easier. The true statement would be 'fearless concurrency (but you might need to rewrite your program)'.
skeezyjefferson 1y ago
> And for the most impressive bit of un-self-reflective projection bit shitty of you given youre having him over his tone, no?
- jibal 1y ago
  -6 karma says what? You have no understanding of the context of this old conversation. Goodbye.