4 ms·

I don't really like the message. For me, it's not "boo, a bug was found after years", it's "yay, they managed to find it!". Bugs are inevitable, security bugs a

• 0xCMP 8y ago
  Mentioned here > You see, Rust provides safe abstractions that let you do useful stuff without having to deal with the complexities of memory layouts and other low-level arcana. But dealing with those things is necessary to run code on modern hardware, so something has to deal with it. In memory-safe languages like Python or Go this is usually handled by the language runtime — and Rust is no exception. > In Rust, the nutty-gritty of hazardous memory accesses is handled by the standard library. It implements the basic building blocks such as vectors that expose a safe interface to the outside, but perform potentially unsafe operations internally.
  • deepsun 8y ago
    Huh, Java didn't know it's necessary to be unsafe to implement a queue (ConcurrentLinkedQueue).
    • dbaupp 8y ago
      Java data structures are built on top of a pile of unsafe code (the JVM and especially the GC), in a similar manner to building things on top of the std data structures in Rust. For concurrency in particular the JVM exposes a more restricted (slower) model than the hardware, to guarantee no unsafety no matter how wrong the code is. Rust can't make that trade-off and still reach its performance goals.
      • deepsun 8y ago
        Mmm, no, ConcurrentLinkedQueue uses the same RAM primitives as Rust can use (compare-and-set, compare-and-set etc) that are needed to implement concurrent queues. And it doesn't use Unsafe class (same as Rust's "unsafe" keyword) in it, it's easy to check. Or maybe I just miss something?
        • dbaupp 8y ago
          Yes: a GC means the programmer can avoid thinking about object lifetimes and just pretend every object lives forever. The garbage collector is deeply unsafe (as in, bugs may cause memory corruption): if a GC fails to account for even a single pointer somewhere, it might deallocate an object too early, potentially leading to problems like use-after-free. Additionally, the JVM ensures every read and write to memory has (minimal) synchronisation so that there is no risk of a data race, meaning no undefined behaviour, no matter how wrong the code is. And, even the reads and writes using proper synchronisation (compare-and-swap, etc.) have only one choice: sequential-consistency. In Rust, a global built-in-to-the-language GC isn't appropriate, and managing object lifetimes properly, with shared memory, is hard. It is thus something that a library has to use `unsafe` for, to assert to the compiler that the programmer has got things right because it is unable to check. Similarly, using synchronised reads/writes everywhere isn't right for Rust, so it is up to the concurrent data structure author to use the right synchronisation (which can be weaker for performance: acquire/release, instead of only SeqCst) just for the rest of the code to be safe: this is also something a compiler can't check.
• zdf 8y ago
  Even plain-old `Vec` requires "The dark arts of advanced and unsafe Rust programming". https://doc.rust-lang.org/nomicon/vec.html https://doc.rust-lang.org/nomicon/vec.html
• agumonkey 8y ago
  I didn't feel this way about the post, but I understand your pov. To me it was important to know that rust doesn't create perfect code out of the box even with all the beautiful theory and design. It's good to stay alert in a way
  • gameswithgo 8y ago
    in the same way, farbage collectora can have bugs that make memory mistakes. has happened to me.