> The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most

> The benchmark game makes it clear that no language with GC gets closer than a 2-3x the time of a non-GC language (julia is the closest) and that matches most real world experience (and also that we don't always care about that hit). It also makes it clear that being dynamically typed and interpreted is a huge penalty in performance. It makes it clear that some people have most time to optimize for a benchmark than others. This benchmark on state-of-the-art cryptography shows that GC-ed languages including Go and Nim can be 2x faster than Rust: - https://hackmd.io/@gnark/eccbench#Pairing https://hackmd.io/@gnark/eccbench#Pairing (old benchmarks, in particular Nim had a parameter passing issue/bad copy behavior on large types) Furthermore, Nim GC/memory management is type-dependent, only seq/string (which use malloc/free) and `ref T` type (which use refcounting) involves some runtime. So Nim devs can choose to opt-in in GC or use manual memory management depending on their priorities.