5 ms·

> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. As soon as you start writing large

> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. If you know that using global variable is often a bad idea, then you are, in some sense, worrying about lifetimes. I first learned this in the mid/late 90s as my Perl4 cgi scripts started to grow beyond about a screens worth of lines, and it really solidified into an almost unconscious background task as I wrote code once I started writing a lot of Perl5 apache mod_perl stuff a few years later. These days, I find myself experiencing slight cognitive dissonance writing tiny Arduino sketches with a bunch of global vars declared right up the top.

throw10920 2y ago
> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.
- kaoD 2y ago
  > Rust's object lifetimes, for all the performance gains you get Lifetimes are not about performance gains. They're about correct behavior under concurrency, which you have even on JS with async-await. Heck, let me correct that: even under programs without concurrency it's very easy introduce subtle bugs due to shared mutable state (something as simple as having a global mutable variable, you don't even need concurrency to mess that up, concurrency just introduces more issues like race conditions). > cognitive and development overhead that is simply not present in memory-managed languages No, the cognitive overhead is there, you're just ignoring it (and thus more likely to introduce subtle bugs). If anything, Rust lowers the cognitive overhead by taking care of that for me statically at borrow check time. Lifetimes are just types (literally). If you think lifetimes are cognitive overhead, so are regular types. Same argument could be used there since types are "cognitive and development overhead that is simply not present in dynamically typed languages". But I wouldn't write anything beyond a few thousand lines of code without them. When I write Rust I spend more time thinking about types than about lifetimes.
sshine 2y ago
> As soon as you start writing large enough programs ...or small enough programs! I fought a lot with the borrow checker when I started learning Rust, and then I learned to embrace it. The borrow checker only occasionally bugs me! As I write more embedded Rust and Rust for WebAssembly, removing implicit dynamic memory allocation forces me to think a lot about lifetimes again.

throw10920 2y ago

> As soon as you start writing large enough programs to start to learn/worry about variable scoping you are kind of "worrying about lifetimes though. Yes, to a much smaller extent. Rust's object lifetimes, for all the performance gains you get, add on a layer of additional cognitive and development overhead that is simply not present in memory-managed languages.

kaoD 2y ago
> Rust's object lifetimes, for all the performance gains you get Lifetimes are not about performance gains. They're about correct behavior under concurrency, which you have even on JS with async-await. Heck, let me correct that: even under programs without concurrency it's very easy introduce subtle bugs due to shared mutable state (something as simple as having a global mutable variable, you don't even need concurrency to mess that up, concurrency just introduces more issues like race conditions). > cognitive and development overhead that is simply not present in memory-managed languages No, the cognitive overhead is there, you're just ignoring it (and thus more likely to introduce subtle bugs). If anything, Rust lowers the cognitive overhead by taking care of that for me statically at borrow check time. Lifetimes are just types (literally). If you think lifetimes are cognitive overhead, so are regular types. Same argument could be used there since types are "cognitive and development overhead that is simply not present in dynamically typed languages". But I wouldn't write anything beyond a few thousand lines of code without them. When I write Rust I spend more time thinking about types than about lifetimes.

sshine 2y ago

> As soon as you start writing large enough programs ...or small enough programs! I fought a lot with the borrow checker when I started learning Rust, and then I learned to embrace it. The borrow checker only occasionally bugs me! As I write more embedded Rust and Rust for WebAssembly, removing implicit dynamic memory allocation forces me to think a lot about lifetimes again.