Hacker News new | ask | show | jobs
by nepeckman 2068 days ago
Since Nim has hit the front page twice in the past day, let me just say: if you're at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you've worked with any static language, you probably know 80%-90% of what you need to write productive Nim code. The dev team has worked hard over the past year to improve documentation, and the website links to some great tutorials.
3 comments

"Nim isn't quite as simple as Zig"

My experience is complete opposite. I find Nim to be very simple and Zig to be not simple. What's the problem with Zig? I find the documentation to be chaotic. I believe that this is largely due to the rapid pace of changes (including changes that break earlier code).

That makes sense. I haven't tried Zig, but it's still pretty early in its history. That means a lot of syntax change, similar to Rust which is settling down, or Swift. Nim's been around long enough that it's settled it's syntax a while back.

Before I started really digging into Nim, it seemed like it was always changing the language a lot (feature churn). However, most of those changes have been compiler support for different GC's and other backend languages, which don't generally break existing code. I've tried Nim code from 4 years ago, and its almost the exact same syntax. Sometimes stdlib names changed. I think syntax change is the part that gets people a lot in terms of daily "complexity".

It actually reminds me of the feel of Python 2, before Python 3 that seems to add new syntax & language complexity every release. Well Python 2 but with a more solid language theory (e.g. everything can be a statement, etc). The trickiest part of day to day Nim are: var vs no-var, object vs ref object, and some iterator annoyances.

My understanding is that Zig is also strongly committed to working out as many kinks as possible so that 1.0 can be an extremely stable release, so they are running as fast as possible to make mistakes in the language. In that sort of an environment it doesn't really make sense to solidify docs.
Maybe I'll give it another try. I might have gone too deep into the docs, but Nim seemed to get very complicated with all the {.annotation.} to remember
If you're just starting with the language, my recommendation would be to ignore the pragmas. None of them are necessary for basic functionality, and a lot of them are only useful for very specific optimizations. The most useful pragmas in my experience are the pragmas for FFI, async, and memory/side effect tracking.
Nim and Zig have vastly different philosophies and targets.