5 ms·

In C++, I can use pointers (or their equivalents like STL’s iterators or ATL’s positions) to combine simple built-in data structures into complex data structure

In C++, I can use pointers (or their equivalents like STL’s iterators or ATL’s positions) to combine simple built-in data structures into complex data structures to suit my needs. For example, a vector that keeps some items + hash map that implements an index over that vector. Or some container that keeps some items + a linked list to track and evict the least recently used item from that container. Rust is just too safe for that. That might be technically doable, but harder to implement, and harder to use. This certainly applies to Rust’s built-in data structures as well. See this example, the problem is trivial to solve in most languages: https://www.reddit.com/r/rust/comments/3cz71e/holding_a_mutable_ref_to_item_in_container_blocks/ https://www.reddit.com/r/rust/comments/3cz71e/holding_a_muta...

kibwen 10y ago
I can believe that such a data structure would be harder to use, since if you bubble the unsafety upwards in your API then you'll force your users to use the `unsafe` keyword. But I'm afraid I don't see how this implies that data structures would be limited or harder to implement: raw pointers exist in Rust, and they're exactly as powerful and unrestricted as they are in C++. The only way it would be harder would be if you were trying to use references to ensure safety guarantees about your program above and beyond what C++ is capable of guaranteeing (i.e. doing more than what C++ does). > See this example, the problem is trivial to solve in most > languages I disagree. That proposed code (again using references which provide guarantees that no other language provides) is failing because Rust statically prevents data races, which is not only non-trivial to solve in most languages, but actually impossible to solve in general in most languages. The way around this is to, again, regress to what other languages do and use raw pointers directly.
- Const-me 10y ago
  About raw pointers — no you can’t do same as in C++. There’s no malloc/free, and placement new is still unstable. Also they feel foreign to the language, and sometimes I can’t even get them from the standard collections (like when I need 2 mutable pointers to different elements). About the safety, it’s important to understand there’s a price. In some cases, it causes simple things hard to implement, or cost performance. For example, there’re algorithms out there that modify items of the same collection at the same time, both single threaded like sorting, and parallel. Can such algorithm cause a data race? Yes. Is it good the compiler tells me about that? Sure. Is it good the compiler prevents me from doing that at all, and forces me to code some workarounds, that will cost me time to implement, will be ugly, and/or will sacrifice runtime performance? Not sure, I like having a choice.
  - kibwen 10y ago
    > There’s no malloc/free Calling into libc isn't a problem, see http://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/fn.malloc.html http://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/... (and in the future, http://doc.rust-lang.org/alloc/heap/index.html http://doc.rust-lang.org/alloc/heap/index.html will be stabilized). > placement new is still unstable That's a fair criticism, the onus is on us to get these features finalized and polished. :) Placement new is certainly going to be a high priority once MIR and specialization are wrapped up. > Is it good the compiler prevents me > from doing that at all But it's not preventing you from doing anything, it's just telling you that it can't automatically prove that a use of references is safe. This is precisely what raw pointers are intended for: Rust isn't about entirely eliminating potential unsafety, it's about encapsulating it behind an "I know better than the compiler" interface that can be feasibly hand-audited. > workarounds, that will cost me time to > implement, will be ugly, and/or will > sacrifice runtime performance I still don't quite understand this criticism. If you were so inclined, you could forgo references altogether and code Rust as though it were C, with nothing but raw pointers, and it shouldn't take any more time to write than C, be no more ugly (syntactic differences aside), and have no difference in runtime performance.
    - Const-me 10y ago
      > you could forgo references altogether and code Rust as though it were C, with nothing but raw pointers, and it shouldn't take any more time to write than C Disagree. In C++ we have sophisticated debuggers, we have standard C library, STL with its containers, algorithms and lots more, boost and other third-party libraries. When coding typical Rust, we have descent-quality standard library, also big set of third-party libraries. When coding Rust as though it were C, we have almost nothing, because the rust’s standard library doesn’t expose unsafe API. Unsafe Rust only takes same time to write as C++ if you’re coding something trivial, like a “Programming 101” homework. For anything even remotely useful, debugger and libraries make huge difference. A single bounds checking feature (C++ has that with STL containers in debug builds, controlled by _GLIBCXX_DEBUG or _ITERATOR_DEBUG_LEVEL) can sometimes save hours.
      - 10y ago

