4 ms·

There is a fair point here that always gets brushed under the rug when discussing Rust vs X: Not having a GC means Rust forces you to think about memory allocat

There is a fair point here that always gets brushed under the rug when discussing Rust vs X: Not having a GC means Rust forces you to think about memory allocation throughout your program's logic & structure. That's a cost and many programs don't benefit from it at all. I had a Rust vs Haskell debate with a VPE at a company (he wanted to move to Rust.) He refused to acknowledge that the fact that Haskell has a GC is a big advantage over Rust for many applications (ours included.) It didn't help that he (somewhat arrogantly) fashioned himself a "systems engineer" and would've chosen C++ if he could've. It wasn't the crux of the argument (there's a lot more to those languages) and this VPE clearly wanted to move away from Haskell from day 1, but nonetheless - a very frustrating discussion to have. I'm not a Rust expert though so please correct me if there's a way to right large Rust programs without worrying about memory management.

jonex 7y ago
You can consistently use reference counting if you want to avoid thinking too much about memory management. Haskell vs Rust is probably a question of much more than a GC or not though.
- saagarjha 7y ago
  Reference counting requires extra syntax, though.
- whateveracct 7y ago
  > Haskell vs Rust is probably a question of much more than a GC or not though. Oh yes 100% My issue was that the discussion was disingenuous. GC was used to knock Haskell, but the cost of Rust's memory management model was not listed at all, thus painting an unbalanced pro/con picture (the scales were unbalanced!)
steveklabnik 7y ago
> I'm not a Rust expert though so please correct me if there's a way to right large Rust programs without worrying about memory management. That's the thing: it depends on what you mean by "think." At this point, I never think about memory in Rust; that's what the borrow checker is for. I write my code, usually it's just fine, sometimes there's an error and I go "oops" and fix it. Consider how you'd feel if someone said "ugh, you know, Haskell makes you think about types throughout your program's logic and structure. That's a cost many programs don't benefit from at all." I would assume, given that you like Haskell, you understand that types are a tool to help you write programs, and dealing with the compiler telling you about types isn't really a burden. Same with Rust. (lifetimes are types!)
- whateveracct 7y ago
  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.

jonex 7y ago

You can consistently use reference counting if you want to avoid thinking too much about memory management. Haskell vs Rust is probably a question of much more than a GC or not though.

saagarjha 7y ago
Reference counting requires extra syntax, though.
whateveracct 7y ago
> Haskell vs Rust is probably a question of much more than a GC or not though. Oh yes 100% My issue was that the discussion was disingenuous. GC was used to knock Haskell, but the cost of Rust's memory management model was not listed at all, thus painting an unbalanced pro/con picture (the scales were unbalanced!)

steveklabnik 7y ago

> I'm not a Rust expert though so please correct me if there's a way to right large Rust programs without worrying about memory management. That's the thing: it depends on what you mean by "think." At this point, I never think about memory in Rust; that's what the borrow checker is for. I write my code, usually it's just fine, sometimes there's an error and I go "oops" and fix it. Consider how you'd feel if someone said "ugh, you know, Haskell makes you think about types throughout your program's logic and structure. That's a cost many programs don't benefit from at all." I would assume, given that you like Haskell, you understand that types are a tool to help you write programs, and dealing with the compiler telling you about types isn't really a burden. Same with Rust. (lifetimes are types!)

whateveracct 7y ago
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.