3 ms·

I think you should be given a choice whether to use GC. Now that's a killer feature.

by CmonDev 13y ago

ori_b 13y ago
That's nearly impossible to do well. The second you decide you want to use a library that relies on GC, you need to turn on GC for your whole app. There's no way to make that a local decision that I know of.
- CmonDev 13y ago
  I don't know much about Rust, but they do promise "optional task-local GC, safe pointer types with region analysis".
  - ori_b 13y ago
    So, while I'm far from an expert on Rust, that seems to me like they have separate heaps for separate tasks, and heap values are not shared. So, effectively, the tasks are roughly as isolated -- memorywise, at least -- as different OS level processes. This means that you can have different tasks that have GC turned on or off at the task level, because a GC'ed object will never "leak" across a process boundary. However, if you decide you want to parse JSON with your fancy new GC-using JSON library, you either need to put that into a separate task, or you need to enable GC in the task that calls into that library. That means that if you want GC-free code, you're going to have to be very careful about which libraries you can call into directly.
    - kibwen 13y ago
      That's a good point, and I bet that once Rust's ecosystem picks up it'll be a major differentiator to be able to claim that a given library uses no GC whatsoever (while also avoiding unsafe code, naturally). FWIW, Rust's stdlib tries to eliminate the use of GC whereever feasible. Cyclic data structures and persistent data structures are probably the only places where GC will end up being necessary.
simias 13y ago
Besides the practical issues of using GCs, I don't get them at a conceptual level. Keeping track of resources is a big part of any software development. You have keep track of open files, user sessions, network connections, memory mappings, all kinds of caches, many other things... and allocated memory. And for some reason this last kind of resource we don't want to keep track of "manually", instead we expect the computer to do that work for us. Why should we handle dynamically allocated memory as a special case of resource management? Don't get me wrong, I love having my computer do my work for me. I expect my compiler to be able to inline my code for me, optimize my arithmetic, unroll my loops and do all kinds of stuff for me. Stuff it's good at, stuff it can do at least as well as I can and probably much better. Memory management is not one of those things IMO. I feel like memory management is like pointers in C, it's a mythical dragon that scares those who have never used them beforehand. It's really not that hard or that much of an issue in the real world. If you really can't keep track of your memory allocations then the solution is not to add a GC, you have a major architectural problem.

I think you should be given a choice whether to use GC. Now that's a killer feature.

by CmonDev 13y ago

I think you should be given a choice whether to use GC. Now that's a killer feature.

ori_b 13y ago

That's nearly impossible to do well. The second you decide you want to use a library that relies on GC, you need to turn on GC for your whole app. There's no way to make that a local decision that I know of.

CmonDev 13y ago
I don't know much about Rust, but they do promise "optional task-local GC, safe pointer types with region analysis".
- ori_b 13y ago
  So, while I'm far from an expert on Rust, that seems to me like they have separate heaps for separate tasks, and heap values are not shared. So, effectively, the tasks are roughly as isolated -- memorywise, at least -- as different OS level processes. This means that you can have different tasks that have GC turned on or off at the task level, because a GC'ed object will never "leak" across a process boundary. However, if you decide you want to parse JSON with your fancy new GC-using JSON library, you either need to put that into a separate task, or you need to enable GC in the task that calls into that library. That means that if you want GC-free code, you're going to have to be very careful about which libraries you can call into directly.
  - kibwen 13y ago
    That's a good point, and I bet that once Rust's ecosystem picks up it'll be a major differentiator to be able to claim that a given library uses no GC whatsoever (while also avoiding unsafe code, naturally). FWIW, Rust's stdlib tries to eliminate the use of GC whereever feasible. Cyclic data structures and persistent data structures are probably the only places where GC will end up being necessary.

simias 13y ago

Besides the practical issues of using GCs, I don't get them at a conceptual level. Keeping track of resources is a big part of any software development. You have keep track of open files, user sessions, network connections, memory mappings, all kinds of caches, many other things... and allocated memory. And for some reason this last kind of resource we don't want to keep track of "manually", instead we expect the computer to do that work for us. Why should we handle dynamically allocated memory as a special case of resource management? Don't get me wrong, I love having my computer do my work for me. I expect my compiler to be able to inline my code for me, optimize my arithmetic, unroll my loops and do all kinds of stuff for me. Stuff it's good at, stuff it can do at least as well as I can and probably much better. Memory management is not one of those things IMO. I feel like memory management is like pointers in C, it's a mythical dragon that scares those who have never used them beforehand. It's really not that hard or that much of an issue in the real world. If you really can't keep track of your memory allocations then the solution is not to add a GC, you have a major architectural problem.