3 ms·

I get what you're saying, but does every program benefit from tracking & managing lifetime of every object? It is clearly beneficial for plenty of programs (Rus

I get what you're saying, but does every program benefit from tracking & managing lifetime of every object? It is clearly beneficial for plenty of programs (Rust is clearly best-in-class imo for non-GC programming) but is it for all? And Haskell's types aren't necessarily what you want either (I still write bash and python and go for a reason!), but I'm guessing they're more generally applicable than lifetimes. I would love to be wrong & learn more though :)

steveklabnik 7y ago
In the same way that you still find bash and python and go useful, I would agree that not every program needs Rust. > I'm guessing [types are] generally more applicable than lifetimes. I think this is an open question! A lot of people argue (you can see some of it in this thread) that Rust's rules teach them a certain programming style that carries over into other languages.
AnimalMuppet 7y ago
If memory is the only resource you have to worry about, then garbage collection is (usually) fine. If you have to worry about file handles, sockets, semaphores, and the like, then GC solves 90% of the problem (memory), but usually leaves you worse off for dealing with the other resources. Why does it usually leave you worse off? Because, since it's garbage collected, the language usually doesn't see the need to also provide a good way for the programmer to manage lifetimes, because, hey, we've got garbage collection, so why would they need to? The result is that the programmer has no help at all with the other resources. So that's where I think the line is. Do you just have memory to worry about? Or do you have other resources as well? And, to be clear: Yes, if you only have memory to worry about, garbage collection is fabulous. A whole set of problems just... goes away. It's very freeing.
- whateveracct 7y ago
  Thank you - this clears stuff up. I see now how lifetimes provide a tool to solve a very important class of problems. I know Haskell is trying to get Linear Types for those purposes (with a paper + working ghc branch) but even those are going to take time to get nice imo.

steveklabnik 7y ago

In the same way that you still find bash and python and go useful, I would agree that not every program needs Rust. > I'm guessing [types are] generally more applicable than lifetimes. I think this is an open question! A lot of people argue (you can see some of it in this thread) that Rust's rules teach them a certain programming style that carries over into other languages.

AnimalMuppet 7y ago

If memory is the only resource you have to worry about, then garbage collection is (usually) fine. If you have to worry about file handles, sockets, semaphores, and the like, then GC solves 90% of the problem (memory), but usually leaves you worse off for dealing with the other resources. Why does it usually leave you worse off? Because, since it's garbage collected, the language usually doesn't see the need to also provide a good way for the programmer to manage lifetimes, because, hey, we've got garbage collection, so why would they need to? The result is that the programmer has no help at all with the other resources. So that's where I think the line is. Do you just have memory to worry about? Or do you have other resources as well? And, to be clear: Yes, if you only have memory to worry about, garbage collection is fabulous. A whole set of problems just... goes away. It's very freeing.

whateveracct 7y ago
Thank you - this clears stuff up. I see now how lifetimes provide a tool to solve a very important class of problems. I know Haskell is trying to get Linear Types for those purposes (with a paper + working ghc branch) but even those are going to take time to get nice imo.