3 ms·

Isn't Rust niche safe low-level (mostly GC-less) programming? I think it is, and the hoops you have to jump through to guarantee that safety are really at odds

• oconnor663 9y ago
  It often feels high level (iterators and closures and all that), but yes, Rust is definitely designed to give you C++-like control over your memory. The learning curve is fairly steep, and new Rustaceans do tend to go through a phase of "fighting the borrow checker". But once you get a handle on the ownership rules, I think you very rarely find them blocking you from doing something you actually should be able to do. For example, it is hard to get non-const pointers to two elements of a map at the same time, because the compiler can't prove they're not pointing to the same element, and that would let you violate all the safety rules. But I'm not sure I've heard of anyone running into that limitation in practice. And if you totally absolutely needed to, you could use unsafe code to do it. The ownership system also gives you a different kind of power, to specify how your API's are supposed to be used, and to have the compiler enforce those rules. If a collection isn't threadsafe, for example, the compiler guarantees that you can't race on it from multiple threads. You can put the container inside a Mutex to let multiple threads use it, but then the Mutex will own the container, and callers can only access it by locking the Mutex. Those are powerful guarantees, and they solve problems that come up in managed/GC'd languages too.
  • pjmlp 9y ago
    Unless one is trying to do GUI related programming.
  • Const-me 9y ago
    > But I'm not sure I've heard of anyone running into that limitation in practice. Algorithms processing trees and graphs are everywhere, both in practice and in CS theory. Both are hard to implement in Rust and/or slow and/or require complex unsafe code. Here’s an example for trees, as you see all 3 approaches are far from ideal: https://github.com/SimonSapin/rust-forest https://github.com/SimonSapin/rust-forest Another thing, because of that ownership thing, in Rust it’s harder to compose data structures. For example, here’s 1300 lines of code implementing hashmap + linked list combination: https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/lib.rs.html https://docs.rs/linked-hash-map/0.4.2/src/linked_hash_map/li... Sure, that particular collection is already in Rust’s standard library. However, quite often I need to compose standard library containers my own way. In Rust, that’s either a lot of complex unsafe code like that LinkedHashMap, or performance sacrifice (e.g. switching from pointers to index in a vector, or ref.counting).
    • oconnor663 9y ago
      I'd heard about the graph issue, but I don't know much about it. Is the main takeaway that GC makes managing trees/graphs a lot easier? If we were talking about C++ instead of Rust, what extra options would there be?
      • Const-me 9y ago
        > Is the main takeaway that GC makes managing trees/graphs a lot easier? It does indeed. But raw pointers in C or C++ also make it easier than Rust. Sure, it’s very easy to screw things up leaking and/or corrupting memory. But it still quite possible to implement correctly, I did that more than once. Technically, you can usually do the same in Rust with unsafe pointers. Like the developers did to implement that LinkedHashMap for the Rust’s standard library. However, C++ is just better for writing unsafe code like this. After all, it evolved for decades being an unsafe language. Over that time, huge amount of stuff were implemented in the language (STL, esp. the checked version), runtime (debug heap), standalone tools (vtune, valgrind), and even OS (windbg) to help people implement e.g. graphs without leaking memory or exposing dangling pointers.