I mean, Nim looks cool, but I’m not sure what it does that is substantially new. Niceties are generally not enough to foster adoption - something real has to be on the table that meaningfully opens up new avenues, unlocks new paths, enables new use cases.
I have the same criticism of Zig.
Nim compiler has an embedded VM, so any Nim code (that doesn't rely on FFI) can run at compile time.
I guess a lot of languages are kind of fungible. If you want a fast, cross platform, GC-based OOP language, the truth is, there are many choices. I'm not saying they are the same, but for 80% of the use cases they kind of are, and there are always good reasons to use established languages rather than new ones.
The ones that make it offer something very unique, not merely better than peers. So Rust, as a memory-safer non-GC language has a clear use case with little or no competition.
Nim doesn't have this luxury. I wish it well, I like the language and often contemplated learning it properly. But I fear the odds are against it.
It’s probably easier than it’s ever been to create a high quality new language but to get as good as Rust has become just takes so much time and collective effort that it can be out of reach for most ecosystems/groups of builders. Getting the language features just right (and including novel stuff) is just the beginning.
Remember when Rust and Go were comparable? Feels like forever ago when they both just looked like “new systems programming languages” a we know how that turned out.
For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.
Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high quality Rust code.
Llms solve this problem
They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.
The definition of "same niche" is doing a lot of heavy lifting.
There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons).
I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer.
For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end.
I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.
There are domains where performance is critical and safety isn't so important (e.g. video games). Zig has an advantage in such domains because of the pervasive support for passing around allocators in the standard library (avoiding hidden allocations, and allowing efficient memory reuse via block allocators), while in the Rust stdlib custom allocators are relatively cumbersome to use (and not easy to prove safe to the compiler).
The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes).
1) Rust, in practice, is "safer" than Zig but doesn't seem to be "much safer".
See: https://mitchellh.com/writing/ghostty-gtk-rewrite
> Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success.
Take that as you will. And what Ghostty does probably requires a decent chunk of "unsafe" that would likely hide a bug anyway.
To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
2) Rust is to C++ like Zig is to C.
Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good.
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything.
All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.
Also an underrated chance to be forced to learn about Arenas, most of the time.
Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.
That said, it's great to hear that others are having success with Zig and aren't writing very many bugs.
> To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
Reasonable points! This is one of the reasons I have on my list to consider Zig at all (that and wanting to write more C), it seems people that like it are wonderfully productive in it.
I really like a lot of the design decisions and watch the streams than Andrew and Loris, Tigerbeetle folks and others do to see the decisions they make. Their managed IO approach is certainly interesting and quite powerful.
Dislike some small petty syntax things (whyCamelCaseFunctions()!?), but that's a me thing.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Agree with this, anecdotally.
> I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
Yup, Typescript works for me here, and usually the hard parts are offloaded to an external service anyway (e.g. Stripe)
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. > > I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
I wouldn't put Rust and C++ in the same league there as far as brain size requirements, but point taken!
$$$money$$$
Rust (backed by a foundation) won over Go (backed by Google). Oh, and remember Dart (backed by Google)?
I wouldn't say either of them have won. I'd say both are amazing tools, too. We're spoiled for choices these days.
Go and Rust don't compete, Go has a GC, they're in fundamentally different domains. Google also uses Rust, among other languages (C++, Java, Python, Go, JS, etc...).
Forget about syntax or semantics or unique features or whatever. Having money and resources are the most important factor for a successful language.
I program a lot in Nim including professionally and strongly prefer it over Rust or even Zig.
Primarily because I just really enjoy programming in Nim and getting things done I wouldn’t have otherwise or be capable of doing.
For example recently I needed to automate a GUI app. I tried the Python libraries but found they kinda sucked. Despite pulling in opencv they were slow at finding buttons in a screenshot. Then the one I tried also broke on hidpi displays.
Instead I got Claude to write me up a Nim library to find images in a screenshot. Then had Claude add SIMD to it.
It’s far faster than the python libraries, supports hidpi, and is far easier to install and use. I still use a small Python app as a server to take the screenshots but it’s a nice balance.
> I guess a lot of languages are kind of fungible. If you want a fast, cross platform, GC-based OOP language, the truth is, there are many choices.
It’s true, in many cases they are fungible. Though much less so for languages which compile to native code. LLMs do lower the barrier to switching.
Nim isn’t really a GC’ed OOP language though it supports some bits of that.
It’s really a systems language that can also run anywhere from an embedded device to a web server and as a JavaScript app.
The new default memory management is based on reference counting with or without a cycle collector. So it’s great for latency sensitive settings.
To my mind, to the contrary :( LLMs get trained on corpora of existing texts, including source code. They become much better at massively used languages because of the plethora of training data, and struggle with more niche languages because of the dearth of good examples. It's a positive feedback loop for mainstream languages, because more stuff gets vibe-coded, or code-assisted when the AI does a better job at it. It's a negative feedback loop for niche languages because the opportunity cost of choosing them grows :(
On top of that I’ve been able to “vibe” code a couple of different libraries for Nim. The bigger limits with LLMs is still “deeper” and loosing track of what it’s doing.
It helps that Nim doesn’t have much unique syntax requirements or paradigms like say Rust lifetime annotations. Some of the rarer Nim idioms like `set[Enum]` being castable to a cint aren’t used.
But generally what you’d do in most C++ code works well in Nim, but with simpler syntax.
It was dead prior to this. A subset of programmers think it's hard to program in any other language other than the one or two they studied.
They are wrong. Most programming languages are very very similar. And learning one means you learned almost all. i learned new languages on the regular pre - llms and it required barely any effort.
Most company interviews are also language agnostic for this reason. Because languages are so trivial to learn once you "get" how to program.
I mean, compared to zig which is starting to have a lot of hype and libraries / help, lets say that we now wish for nim to have this, then are the feature differences b/w zig and nim worth the revival of nim in that sense? (Pardon me if this doesn't make sense)
Then around 2019 Nim started to gain momentum (preparing for 1.0 release) and when I looked into it a bit deeper it became evident that for most of the code I usually write for myself Nim is just a more pragmatic choice than Rust. It gets me there faster.
Zero job perspectives both times, scratched my own itch twice though.
Glad I haven't gone with Go. Nim is not a perfect overlap with Rust, but it definitely covers everything Go can do and more and is a better design in my opinion.
Maybe we both just got bad first expression with most popular, but unfortunately not a good language? =)
Back when most of my code was in C or C++ (or Java), I was told all the time, sure you can omit these braces for a single-statement block, but you shouldn't, you'll regret it later. You can leave all the code unindented or irregularly indented, it won't matter to the compiler, but you'll appreciate lining it up in the long run. And all that advice was correct; I was better off in the long run, and I saw others come to regret it all the time. But then, over time, I started to wonder why I had to scan past all these diagonal lines of close braces as I read the code. And I cursed that these languages made it too difficult to pull out the inner parts into separate functions, disentangle setup and teardown from the main loop etc. But I also cursed that after putting in the effort (even if was just "using a proper text editor") to make things line up beautifully and in agreement with the logical structure, I still had to take up vertical space with these redundant markers of the logical structure.
Python was my first language using significant whitespace, and it was a breath of fresh air. That was a bit over 20 years ago, I think. I've learned several other programming languages since then, but I never "looked back" in any meaningful way.
I'm now certain that significant whitespace is simply wrong.
But significant whitespace has always made sense to me. You are going to indent your code anyway, so you might as well give the indentation some meaning. I write Python, JavaScript and Lua most of the time, and I never waste any thought on whitespace VS braces VS keyword delimiters.
2, I sometimes want to fuck up the indentation on purpose, if I'm just quickly pasting some code to test if it even works or to mark it as "look at it in 5 minutes from now". Also I can mix spaces and tabs
quick edits it notepad/vim/whatever become painful
also converting tabs to spaces or vice-versa is tiring. A language shouldn't force me to a particular code style
Nim is a statically typed programming language that compiles to native dependency-free executables in C, C++ or JavaScript.
Nim fixes many of the issues I had with Python. First, I can now make games with Nim because it’s super fast and easily interfaces with all of the high performance OS and graphics APIs. Second, typos no longer crash in production because the compiler checks everything. If it complies it runs. Finally, refactors are easy, because the compiler practically guides you through them. The cross compiling story is great you can compile to JS on the front end. You can use pytorch and numpy from Nim. You can write CUDA kernels in Nim. It can do everything.
See: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
Gentle correction: Python is typed now too and you can get the benefits of typing both in your IDE (via LSP) and before deploying to production (via mypy and the like). This happens both by type inference as well as explicit type annotations.
Not to mention, if a library does not or does sloppily use type annotations, you would not get reliability even with a perfect type checker.
Php even seems to have decent static types these days, but do my coworkers use them? Hell no
No it's not and you should lose your union card for lying like this.
"Can be typed now" is somewhat correct.
"Can be partially typed now" is actually correct.
I recently compiled some stats on Nims popularity on GitHub: https://code.tc/nim-stats-august-2025/
It’s growing steadily but I do qualitatively feel like the ecosystem has lost a bit of steam over the past year. Excited for the ongoing Nim tool chain work though.
* It doesn't have many libraries.
Nim is in the awkward middle area where it's got a GC so it'll never replace C/C++ but it also isn't as productive as something like Ruby.
It is recommended to use ARC, which has similar semantics to C++, ie moves, copies, etc.
Unlike D, the GC is not mandatory for the standard library.
mathverse•15h ago
andsoitis•14h ago
Compare to other communities where you need to stand out from the noise.
scuff3d•4h ago
lifthrasiir•3h ago
Personal anecdote: I was exactly there a decade ago when I was working on Chrono, now one of best-known date and time libraries in Rust. Since I was simply my own, my design was not as good as it could have been. Of course it is still much better to have a suboptimal Chrono, but I can't deny that it remains and probably will remain suboptimal due to my design a decade ago.
DarkNova6•14h ago
summarity•7h ago