3 ms·

Sum types are fantastic and I’ll join you singing their praises all day long. But this article is about rust’s memory model & memory safety - which is independe

Sum types are fantastic and I’ll join you singing their praises all day long. But this article is about rust’s memory model & memory safety - which is independent of sum types. Unsafe blocks in rust are the only place you can dereference pointers. There are whole classes of memory bugs which are impossible to code up in safe rust code because of this. As an example of how this helps, a couple years ago I was working on a complex & clever rope data structure. My code segfaulted - and I can count on one hand the number of times my rust code has ever done that. A segfault like that can only come from memory corruption or dereferencing invalid memory - both of which are only possible in unsafe code. And the bottom of the stack trace was a safe function, so I knew I’d corrupted memory somehow. These bugs are really hard to find in C - basically the worst case for debugging because the problem could be literally anywhere. But in rust I knew the bug was in one of only two unsafe blocks in the ~thousand or so lines of my library. And one of those blocks was executed not long before the crash. 5 minutes later I had found and fixed the bug. In C, I’ve had similar problems take hours to days to fix. Bugs like this aren’t possible at all in Go or C# because of their memory model. But in those languages you pay for safety by sacrificing performance. The rust I’ve written & benchmarked so far somehow faster than the equivalent C code. Which is pretty wild!

soulbadguy 3y ago
> These bugs are really hard to find in C - basically the worst case for debugging because the problem could be literally anywhere. > 5 minutes later I had found and fixed the bug. In C, I’ve had similar problems take hours to days to fix. Modern tooling like a memory synthesizer and good debugger makes this kind of debugging relatively easy. In some case, the bug would have been detected even before you run with proper warnings. > Bugs like this aren’t possible at all in Go or C# because of their memory model. Except in their respective FFI or unsafe block of code. > But in those languages you pay for safety by sacrificing performance. That's a bit of a strong statement. Even if we accept (i don't) the performance aspect, GC languages give more safety,convenience and dev prod. than rust and at a significantly less complexity overload. > As an example of how this helps, a couple years ago I was working on a complex & clever rope data structure. My code segfaulted - and I can count on one hand the number of times my rust code has ever done that. This might simply be an indication that you were using the wrong tools in the first language. Most native languages (D, C++ etc...) have facilities to avoid unsafe behavior. Use them.
- ReactiveJelly 3y ago
  I've never heard of memory synthesizers. I'll cede the point that some of Rust's advantages are merely psychological. But I would argue that most of us are tired, frustrated, and working on teams where we have neither the energy nor authority nor teaching experience to make everyone learn the right tools. I've had to teach some coworkers how to use a profiler. And then remind them to use it. Therefore mere psychological benefits still improve outcomes. It's easier to memorize "cargo run" than to memorize the vocabulary quizzes for Python or Kotlin tooling. (A gradle is used to serve soup. A wheel is part of a car.) Rust produces one binary by default, and I don't even have to think about how to bundle a runtime. That means I also don't need to teach anyone what Docker is. I have a hunch this actually matters. Everyone who's learning to program right now will be deep in their work in 20 years. So every software that's succeeded in my lifetime - JavaScript, Python, Unity 3D, etc., has succeeded by appealing to noobies and then lasting long enough that everyone likes it. In the very long term, a low barrier to entry might matter as much as a high skill ceiling.
  - jcranmer 3y ago
    > I've never heard of memory synthesizers. I assume it's a typo for memory sanitizer (i.e., ASAN).
    - soulbadguy 3y ago
      +1
