5 ms·

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 so

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.
  - kibwen 10y ago
    > In C++ we have sophisticated debuggers What features do you look for in a sophisticated debugger? There's upstream support for Rust in GDB (https://np.reddit.com/r/rust/comments/4merw3/gdb_now_supports_debugging_programs_written_in/ https://np.reddit.com/r/rust/comments/4merw3/gdb_now_support...), I've seen people do reverse debugging with rr (http://huonw.github.io/blog/2015/10/rreverse-debugging/ http://huonw.github.io/blog/2015/10/rreverse-debugging/) as well as Valgrind, and the compiler knows how to emit debuginfo, and so should work with any tool that can read DWARF (like LLDB). Mozilla is investing even more into dedicated IDE support this year and the next. > the rust’s standard library doesn’t expose unsafe API What unsafe APIs would you like to see? Using Vec as an example, I see a function for constructing a Vec out of raw data (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.from_raw_parts http://doc.rust-lang.org/std/vec/struct.Vec.html#method.from...), a function for mucking around with the private length field (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.set_len http://doc.rust-lang.org/std/vec/struct.Vec.html#method.set_...), a function for receiving a raw pointer to the underlying buffer (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.as_mut_ptr http://doc.rust-lang.org/std/vec/struct.Vec.html#method.as_m...)... we're far from opposed to adding low-level APIs for complete control over collections, all you need to do is ask for them and tell us why they'd be useful. :) > A single bounds checking feature I'm not sure what this is asking for. All Rust containers are bounds-checked by default.

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.
- kibwen 10y ago
  > In C++ we have sophisticated debuggers What features do you look for in a sophisticated debugger? There's upstream support for Rust in GDB (https://np.reddit.com/r/rust/comments/4merw3/gdb_now_supports_debugging_programs_written_in/ https://np.reddit.com/r/rust/comments/4merw3/gdb_now_support...), I've seen people do reverse debugging with rr (http://huonw.github.io/blog/2015/10/rreverse-debugging/ http://huonw.github.io/blog/2015/10/rreverse-debugging/) as well as Valgrind, and the compiler knows how to emit debuginfo, and so should work with any tool that can read DWARF (like LLDB). Mozilla is investing even more into dedicated IDE support this year and the next. > the rust’s standard library doesn’t expose unsafe API What unsafe APIs would you like to see? Using Vec as an example, I see a function for constructing a Vec out of raw data (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.from_raw_parts http://doc.rust-lang.org/std/vec/struct.Vec.html#method.from...), a function for mucking around with the private length field (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.set_len http://doc.rust-lang.org/std/vec/struct.Vec.html#method.set_...), a function for receiving a raw pointer to the underlying buffer (http://doc.rust-lang.org/std/vec/struct.Vec.html#method.as_mut_ptr http://doc.rust-lang.org/std/vec/struct.Vec.html#method.as_m...)... we're far from opposed to adding low-level APIs for complete control over collections, all you need to do is ask for them and tell us why they'd be useful. :) > A single bounds checking feature I'm not sure what this is asking for. All Rust containers are bounds-checked by default.