5 ms·

Exactly. Ownership/lifetimes exist in almost every mainstream PL (anywhere where you can have any sort of references + mutability). It's just people pretend it

by dpc_pw 7y ago

Exactly. Ownership/lifetimes exist in almost every mainstream PL (anywhere where you can have any sort of references + mutability). It's just people pretend it doesn't, and hope everything is going to be fine. And when you bring it in front of their consciousness they scream in panic, like it didn't exist before. Once you internalize Rust ownership rules, they are almost effortless and you see and obey them in any code in any PL you happen to be programming in.

weberc2 7y ago
Most languages have a GC so there really is no ownership to pretend away (if you like, everything is owned by the GC). Rust can be super cool without inventing fake problems for other languages.
- sanxiyn 7y ago
  How is it a fake problem? Uber is copying slices it doesn't need to copy, suffering significant performance penalty, because it is too error prone in Go. Rust completely prevents this error.
  - weberc2 7y ago
    Ownership is different than mutability. Yes, immutability would prevent those errors.
    - rictic 7y ago
      The point is that ownership also prevents these errors. If there are never two simultaneous mutable references to something, then you can get the advantages of immutable data structures without paying the performance penalty.
      - weberc2 7y ago
        We’re having a semantic debate. Ownership appears to mean something different to Rust folks, which is fine. I agree that Rust’s borrow checker (what you appear to be referring to as ownership or the enforcer thereof) prevents errors and is generally very cool. It’s just not what I understand ownership to mean.
  - grumpydba 7y ago
    It's a trade-off. Programmer's productivity versus theorically perfect ownership handling. I think that rust fills the needs of applications with extreme requirements. A browser is in that niche. Not all software is. Thus most of the time you don't have to inflict yourself the pain to work with it.
- dpc_pw 7y ago
  I'm sorry, but that is a naive misconception. "everything is owned by the GC" is a sign of not understanding concept of ownership, BTW. GC is not an actor in the system, so does not participate in the ownership. A Java finalizers might kind of do stuff, but that's when all references are gone, so they have exclusive ownership. Anyway... Languages with GC still do have ownership. It is just defaulting to be the most problematic case of "shared ownership" everywhere. Shared ownership is only worry-free if you don't ever modify data. Which is possible, but actually harder and more constraining to implement in a practical software (especially if you care about any performance). So then you either have to synchronize everything with mutexes, and figure out a way to not deadlock yourself on every step (also hard), or you have to implicitly track ownership and decide who can and when mutate the data, which is exactly what Rust would make you do, but this time you get no compiler help. The only reason people don't notice that is because they do it incorrectly and it works most of the time, so they are unaware. There is no escape from it - one has to figure out ownership with a GC or without it, because GC has nothing to do with ownership. It only reclaims memory after all references are gone. That's it. That is actually very, very little improvement.
  - blub 7y ago
    "The only reason people don't notice that is because they do it incorrectly and it works most of the time, so they are unaware." Ironically, that's Rust biggest problem: not using perfect ownership management works for most software most of the time and that's good enough for most people and companies. You probably can't sell ownership management as a feature. The only thing that Rust can sell and that makes sense is "it won't crash" + "it's fast", but then there's a lot of other languages that have the first property and the second is not very appreciated, as seen in the rise of so-called Electron apps and web apps in general.
    - dpc_pw 7y ago
      Sure. SWE is not a first industry where you can get away with cutting corners or straight incompetence. And some people are going to write a code taking care of ownership by experience, skill, etc. and they don't need Rust. They might not know they are taking care of ownership, and yet do it correctly. Rust is only formalizing and verifying it. I think in time more and more people and teams will discover that doing stuff with Rust is just cheaper and more productive. You learn ownership once, you get great results ever after.

by dpc_pw 7y ago

weberc2 7y ago

Most languages have a GC so there really is no ownership to pretend away (if you like, everything is owned by the GC). Rust can be super cool without inventing fake problems for other languages.

sanxiyn 7y ago
How is it a fake problem? Uber is copying slices it doesn't need to copy, suffering significant performance penalty, because it is too error prone in Go. Rust completely prevents this error.
- weberc2 7y ago
  Ownership is different than mutability. Yes, immutability would prevent those errors.
  - rictic 7y ago
    The point is that ownership also prevents these errors. If there are never two simultaneous mutable references to something, then you can get the advantages of immutable data structures without paying the performance penalty.
    - weberc2 7y ago
      We’re having a semantic debate. Ownership appears to mean something different to Rust folks, which is fine. I agree that Rust’s borrow checker (what you appear to be referring to as ownership or the enforcer thereof) prevents errors and is generally very cool. It’s just not what I understand ownership to mean.
- grumpydba 7y ago
  It's a trade-off. Programmer's productivity versus theorically perfect ownership handling. I think that rust fills the needs of applications with extreme requirements. A browser is in that niche. Not all software is. Thus most of the time you don't have to inflict yourself the pain to work with it.
dpc_pw 7y ago
I'm sorry, but that is a naive misconception. "everything is owned by the GC" is a sign of not understanding concept of ownership, BTW. GC is not an actor in the system, so does not participate in the ownership. A Java finalizers might kind of do stuff, but that's when all references are gone, so they have exclusive ownership. Anyway... Languages with GC still do have ownership. It is just defaulting to be the most problematic case of "shared ownership" everywhere. Shared ownership is only worry-free if you don't ever modify data. Which is possible, but actually harder and more constraining to implement in a practical software (especially if you care about any performance). So then you either have to synchronize everything with mutexes, and figure out a way to not deadlock yourself on every step (also hard), or you have to implicitly track ownership and decide who can and when mutate the data, which is exactly what Rust would make you do, but this time you get no compiler help. The only reason people don't notice that is because they do it incorrectly and it works most of the time, so they are unaware. There is no escape from it - one has to figure out ownership with a GC or without it, because GC has nothing to do with ownership. It only reclaims memory after all references are gone. That's it. That is actually very, very little improvement.
- blub 7y ago
  "The only reason people don't notice that is because they do it incorrectly and it works most of the time, so they are unaware." Ironically, that's Rust biggest problem: not using perfect ownership management works for most software most of the time and that's good enough for most people and companies. You probably can't sell ownership management as a feature. The only thing that Rust can sell and that makes sense is "it won't crash" + "it's fast", but then there's a lot of other languages that have the first property and the second is not very appreciated, as seen in the rise of so-called Electron apps and web apps in general.
  - dpc_pw 7y ago
    Sure. SWE is not a first industry where you can get away with cutting corners or straight incompetence. And some people are going to write a code taking care of ownership by experience, skill, etc. and they don't need Rust. They might not know they are taking care of ownership, and yet do it correctly. Rust is only formalizing and verifying it. I think in time more and more people and teams will discover that doing stuff with Rust is just cheaper and more productive. You learn ownership once, you get great results ever after.