- josephg 3y ago
  > Even if we accept (i don't) the performance aspect, GC languages give more safety,convenience and dev prod. than rust and at a significantly less complexity overload At the limit, I think the performance benefits of rust are pretty clear. The performance ceiling of rust seems to be pretty unambiguously higher than that of Go, Python, C#, javascript, etc. But yeah - no contest on rust being way harder to learn and use. I’ve been programming rust for years now, but I still reach for typescript when prototyping because I still find it much faster when making prototypes. Especially when async is involved. > This might simply be an indication that you were using the wrong tools in the first language. Most native languages (D, C++ etc...) have facilities to avoid unsafe behavior. Use them. Can you give some examples of those tools? The “first language” I mentioned above was C. What equivalent does C have to rust’s memory safety? Or C++ for that matter? Are smart pointers in C++ that ubiquitous and good that memory corruption is a thing of the past?
fnfjfk 3y ago
Oh I understand how safe helps and all, just wanted to sing Rust’s praises as a less low level memory-focused language too.
rstuart4133 3y ago
> Bugs like this aren’t possible at all in Go or C# As a point of order, such bugs are possible for Go. Eg, hashmap's behaviour becomes undefined if you access from multiple threads at the same time. Admittedly, that's a Go peculiarity. Making the programmer deal with concurrency on collections undoubtedly gets it a speed boost, but it's not the tradeoff most gc languages take. The beauty of Rust, is you don't need to trade speed or memory for concurrency.

soulbadguy 3y ago

> These bugs are really hard to find in C - basically the worst case for debugging because the problem could be literally anywhere. > 5 minutes later I had found and fixed the bug. In C, I’ve had similar problems take hours to days to fix. Modern tooling like a memory synthesizer and good debugger makes this kind of debugging relatively easy. In some case, the bug would have been detected even before you run with proper warnings. > Bugs like this aren’t possible at all in Go or C# because of their memory model. Except in their respective FFI or unsafe block of code. > But in those languages you pay for safety by sacrificing performance. That's a bit of a strong statement. Even if we accept (i don't) the performance aspect, GC languages give more safety,convenience and dev prod. than rust and at a significantly less complexity overload. > As an example of how this helps, a couple years ago I was working on a complex & clever rope data structure. My code segfaulted - and I can count on one hand the number of times my rust code has ever done that. This might simply be an indication that you were using the wrong tools in the first language. Most native languages (D, C++ etc...) have facilities to avoid unsafe behavior. Use them.

ReactiveJelly 3y ago
I've never heard of memory synthesizers. I'll cede the point that some of Rust's advantages are merely psychological. But I would argue that most of us are tired, frustrated, and working on teams where we have neither the energy nor authority nor teaching experience to make everyone learn the right tools. I've had to teach some coworkers how to use a profiler. And then remind them to use it. Therefore mere psychological benefits still improve outcomes. It's easier to memorize "cargo run" than to memorize the vocabulary quizzes for Python or Kotlin tooling. (A gradle is used to serve soup. A wheel is part of a car.) Rust produces one binary by default, and I don't even have to think about how to bundle a runtime. That means I also don't need to teach anyone what Docker is. I have a hunch this actually matters. Everyone who's learning to program right now will be deep in their work in 20 years. So every software that's succeeded in my lifetime - JavaScript, Python, Unity 3D, etc., has succeeded by appealing to noobies and then lasting long enough that everyone likes it. In the very long term, a low barrier to entry might matter as much as a high skill ceiling.
- jcranmer 3y ago
  > I've never heard of memory synthesizers. I assume it's a typo for memory sanitizer (i.e., ASAN).
  - soulbadguy 3y ago
    +1
josephg 3y ago
> Even if we accept (i don't) the performance aspect, GC languages give more safety,convenience and dev prod. than rust and at a significantly less complexity overload At the limit, I think the performance benefits of rust are pretty clear. The performance ceiling of rust seems to be pretty unambiguously higher than that of Go, Python, C#, javascript, etc. But yeah - no contest on rust being way harder to learn and use. I’ve been programming rust for years now, but I still reach for typescript when prototyping because I still find it much faster when making prototypes. Especially when async is involved. > This might simply be an indication that you were using the wrong tools in the first language. Most native languages (D, C++ etc...) have facilities to avoid unsafe behavior. Use them. Can you give some examples of those tools? The “first language” I mentioned above was C. What equivalent does C have to rust’s memory safety? Or C++ for that matter? Are smart pointers in C++ that ubiquitous and good that memory corruption is a thing of the past?

fnfjfk 3y ago

Oh I understand how safe helps and all, just wanted to sing Rust’s praises as a less low level memory-focused language too.

rstuart4133 3y ago

> Bugs like this aren’t possible at all in Go or C# As a point of order, such bugs are possible for Go. Eg, hashmap's behaviour becomes undefined if you access from multiple threads at the same time. Admittedly, that's a Go peculiarity. Making the programmer deal with concurrency on collections undoubtedly gets it a speed boost, but it's not the tradeoff most gc languages take. The beauty of Rust, is you don't need to trade speed or memory for concurrency.