3 ms·
I wouldn't call GC "poison", but in a lot of domains it is a severe limitation. I don't see any GC language unseating C/C++ very soon, and perhaps never. Clear
by jeffdavis 7y ago
I wouldn't call GC "poison", but in a lot of domains it is a severe limitation. I don't see any GC language unseating C/C++ very soon, and perhaps never.
Clearly GC has achieved a ton. However, I am starting to wonder whether it will hang on to that success, or whether new language designs that don't need it will gain a lot of ground back.
GC, in a way, seems like a shortcut to avoid reasoning about lifetimes, and sometimes taking that shortcut comes back to bite. If it becomes easy enough to get help from the compiler, maybe we just don't need GC any more?
Obviously far-fetched, but interesting to think about.
- pjmlp 7y agoYet C++ community has adopted RC on the standard library, COM/UWP uses RC, and the most sucessful AAA game engine middleware uses a C++ tracing GC. And yes, RC is a GC implementation algorithm as per CS reference papers and notable books. C might never come close to any form of authomatic memory management, but in a couple of decades it will be relegated to surviving UNIX clone deployments.
- pfdietz 7y agoGC is a way to let the computer do something so we don't have to think about it. This is a GOOD THING. It's what using computers properly is all about. The idea that there's some sort of virtue in doing this reasoning manually just baffles me. It's like objecting to compilers because it's better if human string together the opcodes.
- jeffdavis 7y agoSee Rust for an example where you don't need to do the work manually, but there's no GC either. The problem with GC is that it's a runtime solution, which has all sorts of annoying problems (like interacting with other languages and runtimes).
- pfdietz 7y agoRust either restricts what you can do with the pointers that don't own their referents, or it opens itself to reference of freed objects bugs. A system with proper GC would not have this problem.