6 ms·

The claim was “leaks are hard to code by accident”. I agree with gp that this is false. Preventing leaks is explicitly not a goal of rust and making lifetimes

The claim was “leaks are hard to code by accident”. I agree with gp that this is false. Preventing leaks is explicitly not a goal of rust and making lifetimes correct often involves giving up and making unnecessary static lifetimes. I see this all the time in async rpc stream stuff.

lifthrasiir 2y ago
I think leaks are indeed harder to code by accident in non-async Rust, which was the original setting Rust was developed on. I wouldn't say it is absolutely hard (that really depends on the architectural complexity), but there seems some truth in that claim.
haileys 2y ago
When a type is 'static, it doesn’t mean it’s leaked for the lifetime of the program. It just means it owns everything it needs and doesn’t borrow anything. It will still free everything it owns when it is freed.
- n3t 2y ago
  https://doc.rust-lang.org/rust-by-example/scope/lifetime/static_lifetime.html#reference-lifetime https://doc.rust-lang.org/rust-by-example/scope/lifetime/sta... says: > As a reference lifetime 'static indicates that the data pointed to by the reference lives for the remaining lifetime of the running program.
  - tczMUFlmoNk 2y ago
    What your link says is correct about `&'static T`, a lifetime on a reference. What GP says is correct about `T: 'static`, a type constraint. They both use the "keyword" 'static, but in different senses.
    - littlestymaar 2y ago
      Yes, and IMHO this is one of the biggest design wart of Rust. T: 'unbounded would be much better.
      - phamilton 2y ago
        `'unbounded` isn't a bad idea. With my team when someone new to Rust hits the static type constraint I usually tell them an overly simplified "is not a reference" followed up with "The data does not have any constraints (or bounds) on its lifetime that this code needs to worry about." I don't know if `unbounded` would immediately be understood by someone new to Rust, but it captures that `T: 'static` is a negating assertion. I.e. it largely says what it can't be.
littlestymaar 2y ago
Leaks are as hard to do in Rust as with a GC though. That is, they aren't impossible and you'll eventually have to fight against one nasty one in your job, but it's far better than without a GC or borrowck.
- jakobnissen 2y ago
  I don't think that's right - in Rust, cycles of Rc or Arc will leak. In GC languages, cycles are properly deleted.
  - littlestymaar 2y ago
    Cycles with reference-counted pointers are how leaks are caused in Rust and it's specific to Rust, but GCs have their own sources of leaks and in my experience they occur roughly as frequently as cycles in Rust (rarely but not exceptionally either)

lifthrasiir 2y ago

I think leaks are indeed harder to code by accident in non-async Rust, which was the original setting Rust was developed on. I wouldn't say it is absolutely hard (that really depends on the architectural complexity), but there seems some truth in that claim.

haileys 2y ago

When a type is 'static, it doesn’t mean it’s leaked for the lifetime of the program. It just means it owns everything it needs and doesn’t borrow anything. It will still free everything it owns when it is freed.

n3t 2y ago
https://doc.rust-lang.org/rust-by-example/scope/lifetime/static_lifetime.html#reference-lifetime https://doc.rust-lang.org/rust-by-example/scope/lifetime/sta... says: > As a reference lifetime 'static indicates that the data pointed to by the reference lives for the remaining lifetime of the running program.
- tczMUFlmoNk 2y ago
  What your link says is correct about `&'static T`, a lifetime on a reference. What GP says is correct about `T: 'static`, a type constraint. They both use the "keyword" 'static, but in different senses.
  - littlestymaar 2y ago
    Yes, and IMHO this is one of the biggest design wart of Rust. T: 'unbounded would be much better.
    - phamilton 2y ago
      `'unbounded` isn't a bad idea. With my team when someone new to Rust hits the static type constraint I usually tell them an overly simplified "is not a reference" followed up with "The data does not have any constraints (or bounds) on its lifetime that this code needs to worry about." I don't know if `unbounded` would immediately be understood by someone new to Rust, but it captures that `T: 'static` is a negating assertion. I.e. it largely says what it can't be.

littlestymaar 2y ago

Leaks are as hard to do in Rust as with a GC though. That is, they aren't impossible and you'll eventually have to fight against one nasty one in your job, but it's far better than without a GC or borrowck.

jakobnissen 2y ago
I don't think that's right - in Rust, cycles of Rc or Arc will leak. In GC languages, cycles are properly deleted.
- littlestymaar 2y ago
  Cycles with reference-counted pointers are how leaks are caused in Rust and it's specific to Rust, but GCs have their own sources of leaks and in my experience they occur roughly as frequently as cycles in Rust (rarely but not exceptionally either)