Hacker News Reader

Comment by sandwichbop | Hacker News Reader

Interesting read and I agree that growth in technical debt is something to worry about. I want to get more involved and been trying my best to learn the skills needed but there’s so much to consider that it’s a bit overwhelming. I’m not familiar with Zig, it’s neat that it has a toolchain that can compile C/C++ but it reminds me a lot of Nim. Could someone explain to me some differences between the two and why you would pick Zig over the other besides personal preference?

View on HN

I'd say Zig wants is really serious on wanting to be a better C, that is have the same (better?) access to bare-metal, memory and bits but with a better type system and error management and without C's footguns and cruft (build system, memory errors, preprocessor). I don't know Nim that well but it seems more ambitious and seems to cater to be more "general purpose" if that means anything. For example there's no hidden flow control in Zig.

Nim is garbage collected, thus is a higher level language but doesn't fit the high performance low overhead of "systems programming" requirement.

While Zig is manual memory managed like C and nearer to the core, but harder to program.

With ARC, Nim's memory management would be closer to Rust than to Go.

Automatic Reference Counting? I’m not sure. Swift spends a lot of its execution time doing reference counting.

Nim does it compile-time to insert destructors in the correct places. (except for cycle collection, which needs a runtime GC)

Are there benchmarks?

I think the maintainers of Nim would disagree with your assessment given that the first sentence on the front page of Nim's official website is:

"Nim is a statically typed compiled systems programming language."

As someone else pointed out, when using Nim with its ARC/ORC and move semantics (which will eventually be the default), it's closer to Rust than to Go.

That being said, Nim's current default GC does well for many kinds of workloads. If it's really causing a performance problem, it's possible to disable it and manage memory manually (or use a different language for the task at hand, of course).

Not at all: Nim always targeted system programming. Even before the new ARC/ORC, the GC was optional and done independently in each thread.

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

https://tinygo.org/

https://www.ptc.com/en/products/developer-tools/perc

Nim targets all the architectures that GCC targets, including less common microcontrollers.

Reply on news.ycombinator.com