37 ms·

On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical ter

On the other side, Rust is a safe language that in real world uses unsafe blocks and unsafe libraries underneath (OpenSSL and other C libraries in practical terms). That is not safe either in practical terms. So there is always this discussion about putting C++ as an unsafe thing and it depens a lot, as you said, on how you use it. I use max warning level, warnings as errors, smart pointers, almost everything return by value and sanitizers. In Rust I have the advantage that libraries can be audited for unsafe blocks, but it still has unsafe and it will still use unsafe libraries in practice from C. So I always challenge these people that say Rust is safe. It is when it is. In rea life it is not perfect. I am pretty sure that the distance gap in safety from well-written C++ and Rust is, well, very small.

edflsafoiewq 3y ago
Certainly it is a question of degrees. But to say the gap in safety is very small is essentially to say Rust's lifetime system is close to zero-value. Unsafe code still exists, the goal is to localize it to small, auditable blocks. However safety often depends on non-local properties. For example, unchecked iteration over a vector requires we know the vector's lifetime exceeds the iteration lifetime, and that the backing buffer won't change. Rust's lifetime system allows this to be expressed, so the "critical zone" can be localized within a single block in the library implementation. If the library is correct, all consumers are safe. In C++, these cannot be expressed, so the critical zone for this safety guarantee is smeared across all code executed during the iteration. No consumer is guaranteed safe.
- germandiago 3y ago
  It is not that the borrow checker is zero value. But the borrow checker enters the game also depending on your code style. And when it does it gets quite viral with annotations and the like. That is why I like more a model like the one found in Hylo language. It sidesteps the rigidity of the borrow checker and it can do very well. Also, the code style I try to keep in C++ is quite "value-oriented" to avoid the typical lifetime pitfalls. Nowadays I try to use STL with debug mode but not escape iterators. I am actually considering using a library like Flux because I think that, as fast as the iterator model is, it is basically playing with fire. Flux seems to be very competent performance-wise and safer, besides compatible with ranges. I am quite happy with C++ at the moment. That does not mean I won't use Rust in the future. Who knows. I hope more work towards safety will be fone in C++. I would not want a borrow checker, but avoiding as many pitfalls as possible is a good thing. I always use compilers with the maximum warning level and warnings as errors. It is actually a good thing to do.
nequo 3y ago
> smart pointers, almost everything return by value and sanitizers All of these have runtime costs. What you describe is C++ forcing you to practice defensive programming in order to avoid costly debugging sessions. Rust’s borrow checker lets you avoid some of that runtime cost. You can pass around references much of the time without wrapping them in smart pointers. You don’t have to reference count and don’t have to malloc and free as much. And while bounds checking will be on, you can avoid some of those sanitizers too. You would get this benefit even if all code was unsafe in the libraries that you use, which of course it isn’t.

edflsafoiewq 3y ago

Certainly it is a question of degrees. But to say the gap in safety is very small is essentially to say Rust's lifetime system is close to zero-value. Unsafe code still exists, the goal is to localize it to small, auditable blocks. However safety often depends on non-local properties. For example, unchecked iteration over a vector requires we know the vector's lifetime exceeds the iteration lifetime, and that the backing buffer won't change. Rust's lifetime system allows this to be expressed, so the "critical zone" can be localized within a single block in the library implementation. If the library is correct, all consumers are safe. In C++, these cannot be expressed, so the critical zone for this safety guarantee is smeared across all code executed during the iteration. No consumer is guaranteed safe.

germandiago 3y ago
It is not that the borrow checker is zero value. But the borrow checker enters the game also depending on your code style. And when it does it gets quite viral with annotations and the like. That is why I like more a model like the one found in Hylo language. It sidesteps the rigidity of the borrow checker and it can do very well. Also, the code style I try to keep in C++ is quite "value-oriented" to avoid the typical lifetime pitfalls. Nowadays I try to use STL with debug mode but not escape iterators. I am actually considering using a library like Flux because I think that, as fast as the iterator model is, it is basically playing with fire. Flux seems to be very competent performance-wise and safer, besides compatible with ranges. I am quite happy with C++ at the moment. That does not mean I won't use Rust in the future. Who knows. I hope more work towards safety will be fone in C++. I would not want a borrow checker, but avoiding as many pitfalls as possible is a good thing. I always use compilers with the maximum warning level and warnings as errors. It is actually a good thing to do.

nequo 3y ago

> smart pointers, almost everything return by value and sanitizers All of these have runtime costs. What you describe is C++ forcing you to practice defensive programming in order to avoid costly debugging sessions. Rust’s borrow checker lets you avoid some of that runtime cost. You can pass around references much of the time without wrapping them in smart pointers. You don’t have to reference count and don’t have to malloc and free as much. And while bounds checking will be on, you can avoid some of those sanitizers too. You would get this benefit even if all code was unsafe in the libraries that you use, which of course it isn’t.