3 ms·

> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I don't think safety is a 1 dimensional spectrum

> I can't imagine any new systems programming languages gaining traction that aren't at least as safe as Rust. I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions. Rust invested a lot on _some dimension_ of safety, which is essentially static borrowing and aliasing. And the tradeoffs for this are numerous: Dynamic safety is either much harder in Rust (due to unsafe being vastly more dangerous and hard to get right vs say, a C program), or at the expense of performance (I.e. just Arc<Mutex<>> or copy everything). That also comes at the expense of an immense cognitive burden for the programmer. I see a lot of space for different tradeoffs on different dimensions of safety.

oneshtein 2y ago
> due to unsafe being vastly more dangerous and hard to get right vs say, a C program It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.
- cataphract 2y ago
  I don't think this is true. Rust has constraints that C/C++ doesn't have. For instance, it's undefined behavior to create more than one exclusive (mutable) reference to the same object or to create one where a shared reference already exists. This is not necessarily easy to ensure. The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).
  - mrcsd 2y ago
    I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.
    - cataphract 2y ago
      It's besides the point whether C pointers are more similar to Rust pointers or references. It's even true that pointers BY THEMSELVES have fewer constraints in Rust than in C . It's in the interaction between pointers and references that it's very easy to trigger undefined behavior in Rust. Besides the fact I already mentioned about the dangers of casting pointers to references, there's also the problem that pointers are only valid as long as no operations are done with references to the same object (no interleaving). On top of it, the autoborrowing rules make it so it's not always clear when a reference is being taken (and operated upon). So yes, in my opinion _unsafe_ Rust is significantly more difficult to get right than C.
- panstromek 2y ago
  Rust has stricter rules than C++. E.g. global mutable variables are way more dangerous in Rust than in C++ - just creating a reference to it can be immediate undefined behaviour.
  - oneshtein 2y ago
    In Rust, use UnsafeCell. In C++, multiple references to the same variable may cause «use after free» bug in it destructor.
- zozbot234 2y ago
  But only Rust uses its equivalent to C "restrict" wrt. its shared and mutable references (unless dealing with UnsafeCell<>) for alias analysis optimization. (In fact, this used to trigger bugs in LLVM because it was hard to test its aliasing optimizations with purely C code.)
  - vlovich123 2y ago
    It’s not just restrict. Rust indeed does have much more strict rules that even though at first glance seem similar to C, the optimizer is allowed to do weird things if you violate a lot harder to understand rules. This has been very well documented. For example, if I recall correctly it’s technically UB to cast to a *mut pointer unless the original variable was declared mut even if you have exclusive ownership over that object. There was a fantastic blog post describing a lot of these nuances but I can’t find it.
ajxs 2y ago
> I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions. Absolutely. This is evident in the different language features of Rust and Ada. At any rate, Rust has advanced the state of the art when it comes to memory safety. The next generation of programming languages are inevitably going to be compared against Rust. In the same way Rust has been compared against Ada. Especially given Rust's popularity. I imagine that if a next-generation 'systems language' can't at least match Rust's features, it won't achieve wider adoption.

oneshtein 2y ago

> due to unsafe being vastly more dangerous and hard to get right vs say, a C program It's not true. Both C (clang), C++, and Rust use same LLVM compiler, so both have same constraints in the unsafe mode. C/C++ developers just not care.

cataphract 2y ago
I don't think this is true. Rust has constraints that C/C++ doesn't have. For instance, it's undefined behavior to create more than one exclusive (mutable) reference to the same object or to create one where a shared reference already exists. This is not necessarily easy to ensure. The aliasing rules in C are much more lax: you only can't have several pointers of different types pointing to the same object, except if one of them is a character pointer (ignoring the restrict keyword, which is opt-in and rarely used).
- mrcsd 2y ago
  I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.
  - cataphract 2y ago
    It's besides the point whether C pointers are more similar to Rust pointers or references. It's even true that pointers BY THEMSELVES have fewer constraints in Rust than in C . It's in the interaction between pointers and references that it's very easy to trigger undefined behavior in Rust. Besides the fact I already mentioned about the dangers of casting pointers to references, there's also the problem that pointers are only valid as long as no operations are done with references to the same object (no interleaving). On top of it, the autoborrowing rules make it so it's not always clear when a reference is being taken (and operated upon). So yes, in my opinion _unsafe_ Rust is significantly more difficult to get right than C.
panstromek 2y ago
Rust has stricter rules than C++. E.g. global mutable variables are way more dangerous in Rust than in C++ - just creating a reference to it can be immediate undefined behaviour.
- oneshtein 2y ago
  In Rust, use UnsafeCell. In C++, multiple references to the same variable may cause «use after free» bug in it destructor.
zozbot234 2y ago
But only Rust uses its equivalent to C "restrict" wrt. its shared and mutable references (unless dealing with UnsafeCell<>) for alias analysis optimization. (In fact, this used to trigger bugs in LLVM because it was hard to test its aliasing optimizations with purely C code.)
- vlovich123 2y ago
  It’s not just restrict. Rust indeed does have much more strict rules that even though at first glance seem similar to C, the optimizer is allowed to do weird things if you violate a lot harder to understand rules. This has been very well documented. For example, if I recall correctly it’s technically UB to cast to a *mut pointer unless the original variable was declared mut even if you have exclusive ownership over that object. There was a fantastic blog post describing a lot of these nuances but I can’t find it.

ajxs 2y ago

> I don't think safety is a 1 dimensional spectrum (say from 0% to 100%). I view it more as a multidimensional thing, and tradeoffs between these dimensions. Absolutely. This is evident in the different language features of Rust and Ada. At any rate, Rust has advanced the state of the art when it comes to memory safety. The next generation of programming languages are inevitably going to be compared against Rust. In the same way Rust has been compared against Ada. Especially given Rust's popularity. I imagine that if a next-generation 'systems language' can't at least match Rust's features, it won't achieve wider adoption.