4 ms·

Personally, I use Rust as a "better C++". Ways in which it is better: * A decent package manager * "Safe by default" (you have to use 'unsafe' to turn off th

Personally, I use Rust as a "better C++". Ways in which it is better: * A decent package manager * "Safe by default" (you have to use 'unsafe' to turn off the safety features), unlike C++ which is "unsafe by default" (v[i] is undefined behaviour if i is out of bounds, for all of C arrays, std::arrays and std::vectors). * Really easy to do multithreading -- I had reached the point with C and C++ where I was of the opinion it is "almost impossible" to write large thread-safe programs, and all communication should be between processes with pipes, wherever reasonable. In Rust I again feel I can safely and productively write multi-threaded code. The things Rust doesn't let you do (throw pointers around everywhere) can get a little annoying, but I find the extra safety increases my productivity enough that it's worth the tradeoff.

dralley 4y ago
>(you have to use 'unsafe' to turn off the safety features) "unsafe" doesn't turn off any safety features, it just allows you to do additional things which the base language does not, like: * use raw pointers * use mutable static globals * access fields of unions https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsafe-superpowers https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa... All the rules of safe Rust still apply inside of unsafe blocks. The borrow checker still works, etc.
tialaramex 4y ago
You didn't say otherwise, but this is such a frequent misunderstanding from people who don't write Rust, or write only safe Rust (which is fine) that it's worth pointing out the unsafe keyword and Rust's choice to be "safe by default" are not directly related. Culturally obviously they come from the same place, but for example: v[i] is bounds checked in Rust even in unsafe. The unsafe "super powers" don't include "magically now indexing has no bounds checks" but because Rust's get function v.get_unchecked(i) is marked unsafe‡ you would need to mark code unsafe to use that function and that function doesn't have bounds checks. If you write: unsafe { println!("{}", v[i]); } The compiler will point out that unsafe isn't doing anything for you here, v[i] is safe, marking it unsafe is just a waste of everybody's time. C++ doesn't have bounds checked array access for its abandoned built-in arrays, but it does (these days) have bounds checked access for std::array and std::vector as a separate member function, however because they aren't the default few C++ programmers use them even where they undoubtedly should. This is an ergonomics issue, it's just easier to write needlessly unsafe C++. ‡ This said just get() before I edited it, but Steve corrected me, see below.
- steveklabnik 4y ago
  Teeeny tiny note > because Rust's get function v.get(i) is marked unsafe You mean get_unchecked. get is safe, and returns an Option, so that None can be returned if something is out of bounds.
  - tialaramex 4y ago
    Doh! I even had the "get_unchecked()" function in front of me on the screen and wrote get() anyway. Thanks Steve.
    - steveklabnik 4y ago
      No problem. Thanks for explaining what unsafe does and doesn't do; you're 100% right that this is a common misconception that comes up often.
- CJefferson 4y ago
  You are right, I did know this but it's worth clarifying. Thanks.
- int_19h 4y ago
  C++ has had std::vector::at() - which checks for out-of-bounds indices - since C++98. The reason why it's not used all that much in practice is because indexing is relatively rare - most of the time, you just iterate over collections, or otherwise use iterators rather than raw indices. And there's no ability to opt into bounds checking for C++ iterators in the standard - implementations usually provide some kind of checked iterators for debug builds, but performance is such that you'd never want that enabled for release.
  - pjmlp 4y ago
    I always keep them enabled for release, performance is good enough. Most devs should learn to use profilers.
    - 4y ago

dralley 4y ago

>(you have to use 'unsafe' to turn off the safety features) "unsafe" doesn't turn off any safety features, it just allows you to do additional things which the base language does not, like: * use raw pointers * use mutable static globals * access fields of unions https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsafe-superpowers https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa... All the rules of safe Rust still apply inside of unsafe blocks. The borrow checker still works, etc.

tialaramex 4y ago

You didn't say otherwise, but this is such a frequent misunderstanding from people who don't write Rust, or write only safe Rust (which is fine) that it's worth pointing out the unsafe keyword and Rust's choice to be "safe by default" are not directly related. Culturally obviously they come from the same place, but for example: v[i] is bounds checked in Rust even in unsafe. The unsafe "super powers" don't include "magically now indexing has no bounds checks" but because Rust's get function v.get_unchecked(i) is marked unsafe‡ you would need to mark code unsafe to use that function and that function doesn't have bounds checks. If you write: unsafe { println!("{}", v[i]); } The compiler will point out that unsafe isn't doing anything for you here, v[i] is safe, marking it unsafe is just a waste of everybody's time. C++ doesn't have bounds checked array access for its abandoned built-in arrays, but it does (these days) have bounds checked access for std::array and std::vector as a separate member function, however because they aren't the default few C++ programmers use them even where they undoubtedly should. This is an ergonomics issue, it's just easier to write needlessly unsafe C++. ‡ This said just get() before I edited it, but Steve corrected me, see below.

steveklabnik 4y ago
Teeeny tiny note > because Rust's get function v.get(i) is marked unsafe You mean get_unchecked. get is safe, and returns an Option, so that None can be returned if something is out of bounds.
- tialaramex 4y ago
  Doh! I even had the "get_unchecked()" function in front of me on the screen and wrote get() anyway. Thanks Steve.
  - steveklabnik 4y ago
    No problem. Thanks for explaining what unsafe does and doesn't do; you're 100% right that this is a common misconception that comes up often.
CJefferson 4y ago
You are right, I did know this but it's worth clarifying. Thanks.
int_19h 4y ago
C++ has had std::vector::at() - which checks for out-of-bounds indices - since C++98. The reason why it's not used all that much in practice is because indexing is relatively rare - most of the time, you just iterate over collections, or otherwise use iterators rather than raw indices. And there's no ability to opt into bounds checking for C++ iterators in the standard - implementations usually provide some kind of checked iterators for debug builds, but performance is such that you'd never want that enabled for release.
- pjmlp 4y ago
  I always keep them enabled for release, performance is good enough. Most devs should learn to use profilers.
  - 4y ago