5 ms·

So the same argument that is made against the "mythical C programmer that never makes memory corruption mistakes" is also valid for the mythical Rust developer

by pml1 6y ago

So the same argument that is made against the "mythical C programmer that never makes memory corruption mistakes" is also valid for the mythical Rust developer that never makes mistakes in unsafe code... It's two sides of the same coin.

monocasa 6y ago
Except unsafe blocks are rare and heavily marked as "this is where the unsafeness is".
- pml1 6y ago
  It won't be rare in driver code.
  - monocasa 6y ago
    It absolutely will, particularly in USB code. USB devices other than host controllers don't have memory mapped registers for instance, it's basically a network protocol.
  - ComputerGuru 6y ago
    I’ve written bare metal code for rust that does networking and had only a handful of `unsafe` usages, and none after startup/init was completed. It’s actually really incredible how far “simple” shared-read-vs-exclusive-write bound checking and a very strict (but capable/likely Turing complete) type system can take you.
samsari 6y ago
Except in rust unsafe code is very much not the norm, and much easier keep an eye on. Anyone writing rust worth their salt should be paying 5 times as close attention to every line of unsafe code for exactly this reason.
spieglt 6y ago
But overall the two situations aren't nearly equivalent. Writing C, you're constantly at risk of making these mistakes. Writing Rust, you can keep the vast majority of your code safe and more closely examine the smaller unsafe area for memory errors. (In driver development, you may have to use more "unsafe" than for application development, but this doesn't negate the benefits. Also the compiler output is much more helpful.)
- pml1 6y ago
  > Writing C, you're constantly at risk of making these mistakes. Writing Rust, you can keep the vast majority of your code safe and more closely examine the smaller unsafe area for memory errors. I think this is a fallacy...The majority of C code doesn't manipulate pointers either. The point is, the moment that you have _any_ unsafe code (C or Rust), it's a question of time before you will have some bugs, especially if you have a very large number of people working on the same code base...you may be extra careful, maybe the next guy is not...Rust is not going to magically solve these problems for unsafe code...
  - toyg 6y ago
    I think you guys are debating whether perfect is the enemy of the good. Rust will not make your code magically bugfree (this is basically impossible by definition), but it will undoubtedly reduce the number of bugs in a very significant way and nudge you towards better code.
    - spieglt 6y ago
      Exactly, it's a difference in degree, not in kind. Rust isn't perfect with regard to memory errors, it's just massively better than C. I don't think pml1 will be convinced, but I've been working on a C project lately and I've never appreciated Rust's memory virtues so much as when using valgrind to debug my string and hashmap implementations. Chased a memory leak for two evenings that was just having free() a few lines off in a function. Stupidly simple error, but my eyes just glazed over the code from having read it so many times. In Rust, it never would've happened because the borrow checker would've dropped the memory at the proper time.

by pml1 6y ago

monocasa 6y ago

Except unsafe blocks are rare and heavily marked as "this is where the unsafeness is".

pml1 6y ago
It won't be rare in driver code.
- monocasa 6y ago
  It absolutely will, particularly in USB code. USB devices other than host controllers don't have memory mapped registers for instance, it's basically a network protocol.
- ComputerGuru 6y ago
  I’ve written bare metal code for rust that does networking and had only a handful of `unsafe` usages, and none after startup/init was completed. It’s actually really incredible how far “simple” shared-read-vs-exclusive-write bound checking and a very strict (but capable/likely Turing complete) type system can take you.

samsari 6y ago

Except in rust unsafe code is very much not the norm, and much easier keep an eye on. Anyone writing rust worth their salt should be paying 5 times as close attention to every line of unsafe code for exactly this reason.

spieglt 6y ago

But overall the two situations aren't nearly equivalent. Writing C, you're constantly at risk of making these mistakes. Writing Rust, you can keep the vast majority of your code safe and more closely examine the smaller unsafe area for memory errors. (In driver development, you may have to use more "unsafe" than for application development, but this doesn't negate the benefits. Also the compiler output is much more helpful.)

pml1 6y ago
> Writing C, you're constantly at risk of making these mistakes. Writing Rust, you can keep the vast majority of your code safe and more closely examine the smaller unsafe area for memory errors. I think this is a fallacy...The majority of C code doesn't manipulate pointers either. The point is, the moment that you have _any_ unsafe code (C or Rust), it's a question of time before you will have some bugs, especially if you have a very large number of people working on the same code base...you may be extra careful, maybe the next guy is not...Rust is not going to magically solve these problems for unsafe code...
- toyg 6y ago
  I think you guys are debating whether perfect is the enemy of the good. Rust will not make your code magically bugfree (this is basically impossible by definition), but it will undoubtedly reduce the number of bugs in a very significant way and nudge you towards better code.
  - spieglt 6y ago
    Exactly, it's a difference in degree, not in kind. Rust isn't perfect with regard to memory errors, it's just massively better than C. I don't think pml1 will be convinced, but I've been working on a C project lately and I've never appreciated Rust's memory virtues so much as when using valgrind to debug my string and hashmap implementations. Chased a memory leak for two evenings that was just having free() a few lines off in a function. Stupidly simple error, but my eyes just glazed over the code from having read it so many times. In Rust, it never would've happened because the borrow checker would've dropped the memory at the proper time.