kibwen 10y ago

I can believe that such a data structure would be harder to use, since if you bubble the unsafety upwards in your API then you'll force your users to use the `unsafe` keyword. But I'm afraid I don't see how this implies that data structures would be limited or harder to implement: raw pointers exist in Rust, and they're exactly as powerful and unrestricted as they are in C++. The only way it would be harder would be if you were trying to use references to ensure safety guarantees about your program above and beyond what C++ is capable of guaranteeing (i.e. doing more than what C++ does). > See this example, the problem is trivial to solve in most > languages I disagree. That proposed code (again using references which provide guarantees that no other language provides) is failing because Rust statically prevents data races, which is not only non-trivial to solve in most languages, but actually impossible to solve in general in most languages. The way around this is to, again, regress to what other languages do and use raw pointers directly.

Const-me 10y ago
About raw pointers — no you can’t do same as in C++. There’s no malloc/free, and placement new is still unstable. Also they feel foreign to the language, and sometimes I can’t even get them from the standard collections (like when I need 2 mutable pointers to different elements). About the safety, it’s important to understand there’s a price. In some cases, it causes simple things hard to implement, or cost performance. For example, there’re algorithms out there that modify items of the same collection at the same time, both single threaded like sorting, and parallel. Can such algorithm cause a data race? Yes. Is it good the compiler tells me about that? Sure. Is it good the compiler prevents me from doing that at all, and forces me to code some workarounds, that will cost me time to implement, will be ugly, and/or will sacrifice runtime performance? Not sure, I like having a choice.
- kibwen 10y ago
  > There’s no malloc/free Calling into libc isn't a problem, see http://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/fn.malloc.html http://doc.rust-lang.org/libc/x86_64-unknown-linux-gnu/libc/... (and in the future, http://doc.rust-lang.org/alloc/heap/index.html http://doc.rust-lang.org/alloc/heap/index.html will be stabilized). > placement new is still unstable That's a fair criticism, the onus is on us to get these features finalized and polished. :) Placement new is certainly going to be a high priority once MIR and specialization are wrapped up. > Is it good the compiler prevents me > from doing that at all But it's not preventing you from doing anything, it's just telling you that it can't automatically prove that a use of references is safe. This is precisely what raw pointers are intended for: Rust isn't about entirely eliminating potential unsafety, it's about encapsulating it behind an "I know better than the compiler" interface that can be feasibly hand-audited. > workarounds, that will cost me time to > implement, will be ugly, and/or will > sacrifice runtime performance I still don't quite understand this criticism. If you were so inclined, you could forgo references altogether and code Rust as though it were C, with nothing but raw pointers, and it shouldn't take any more time to write than C, be no more ugly (syntactic differences aside), and have no difference in runtime performance.
  - Const-me 10y ago
    > you could forgo references altogether and code Rust as though it were C, with nothing but raw pointers, and it shouldn't take any more time to write than C Disagree. In C++ we have sophisticated debuggers, we have standard C library, STL with its containers, algorithms and lots more, boost and other third-party libraries. When coding typical Rust, we have descent-quality standard library, also big set of third-party libraries. When coding Rust as though it were C, we have almost nothing, because the rust’s standard library doesn’t expose unsafe API. Unsafe Rust only takes same time to write as C++ if you’re coding something trivial, like a “Programming 101” homework. For anything even remotely useful, debugger and libraries make huge difference. A single bounds checking feature (C++ has that with STL containers in debug builds, controlled by _GLIBCXX_DEBUG or _ITERATOR_DEBUG_LEVEL) can sometimes save hours.
    - 10y ago