3 ms·

This isn't true in practice. When you don't have to worry about memory safety, your brain is freed up to worry about other kinds of bugs. The other bit of goo

This isn't true in practice. When you don't have to worry about memory safety, your brain is freed up to worry about other kinds of bugs. The other bit of good news is that the sorts of things Rust does to have memory safety also enable the systematic elimination of many other kinds of bugs. For example, iterator invalidation.

mgaunard 2y ago
For example, the easiest way to make programs avoid use-after-free errors is to never free things. Would you rather get a program that constantly use all of your RAM until you restart it, or one that consistently uses very little, but someone crashes in edge cases?
- sunshowers 2y ago
  I'd rather use a program that uses as little memory as possible and that also never crashes. With Rust you can just have both.
  - mgaunard 2y ago
    That's not really what happens. Most Rust code actually does whatever is easiest to get the borrow checker to stop complaining, including extending lifetime beyond the scope that is necessary, and putting reference counting everywhere.
    - sunshowers 2y ago
      I'm not one to boast, but at least my Rust code doesn't do that much. Feel free to have a look, basically all the professional Rust code I've ever written is free software. Rust is a lot better than GC languages at memory usage, and (because borrowing is actually safe) a bit better than C++.
  - kiitos 2y ago
    Sure, if you never use unsafe, or anything that uses unsafe, transitively.
    - sunshowers 2y ago
      Memory unsafety is a property of von Neumann architectures, and explicit unsafe limits the scope of damage significantly. I have made major contributions to several Rust projects that have collectively saved organizations over $100MM in production, if not more. I worry about lots of things, but crashes just aren't one of them.
- leni536 2y ago
  Good luck not releasing stack frames.
  - mgaunard 2y ago
    Talked like somebody that doesn't understand the stack at all. On Linux, the stack grows automatically and never shrinks.
    - leni536 2y ago
      Sure, the stack as storage never shrinks, but it's constantly reused for different kinds of objects. Having said that dynamic memory is also rarely given back to the OS, and you are lucky to get a segfault from a use-after-free there too. This is not the problem. The problem is accessing objects that are outside of their lifetime, not storage. The objects are gone, even if the storage might still be there.
      - mgaunard 2y ago
        That's not as big of a problem as using more resources than you need.
    - UncleMeat 2y ago
      Use-after-return is a subset of use-after-free bugs. Allocate a temporary on the stack, pass it by reference to somewhere that outlives that function, and then watch your program explode. No dynamic memory allocation at all.
      - kiitos 2y ago
        Escape analysis can easily determine if a temporary/local value that would by default be allocated on the stack outlives the function in which it was declared, and in that case can move the allocation to the heap instead.
        UncleMeat 2y ago

mgaunard 2y ago

For example, the easiest way to make programs avoid use-after-free errors is to never free things. Would you rather get a program that constantly use all of your RAM until you restart it, or one that consistently uses very little, but someone crashes in edge cases?

sunshowers 2y ago
I'd rather use a program that uses as little memory as possible and that also never crashes. With Rust you can just have both.
- mgaunard 2y ago
  That's not really what happens. Most Rust code actually does whatever is easiest to get the borrow checker to stop complaining, including extending lifetime beyond the scope that is necessary, and putting reference counting everywhere.
  - sunshowers 2y ago
    I'm not one to boast, but at least my Rust code doesn't do that much. Feel free to have a look, basically all the professional Rust code I've ever written is free software. Rust is a lot better than GC languages at memory usage, and (because borrowing is actually safe) a bit better than C++.
- kiitos 2y ago
  Sure, if you never use unsafe, or anything that uses unsafe, transitively.
  - sunshowers 2y ago
    Memory unsafety is a property of von Neumann architectures, and explicit unsafe limits the scope of damage significantly. I have made major contributions to several Rust projects that have collectively saved organizations over $100MM in production, if not more. I worry about lots of things, but crashes just aren't one of them.
leni536 2y ago
Good luck not releasing stack frames.
- mgaunard 2y ago
  Talked like somebody that doesn't understand the stack at all. On Linux, the stack grows automatically and never shrinks.
  - leni536 2y ago
    Sure, the stack as storage never shrinks, but it's constantly reused for different kinds of objects. Having said that dynamic memory is also rarely given back to the OS, and you are lucky to get a segfault from a use-after-free there too. This is not the problem. The problem is accessing objects that are outside of their lifetime, not storage. The objects are gone, even if the storage might still be there.
    - mgaunard 2y ago
      That's not as big of a problem as using more resources than you need.
  - UncleMeat 2y ago
    Use-after-return is a subset of use-after-free bugs. Allocate a temporary on the stack, pass it by reference to somewhere that outlives that function, and then watch your program explode. No dynamic memory allocation at all.
    - kiitos 2y ago
      Escape analysis can easily determine if a temporary/local value that would by default be allocated on the stack outlives the function in which it was declared, and in that case can move the allocation to the heap instead.
      - UncleMeat 2y ago