I expect, and I hope that like today with have: * the possibility to choose if a type is GC-ed or not (ptr vs ref) and the assurance that if we mixed ptr and ref, only the ref codepath can trigger GC-related latencies. i.e. if you only use ptr and object you don't have the GC compiled-in (today you still have it for strings) * the possibility to choose which GC to use. There is no one-size-fits all and what of Nim attractiveness is the possibility to add real-time constraint to the GC for games for example or audio which cannot pause (but might want a heap structure to collect counters and statistics and would also be able to repurpose a third-party logging library with their real-time constraint)
Furthermore, it seems like there will be an allocator API. All in all, Nim may manage to meet the needs of 2 very different use-cases: * high-level: don't want to deal with memory management * low-level: memory management is 50% of my perf and working around the GC is a no-go Even better, it may be able to mix both and still keep the developers happy: * high-level was always able to call low-level code (see Python and C/Fortran). * low-level had to reinvent the wheel logging, metrics) because high-level lib were too restrictive.
