9 ms·

I would argue that the phrase "One of Rust's main differentiator[s] is that it provides memory safety" should really be "One of Rust's main differentiators is t

• _-___________-_ 7y ago
  Yeah, I guess they mean differentiators against similar languages (mostly C/C++). There are few languages with "no runtime" that provide memory safety.
  • jkoudys 7y ago
    As someone who hasn't done much c++ in over a decade, but who loves rust, I often find the extreme focus on comparing to c++ to be a bit jarring and unhelpful. As someone who's worked more with JS/ts/java, I find the borrowing system's guarantees far more interesting wrt concurrency. Yet that's often little more than a footnote in long articles about how rust is safer than c++.
    • jfkebwjsbx 7y ago
      Which guarantees? Rust guarantees there are no data races (like other higher level languages). It does not guarantee anything regarding general race conditions (no language can, at least in a non-trivial way). Rust gets compared with C++ because that is the target audience. If you don’t need the properties of a systems programming language, you are better off avoiding both C++ and Rust for increased productivity.
      • nicoburns 7y ago
        It prevents you from sharing non-threadsafe structures between threads. A language like Java provides a concurrent hashmap, but nothing stops you from (incorrectly) using the standard hashmap. Rust will fail to compile if you share a std::HashMap across threads without wrapping it in a mutex or similar synchronisation primitive.
      • deleted 7y ago
        [deleted]
• alkonaut 7y ago
  That would also be a bit confusing because it can be interpreted (incorrectly) as that all languages with garbage collectors offers all the safety guarantees of Rust. A trivial counterexample is the protection against data races.
  • CJefferson 7y ago
    Yes, as I do more rust, I love the fact I can safely parallelise more than I love the memory protection. Before Rust, I was close to saying that thread-based parallelization was almost impossible to do safely, and was moving to only doing process-level parallelization.
    • littlestymaar 7y ago
      This was actually the reason why Graydon Hoare created Rust BTW. He wasn't looking for a way to get rid of garbage collection or an alternative to C++ (those two characteristics came later from Mozilla, the first versions of Rust had a GC and a heavy runtime with green threads and all), but he wanted a language that helped using all cores on the machine without the traditional issues of shared-memory multithreading.
  • jfkebwjsbx 7y ago
    False, because Rust does not offer protection against race conditions. Do not confuse data races (a subset of race conditions that many languages solve) with race conditions (a way harder problem that there is no general solution to).
    • ChrisSD 7y ago
      True but the point still stands if the example is changed to: > A trivial counterexample is the protection against data races.
      • alkonaut 7y ago
        I updated my post to say exactly that. I always confuse those.
• pdpi 7y ago
  Rust doesn't provide memory safety in the GC sense — it can and will leak memory in ways Java wouldn't. Rather, it provides safety from all data races, which is something that conventional GCs don't give you.
  • chewbacha 7y ago
    "Memory Safety" doesn't refer to leakage, it refers to read-after-free, buffer overflows, and other memory-access related bugs. Garbage collection runtimes keep track of memory access to avoid these issues, rust does it through lifetimes/ownership.
  • bluejekyll 7y ago
    Java doesn’t prevent memory leaks either. Java will happily allocate up until an OOM. If an object is live, it will not be garbage collected. In fact Java will leak memory over FFI boundaries as well. Rust is memory safe, but like many languages it is not leak safe. It is possible in Rust to tell it to leak memory, but that’s for special cases. To state this another way, memory leaks are different from memory safety.
  • swsieber 7y ago
    True, but it's safe with memory in ways that non-GC'd languages usually aren't (buffer overflows, use after free, etc.) so it's worth mentioning the GC bit.
  • mqus 7y ago
    How does java prevent memory leaks which rust couldn't ? Do you have examples for that? I was not aware that Java does it and am very interested in that.
    • steveklabnik 7y ago
      One of the advantages of a tracing garbage collector is that it can recognize cycles. This means that if you have a few objects which point to each other, but the overall object graph is dead, a tracing GC should be able to collect these objects. If you use reference counting in Rust, it will not be able to detect cycles. That said, it's not super easy to get a cycle accidentally.
