4 ms·

Ownership reasoning is not a productivity history in a web server, where the lifetime of pretty much everything is a single request which is handled and then di

• zozbot234 6y ago
  The thing with ownership reasoning in Rust is that you can opt out of it whenever it makes sense to do so. If you really have "objects which live for indeterminate amounts of time and can be shared across views", that's not an increase in complexity; you just acknowledge that reasoning about ownership and sharing at compile time is not going to be feasible, write Rc<RefCell<…>> (with a documentation comment to that effect) and move on. All it takes is knowing where to add a tiny bit of boilerplate.
  • amelius 6y ago
    Yes, but you still can't write garbage collected code, which is tremendously useful in many circumstances. E.g. when using closures you really don't want to be thinking about memory allocation, and closures have proven a very useful concept. There are countless of reasons why the availability of a GC is a productivity booster. So I wouldn't describe Rust as a language that fits all domains and/or programmers well.
    • pasabagi 6y ago
      Isn't Rc<T> essentially garbage collection though?
      • amelius 6y ago
        Reference counting is a form of garbage collection, but with closures you often end up with circular dependencies, which is what RC can't handle.
      • ivanbakel 6y ago
        Not really. Reference counting doesn't prevent reference loops, and reference loops which aren't reachable from code are memory leaks - which is why garbage collectors do sweeps to detect unreachable memory. Rust doesn't have any kind of automatic cleanup of unreachable memory if you bypass the borrow-checker. Rust is a language for memory management. There is no way to write code in Rust without thinking about memory.
    • zozbot234 6y ago
      > when using closures you really don't want to be thinking about memory allocation You don't have to think about this with Rust - and you don't need a GC either. The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case.
      • amelius 6y ago
        > The borrow checker will make sure that your closure doesn't outlive the variables it captures, which is what you need for correctness in this case. No, the borrow checker will merely give you an error when your closure may outlive the captured variables. This is often not useful, and is an impediment to being productive. As a programmer you don't want to be solving the same boring problem of memory management over and over again, unless perhaps when you're doing really low-level stuff and there is no other option.
        • zozbot234 6y ago
          > This is often not useful How is it "not useful"? It's generally quite easy to resolve the ensuing lifetime problems: either use .clone() to copy the underlying values, or use Rc<>/Arc<> to provide shared control of the lifetimes involved. And it's far from a "boring problem"; quite often, being aware of how and why lifetime and mutability interact at a "low" level can inform higher-level design as well.
          • amelius 6y ago
            Reference counting doesn't solve all memory management problems. With closures you often end up with circular references. And yes, in probably 99% of cases you can actually find a way out of a memory management problem in Rust if you think hard enough. But my point is that quite often you don't want to think about memory management. Rust doesn't help here. Rust advertises that it solves memory management problems, but in reality that only holds up to a point. So use Rust for your OS or your low-level server, but don't think it is a panacea.