3 ms·

Maybe I shouldn't have said that, because it's contentious, but I do believe it to be true. I believe Rust's success has less to do with memory safety, which I

• fluffything 6y ago
  A GC only protects you from memory errors, not threading errors. In general, Rust allows you to write software that doesn't break silently. That's a quite good value proposition for large scale software, where other languages often require programers to be super careful with refactorings, while in Rust you can really refactor all the things. The reason people are afraid to do large refactorings in say C++ is often "security-related": fear of introducing segfaults, memory errors, undefined behavior, threading errors, etc. but one can also see these fears as "productivity-related" (hours and hours of debugging), or through many other lenses (shipping bugs to users, having a segfault in the middle of a demo that costs you a client, introducing a segfault one day before the release of your game, etc.). In general, every programmer wants to have a certain degree of security that their software "works" for some definition of "works". For some this security might be actual network security, but for others it might mean that they don't want their data-science app that has been running for a week burning thousands of dollars to crash due to a segfault while writing the results.
  • pjmlp 6y ago
    Rust's type system also only protects about threading errors if they happen to be data races for in-process data structures. If they are external resources, there is little it can do. While an improvement, it isn't a full solution, specially in the domain of distributed computing.
    • fluffything 6y ago
      For multi-process data-structures using inter-process shared memory, you can still write Rust APIs that protect you from data-races as long as all processes involved use those APIs. If they don't, then protection is up to the operating system (you can lock and unlock shared memory, but whether processes can violate the locks is an OS thing). For distributed computing, you typically use message passing of some form via network sockets, that's "safe" by design. You can also use RDMA, and there usually your process needs to opt into that, create an RDMA readable/writable region, and you are back to the mercy of your network stack up to which kind of protection you can enforce there. From Rust point-of-view, if you make the wrong assumptions about shared memory or RDMA regions, your program has a bug. The fix is simple, use appropriate atomic (or atomic volatile) to read/write from those regions. Even if another process is writing while you are reading, as long as the operations are the right ones (e.g. <128-bit atomic reads/writes), you can avoid memory unsafety and data races. This won't protect you from deadlocks or race conditions, etc. but that's not something that any programming language does. Rust has deadlock protection within a process, but that's not required for safety, so it is an extra feature on top.
      • pjmlp 6y ago
        That is exactly my point, while it is definitely good to have, it isn't the end solution that many assume at first thought.