As you rightly observe, there is no 'perfect' GC. Every time you use a GC, you pay a price in some way. But, as with everything else in life, it comes down to a cost-benefit analysis. The current Nim GC allows me to write expressive code, without much boilerplate. Whatever small price I'm paying in terms of extra GC hooks, data kept alive for longer, et al. fades into insignificance compared to the productivity advantages the GC gives me.
> I think the biggest benefit for someone like @RedFred is better > multithreading. But we already have great multi-threading even with the GC. Threads have their own heaps, so they don't pause when main GC kicks-in. We have channels, threadpool/spawn, async-await, it's all good. Yes, I appreciate there are bugs / optimisations to be made for certain multi-threading use-cases but there are no show-stoppers AFAICS. > Both Python and Node.js went down a very similar path to what @RedFred > proposes: They focused on a good single threaded GC. Both of those languages > ended up having crazy hacks and ecosystem fractures once they started having > to deal with multithreading. The GIL in Python is STILL a big problem, after > years! For the record, I'm not proposing anything, much less a GIL-based GC. I'm just trying to clarify / ascertain what the implications of the newruntime will be for someone like me. My concern was that we might end-up with a language that you have to fight against all the time in order to satisfy its own memory-management quirks and eccentricities (for example see [https://stackoverflow.com/questions/24847533/why-does-rust-borrow-checker-reject-this-code)](https://stackoverflow.com/questions/24847533/why-does-rust-borrow-checker-reject-this-code\)). However, I am much put at ease with many of the posts here, so thanks to everyone who responded.
