You can always use things like arenas in C and get similar speed ups without GC overhead. If you know your memory lifetimes in advanced, avoiding granular malloc/free calls is pretty straightforward. A GC language doesn’t usually offer such options.

You provide no trustworthy benchmark for your claim that Go is slow, or that nim is faster than that. Many engineer hours have been put on the go GC and compiler

I haven't seen data that would confirm that the Nim ARC/ORC approach is faster than manual memory management (C/Rust/Zig/...) on programs with non-trivial lifetimes (for trivial lifetimes, Nim elides RC). I'd also be somewhat surprised if it was consistently faster than GC – most languages with automatic memory management use GC over RC because RC adds significant overhead, especially in multithreaded programs.

Good to know! Would there be any way languages like Go or C# could adopt Nim's new garbage collector? If it's better, what stops other languages from using it?

> GC programs can be faster than manually managed ones in some cases.

I've seen poorly written programs in C/C++/Rust which are slow because they allocate millions of tiny objects. Its true that generational GCs can be faster in this case. But you usually get much better performance again by using arenas and such. The reality is that I know more about the lifecycle of my data than my compiler. If you know what you're doing, you can take advantage of this information to write better programs.

If you don't want to think about memory management, then I agree - you're usually better off using a language with a GC. Personally I do a lot of my prototyping in typescript because I can iterate faster when I don't have to think about lifetimes.

Maybe some day Fil-C will run general purpose C code at native speeds, without a high memory overhead. But we're not there yet. I'm not holding my breath.

[flagged]