4 ms·

> force you to do memory management This is not my experience at all. I never think about memory management when I'm writing Rust, let alone am I "doing it" (a

by bsnnkv 2y ago

> force you to do memory management This is not my experience at all. I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Your second comment is a very weird sentence that is very difficult for me to grok.

throw10920 2y ago
> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis in your editor? You certainly didn't explain it.
- bsnnkv 2y ago
  > Worrying about lifetimes Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building. If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
  - throw10920 2y ago
    > Again, not my experience at all. I simply don't think about any of that stuff when I write Rust Your subjective perception is not reality. You have to think about it, or your programs will be incorrect. The mental load may be low to an experience Rust programmer, but it is there, and it's very intrusive to Rust beginners like myself. > If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube. That's not relevant. Lack of external indicators of cognitive load does not mean that it's not happening.
    - adastra22 2y ago
      In most Rust code I write, I never have to use an explicit lifetime marker other than ‘static (which is more of a global const thing). It’s really only something you have to worry about under certain conditions.
    - bsnnkv 2y ago
      Glad I noped out of this particular bad-faith subthread last night. I am pleasantly surprised to see however that this unfortunate subthread produced interesting and well-intentioned comments from others.
      - throw10920 2y ago
        Perhaps consider not violating the literal letter of the HN guidelines: > Assume good faith. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html You have no idea what's going on it my head, yet you choose to believe that you do as a result of me countering your arguments. This is a great example of why the Rust community has a bad reputation.
    - evilduck 2y ago
      > Your subjective perception is not reality. A self-whoosh? I'd consider myself a Rust beginner (e.g. I've completed Rustlings, I have written a handful data parse and transform programs on my own and a couple of web servers to benchmark stuff, nothing grandiose) and lifetimes haven't ever gotten in my way, they usually get automatically inferred or the compiler tells you what is wrong and how to fix it. Most code examples and docs I've worked with, like Rust By Example, Rust Cookbook, even Rocket's docs, don't even feature code with a lifetime annotation or they don't really need you as a developer to do anything with them other than copy and paste if necessary. This is the smallest hill to die on.
  - fastball 2y ago
    > I'm an incredibly lazy developer > Watch the literally hundreds of hours of me live coding in Rust on YouTube Your definition of "lazy" seems quite different from the standard definition. In my view, the average "incredibly lazy developer" of 2024 tries to have an LLM write most code for them (probably in JS/TS/Python), doesn't notice the subtle bugs introduced by said LLM, and ships straight to prod. If using an LLM fails, they go back to StackOverflow to look for an answer that they can copy-paste. When that fails they give up and ask a less lazy developer for help. At no point in this process did they read the documentation for the language/framework/etc they are using to accomplish their goals.
- bigiain 2y ago
  > 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.
- selfmodruntime 2y ago
  > Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. That's why I just... don't. I use `clone` liberally. That's it.
kaba0 2y ago
A better metric for whether you think about it or not would be at refactor time. In Java, you can just move something around in any way or shape, change its lifetime semantics very liberally (e.g. make it have a single instance, or make every thread have its own, or make it have its own instance of X as a field, or just use a shared one), and it will compile without a word and the runtime will handle it. In rust, in my experience (though it is surely significantly less than Yours), these kind of refactors actually require code changes at almost every location, and might recursively cause further such issues. I think there is a sort of bias here as well, that people kind of like this kind of refactor where the tooling readily shows you the exact error and it may not be too difficult to solve each case, so this might not register as annoying, but quite obviously a stricter lifetime system will have to have some downsides as well.

by bsnnkv 2y ago

throw10920 2y ago

> I never think about memory management when I'm writing Rust, let alone am I "doing it" (active voice). Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. My second paragraph is pointing out that "where I can open something like Notepad without an LSP or highlighting" is a strange qualifier. Why does it matter if you don't have semantic analysis in your editor? You certainly didn't explain it.

bsnnkv 2y ago
> Worrying about lifetimes Again, not my experience at all. I simply don't think about any of that stuff when I write Rust, all my mental energy can safely go towards working on whatever I'm building. If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube.
- throw10920 2y ago
  > Again, not my experience at all. I simply don't think about any of that stuff when I write Rust Your subjective perception is not reality. You have to think about it, or your programs will be incorrect. The mental load may be low to an experience Rust programmer, but it is there, and it's very intrusive to Rust beginners like myself. > If you don't believe me, you're welcome to watch the literally hundreds of hours of me live coding in Rust on YouTube. That's not relevant. Lack of external indicators of cognitive load does not mean that it's not happening.
  - adastra22 2y ago
    In most Rust code I write, I never have to use an explicit lifetime marker other than ‘static (which is more of a global const thing). It’s really only something you have to worry about under certain conditions.
  - bsnnkv 2y ago
    Glad I noped out of this particular bad-faith subthread last night. I am pleasantly surprised to see however that this unfortunate subthread produced interesting and well-intentioned comments from others.
    - throw10920 2y ago
      Perhaps consider not violating the literal letter of the HN guidelines: > Assume good faith. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html You have no idea what's going on it my head, yet you choose to believe that you do as a result of me countering your arguments. This is a great example of why the Rust community has a bad reputation.
  - evilduck 2y ago
    > Your subjective perception is not reality. A self-whoosh? I'd consider myself a Rust beginner (e.g. I've completed Rustlings, I have written a handful data parse and transform programs on my own and a couple of web servers to benchmark stuff, nothing grandiose) and lifetimes haven't ever gotten in my way, they usually get automatically inferred or the compiler tells you what is wrong and how to fix it. Most code examples and docs I've worked with, like Rust By Example, Rust Cookbook, even Rocket's docs, don't even feature code with a lifetime annotation or they don't really need you as a developer to do anything with them other than copy and paste if necessary. This is the smallest hill to die on.
- fastball 2y ago
  > I'm an incredibly lazy developer > Watch the literally hundreds of hours of me live coding in Rust on YouTube Your definition of "lazy" seems quite different from the standard definition. In my view, the average "incredibly lazy developer" of 2024 tries to have an LLM write most code for them (probably in JS/TS/Python), doesn't notice the subtle bugs introduced by said LLM, and ships straight to prod. If using an LLM fails, they go back to StackOverflow to look for an answer that they can copy-paste. When that fails they give up and ask a less lazy developer for help. At no point in this process did they read the documentation for the language/framework/etc they are using to accomplish their goals.
bigiain 2y ago
> 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.
selfmodruntime 2y ago
> Worrying about lifetimes is memory management that is unnecessary with GC languages and directly increases cognitive load. That's why I just... don't. I use `clone` liberally. That's it.

kaba0 2y ago

A better metric for whether you think about it or not would be at refactor time. In Java, you can just move something around in any way or shape, change its lifetime semantics very liberally (e.g. make it have a single instance, or make every thread have its own, or make it have its own instance of X as a field, or just use a shared one), and it will compile without a word and the runtime will handle it. In rust, in my experience (though it is surely significantly less than Yours), these kind of refactors actually require code changes at almost every location, and might recursively cause further such issues. I think there is a sort of bias here as well, that people kind of like this kind of refactor where the tooling readily shows you the exact error and it may not be too difficult to solve each case, so this might not register as annoying, but quite obviously a stricter lifetime system will have to have some downsides as well.