6 ms·

https://news.ycombinator.com/item?id=32276580#:~:text=One%20of%20the%20biggest%20issues,increment%20the%20object's%20reference%20count https://news.ycombinator.

by hu3 2y ago

https://news.ycombinator.com/item?id=32276580#:~:text=One%20of%20the%20biggest%20issues,increment%20the%20object's%20reference%20count https://news.ycombinator.com/item?id=32276580#:~:text=One%20....

steveklabnik 2y ago
You don’t do this in Rust. Up u can take a normal &T into something held by an Rc<T>. The count will not be touched. It’s only when you need an additional owning reference that you call clone() and increment the count, or when one of the owners goes out of scope, and Drop decrements the count. But for non-owning cases, which are many of them in most code, the count stays the same.
- hu3 2y ago
  That has a cost both to the compiler and to the developer. It's not a free win.
  - steveklabnik 2y ago
    It’s part of the standard library, not the language, so it’s not really a cost to the compiler. And this just uses all the same rules as normal Rust code, so like, sure, to use features you have to know them, but I find it a bit silly to frame that as a “cost.” If that’s a cost, so is literally everything. Anyway my main point is just that you have less refount traffic than in other implementations.
    - hu3 2y ago
      If were going down the calling silly route, I'd rather categorize handwaving of Rusts additional complexities by their community as silly. If "everything has a cost" anyway we might as well code is assembly for optimal performance. But no, because nuances and differences of cognitive load during development can be significant. And so does compilation speed. It's arguably much easier to code with a GC and language adoption reflects that.
      - cesarb 2y ago
        > I'd rather categorize handwaving of Rusts additional complexities by their community as silly. I believe what steveklabnik meant, was that all this extra complexity (the borrow checker) already exists in the language for other reasons. It's not an additional cost to the compiler or the developer when using the reference-counted types (Rc or Arc).
        steveklabnik 2y ago
        That's correct. I thought we were talking specifically about refcount traffic, not about broader issues.
- steveklabnik 2y ago
  "Up u" should be "You", I don't know why my phone autocorrected this way. Too late to edit now!

by hu3 2y ago

https://news.ycombinator.com/item?id=32276580#:~:text=One%20of%20the%20biggest%20issues,increment%20the%20object's%20reference%20count https://news.ycombinator.com/item?id=32276580#:~:text=One%20....

steveklabnik 2y ago

You don’t do this in Rust. Up u can take a normal &T into something held by an Rc<T>. The count will not be touched. It’s only when you need an additional owning reference that you call clone() and increment the count, or when one of the owners goes out of scope, and Drop decrements the count. But for non-owning cases, which are many of them in most code, the count stays the same.

hu3 2y ago
That has a cost both to the compiler and to the developer. It's not a free win.
- steveklabnik 2y ago
  It’s part of the standard library, not the language, so it’s not really a cost to the compiler. And this just uses all the same rules as normal Rust code, so like, sure, to use features you have to know them, but I find it a bit silly to frame that as a “cost.” If that’s a cost, so is literally everything. Anyway my main point is just that you have less refount traffic than in other implementations.
  - hu3 2y ago
    If were going down the calling silly route, I'd rather categorize handwaving of Rusts additional complexities by their community as silly. If "everything has a cost" anyway we might as well code is assembly for optimal performance. But no, because nuances and differences of cognitive load during development can be significant. And so does compilation speed. It's arguably much easier to code with a GC and language adoption reflects that.
    - cesarb 2y ago
      > I'd rather categorize handwaving of Rusts additional complexities by their community as silly. I believe what steveklabnik meant, was that all this extra complexity (the borrow checker) already exists in the language for other reasons. It's not an additional cost to the compiler or the developer when using the reference-counted types (Rc or Arc).
      - steveklabnik 2y ago
        That's correct. I thought we were talking specifically about refcount traffic, not about broader issues.
steveklabnik 2y ago
"Up u" should be "You", I don't know why my phone autocorrected this way. Too late to edit now!