• eloff 7y ago
  It also protects against data races which is fairly novel. A lot of functional languages offer this by avoiding mutable data, but that's high cost and not really equal with what rust does. I find rust quite elegant but also quite complex. There's a scale for computer languages between a compiler that doesn't do enough checking (JavaScript, Python), and ones that do too much where you spend a lot of energy trying to satisfy the compiler. I think rust falls a bit too far to this latter side for my taste. I like the language but I feel more productive with Go even although Go isn't as elegant in my mind and has some flaws (nil, no generics). I think rust is nicer for where you would previously use C or C++ but I don't work in that domain.
  • throwaway894345 7y ago
    I agree with everything you posted (and I also really like Rust!), but I especially took note of this: > A lot of functional languages offer this by avoiding mutable data, but that's high cost This is true, but the inverse is that Rust's ownership model itself poses its own high cost in terms of a significant cognitive burden (and while I have no doubt that the burden decreases with time, I'm very skeptical that it ever gets to the point of a GC language). This is roughly what you're saying in the second paragraph, but I wanted to be a bit more explicit that the ownership model itself comes with a cost.
    • steveklabnik 7y ago
      I think how low it gets really depends on the person. For me, it's basically zero burden. I don't have to think about these things, the compiler thinks about them! That's kind of the point. I've also internalized the rules, so that I tend to program in a style that works. I am of course, extremely biased, but this story seems to play out with many people who stick with it.
    • dpc_pw 7y ago
      > significant cognitive burden (...) I'm very skeptical that it ever gets to the point of a GC language My experience in this regard: Once you stop thinking in OOP, and embrace Data Oriented Design (which really helps structure your program like Rust wants it to be to avoid lifetimes issues) and get proficient with type system and popular libraries, Rust is far more productive and effortless than mainstream GC languages. I routinely do non-trivial changes to my open source projects late in the evening, after long day of work, after I've finally put my kids to sleep, and despite sloppiness and lethargy it's very much effortless. I don't have to debug weird stuff. Compiler just straight tells me what I did wrong and how to fix it. Languages expressiveness is first class, so I don't have think too much what's the best way to express this or that idea. Then - not only I don't have to worry about `free`, but I also get deterministic destruction: files, sockets and any other "resources" get closed/freed when I'm done with them. And then the libraries... they have beautiful, well-documented, and hard to misuse APIs.
• abraxas 7y ago
  One thing that still confuses me about Rust and something I'm not able to brush aside is the fact that as far as I can tell I can't ever be certain when Rust will decide that it needs to copy the underlying data or merely pass a pointer. I don't know the language beyond reading a few chapters of the Rust book but this is something I'm stuck on and I won't invest time in learning the language that removes from my control when I pass data by reference versus pass it by value. The cost of the latter is simply too great in certain scenarios. Can someone share a good, authoritative source that explains the variable passing semantics of Rust in terms that a C/C++/Java programmer can understand?
  • estebank 7y ago
    I don't understand where your confusion is coming from. If and argument is a borrow, it is being passed by reference. If its ownership is passed, the type is passed by value, and a copy might happen if needed or the same portion of memory will be used if the compiler can avoid the copy. You seem to think you have less control over your allocations than in other languages, but this is not accurate, particularly contrasted to GCd languages.
    • abraxas 7y ago
      > and a copy might happen if needed or the same portion of memory will be used if the compiler can avoid the copy How can I definitively tell which of the two things will happen? Under what conditions will it choose to make a copy instead of passing the address?
      • estebank 7y ago
        Scratch that, it is actually a planned feature (I thought llvm was already doing it): https://github.com/rust-lang/rust/issues/13707 https://github.com/rust-lang/rust/issues/13707 The idea is to detect large moves and do a pass by reference, much like Swift does. On my personal roadmap I have detecting these cases and lint against it, suggesting passing the argument as & or &mut as appropriate. That way the performance implications and tradeoffs are visible in the code you write/read.