I've only used Nim but generally if you can use a garbage collected language you should in most cases but there are many cases where you can't, reasonably, and so we have languages like Zig, Rust, C, etc. Unless you're going to be doing something very sensitive to performance to the extent that you were going to be thinking carefully about memory lifetimes anyways.

TIL about Zig. It looks like it's been released a while ago (2016) but when I searched for how they handle concurrency all I could find was it's still in the research phase :(. I thought I was going to be able to find at least a design document like with Swift:

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

> if you can use a garbage collected language

With ARC there's no GC runtime anymore, making Nim a competitor with Rust.

Do you mean with Rust's Rc or Arc?

They mean this: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

Isn't the GC of Nim optional?

Optional, though the language and standard library are kind of designed around it. So I'd say Nim can be used without the GC, but is optimized with the idea that you'll use the GC by default, with escape hatches for manual allocation when you need the power for performance or efficiency, e.g. manually managing big blocks of memory for tight loops.

Contrast to a language like Zig, which has a standard library and syntax built around the idea of manual allocators and what not, but is missing the "ease of use" of GC. Personally, I agree with GP, and like Nim's compromise of GC with a "I know better, let me do it manually" syntax, but there are domains where you want a language like Zig.

Correct. I'd add that with ARC (or ORC even), there's little reason to do manual memory management (alloc/free), even for embedded systems. ARC is an automatic memory management system based on reference counting, but there's no "runtime". It actually injects alloc and free calls at compile-time based on static analysis.

ORC adds runtime GC only for cycles, and will be the default in Nim 2.0.

You're information seems to be dated by the presentation.

I suggest you think of Nim as a better Go - more ergonomic, easier to start being productive in, faster, giving more control if necessary (by descending into the unsafe territories of manual memory management, `emits` and such), more portable, suitable for workstations and embedded alike.

Zig is definitely not that. And I understand the description above misses the downsides of a small community and not the strongest ecosystem.

I think it is a stretch to compare Nim and Go as anything other than statically compiled languages. Nim is the anti-Go with every possible programming paradigm inside the language.

The implementation details and the development ethos differ, but from the pragmatic point they compete, offering higher abstraction level over C. Moreover:

- Both took some inspiration from languages of Wirthian family.

- Both promise easy onboarding and high readability.

- Both rely on automatic memory management by default.

On the other hand, I agree that Nim feels and functions totally different while offering much more possibilities. You can definitely call Nim the anti-Go, but it doesn't negate the fact it could absolutely shine in the same domains, at least with a bit more love, attention and funding.

But they're both statically typed GC languages that compile to native binaries. Versus Zig which has no GC and is more akin to C, Rust, Ada, that sort of thing...

With ARC Nim is also very akin to Ada and Rust: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

> ORC is Nim’s all-new cycle collector based on ARC. It can be considered a full-blown GC since it includes a local tracing phase (contrary to most other tracing GCs which do global tracing). ORC is what you should use when working with Nim’s async because it contains cycles that need to be dealt with.

From that blog post. Nim is great but it's more Go and less Rust...

> more Go and less Rust

Not at all, it does not have a runtime with a built-in thread pool and channels like Go.

I learnt a bit of Nim few years ago, but haven't continue it. My understanding so far is unlike Go, Nim doesn't have concurrency built into the language/runtime?

Hopefully it should get better soon-ish, but concurrency (and even parallelism aka threads) unfortunately is probably Nim's weakest point at the moment.

On the good side, compared to go, Nim's interop with C is fully transparent (since Nim uses C as a backend). This means easy access to C libraries, but also makes it very appropriate for embedded targets like microcontrollers (especially with its ARC memory-management system, which is static/deterministic automatic reference counting).

Of course it does.

Perhaps Nim will compile to Zig one day?