treeform
setopt
That’s very interesting actually. Can you call only specially wrapped libraries from Nim, or is any Python library importable? When you cross-compile to JS can you only use pure-Nim libraries or how does that work?
Tiberium
It's not a built-in Nim feature, and it'll only work with native backends (C/C++/ObjC). The project that makes it possible is https://github.com/yglukhov/nimpy
rich_sasha
I often wonder why some languages succeed while others falter. Why did Rust break through, for example, while so many other excellent languages didn't.
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.
elcritch
The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
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.
nine_k
> The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
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 :(
elcritch
That hasn’t been my experience with Nim so far. Both Claude 4 and GPT5 both one shot Nim code almost perfectly now. They even made a Nim JavaScript app for me.
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.
DennisP
Using LLMs to build the libraries you need seems like a fantastic way to work with them, since they've probably been trained on code that does similar things.
SkiFire13
> Nim isn’t really a GC’ed OOP language though it supports some bits of that.
I'm not sure about the OOP part, but last time I checked the standard library assumed the GC was enabled, so on that side I believe it's much closer to those languages than to C/C++/Rust/Zig
elcritch
It’s more that Nim2 moved from a GC to ARC/ORC, scope based automatic reference counting (ARC) with an optional cycle collector (ORC).
C++, Swift, and even Rust rely on reference counting quite a bit.
ninetyninenine
>The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
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.
hardwaresofton
I really feel for new languages that have to compete with Rust.
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.
baq
> Remember when Rust and Go were comparable?
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.
steveklabnik
Way back when Rust was first made known outside of Mozilla; it was pretty close to Go. While the intent was to be super low level, it didn’t really achieve those goals until years later, and kind of at the expense of parts of the original vision.
pjmlp
Go is hardly a replacement with its weaker type system.
bsder
>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.
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.
logicchains
>a language with often comparable performance that is ALSO much safer
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).
akkad33
> 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
Llms solve this problem
MeetingsBrowser
> be confident I’m Not introducing a whole class of gnarly bugs
I think LLMs are doing the exact opposite
sroerick
Have you tried using an LLM with Zig? When the training sets are on different language versions and there are breaking changes you may find it challenging.
I actually enjoyed zig because it prevented me from using LLMs to code in this way
Tiberium
I use LLMs almost daily, and they certainly don't "solve" the problem of finding bugs, not even in popular languages like TypeScript. They do help a lot, yes, but they haven't solved it completely.
lionkor
If you think LLMs solve this problem, you should reevaluate your experience level and seniority.
hk__2
Using LLMs on a language you don’t already master is a sure way to introduce a lot of bugs.
bobajeff
I vaguely remember a talk given by the creator of ELM called "The Economics of Programming Languages". It's actually really expensive to make a good programming language that's widely used.
Forget about syntax or semantics or unique features or whatever. Having money and resources are the most important factor for a successful language.
Imustaskforhelp
Oh boy, I always had this knack for seeing/testing multiple langauges and when I had first discovered nim, I used to watch some nim youtube related content and I remember someone in nim community pointed out about this same video from the creator of elm that you also mention.
So, I think that I had watched the video and honestly, I will watch it now once again since I don't remember it clearly but If I remember, I really liked it.
A quick search points me to the video, though I am not sure https://www.youtube.com/watch?v=XZ3w_jec1v8
zahlman
Where does the money get spent? Just developer salaries and marketing?
colejohnson66
Yes. Writing a language in your free time means juggling work on the side. Or you can be at Google and get paid to write Go for your job, and get free marketing from it. Even Rust had the backing of Mozilla. Until your "pet" language reaches critical mass that you can sustain yourself and quit your day job, you're fighting the giants.
steveklabnik
Salaries, hosting bills, CI bills… most languages do not have a significant marketing budget.
xigoi
> I often wonder why some languages succeed while others falter.
$$$money$$$
miggy
A strong tooling ecosystem needs money, which usually means corporate sponsorship.
hk__2
> $$$money$$$
Rust (backed by a foundation) won over Go (backed by Google). Oh, and remember Dart (backed by Google)?
nine_k
Say that Rust "won over" Go is like saying that Python "won over" Java. They are both alive and kicking, and live happily in rather different niches.
zeroc8
They are used for different things. There are a zillion successful projects in Go. Don't see how Rust won anything.
xigoi
In what sense did Rust “win over” Go? And since Google loves to kill its side projects fast, no wonder Dart failed.
OoooooooO
Rust can do everything Go does but Go can't do the same as Rust can.
paradox460
I really wanted to love nim. I wrote a bunch of tools in it, had fun, and then ultimately rewrote them all in rust. The library situation in nim is just unfortunate, and I say that as someone who uses elixir. That, and the cross compiling took far more effort than getting the same code finished on rust, which was little more than "use cross"
I keep hoping nim will get better, because it's a beautiful language that produces absolutely tiny, efficient binaries
gyulai
So, there I was in 2016. It had been 13 years since I had last entertained the desire to learn a new programming language (I had landed on Python, back then). The serious contenders were Go, Nim, and Rust. I landed on Nim back then, thinking to myself: Man, this language really has a future. I did my next side project in Nim, and loved it like I've loved no other language over the course of my (as of now, in 2025) 28 years of programming. But no actual job ever materialized to make me into a professional Nim programmer that would actually pay the bills. I stuck it out with Python, with growing discontentment. I took a Perl job in 2018, which lasted until 2022, which I never should have taken in the first place. I was relatively free in my choice of language from that point forward, and decided to switch from Python to Lua after a short period of disorientation where I kind of liked Haxe. Right now, I'm learning Rust, crying tears over that future for Nim that never materialized.
ZoomZoomZoom
Had almost the same situation to a tee around the same time (~2014). Decided between Rust, Nim, D and Go. Went with Rust then and quickly felt it had been the right choice since it really helped me improving my skills and got me interested in programming again after a few years away from it. Rust community was way smaller and more approachable, the language felt exciting and really delivered on its promises.
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.
Imustaskforhelp
Honestly, we can all still correct it if we really want to. Nothing is too late in my opinion, but the question that I wish to ask is, is it worth it?
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)
mathverse
Nim is a programming language for an expert programmer. The ecosystem is very small and for everything a little bit more specialized you need to make a library yourself.
summarity
Whenever I’m missing a library I’m usually just 5 mins away from successfully using a C library (or any library with a C API). In my years doing data analysis, signal processing, and just writing plain servers I’ve never once gotten stuck because of a missing library.
andsoitis
When there's a vacuum like that, that is also an opportunity for folks to make a significant impact.
Compare to other communities where you need to stand out from the noise.
hk__2
This usually ends up in a situation where most of the significant libraries for the language are abandoned GitHub repos with 13 stars and no documentation ("You just have to read the code!!1!").
raffraffraff
This. I really wanted to like Nim. I tried to learn it, but having never been a programmer before (but years of Linux admin, puppet, terraform and scripting) I found it extremely tough, and a lot of documentation is out of date and the there aren't many good examples to follow. Switched to Go and have built lots and lots of stuff in go.
ZoomZoomZoom
> a lot of documentation is out of date
Please, file bugs or complain on the official matrix room. The community tries its best to keep up the official documentation in sync with the changes.
Imustaskforhelp
Exactly, I had tried nim but I felt the same issue.
I mean, personally I really like golang. Its actually gotten an ecosystem that functions while being able to cross compile and actually being easy enough to learn unlike rust.
I also sometimes exclusively just use typescript/python just for their ecosystem as a junior programmer. For me ecosystem matters a lot and this was a reason why I wish that more languages can create more libraries which can work.
Like the article pointed, nim is really solid language. But I'd like to see more libraries being made for it.
DarkNova6
Sounds more like "Expert Hobbyist" than "Expert Programmer".
jarredkenny
I fell in love with Nim a couple of years ago, but feel like Zig gaining popularity has really pushed Nim out of the limelight in terms of developer adoption.
Zambyte
Nim has been on my radar for a while, but I've never really dug into it. I have actually written some small projects in Zig though. Are there things you think Nim does better than Zig?
Tiberium
I think Nim and Zig target very different audiences and have very different goals. Nim is about being a big, powerful language with lots of features, so that you have the freedom to use it the way you want, e.g. there is OOP with methods, but it's completely optional. Zig is explicitly against that, even on the homepage you can see: "No hidden control flow. No hidden memory allocations. No preprocessor, no macros.". While memory management in Nim by default is completely automatic, and templates/macros are quite common.
It makes much more sense to compare Nim to, say, Swift, D, or other modern compiled languages with lots of syntax sugar.
anta40
You may consider Nim as a sort of "compiled Python" with some Pascal influences.
https://nimble.directory/ I'd pick Nim if my concern is general app development, not specifically system programming.
null
summarity
I’m also an avid Nim developer (findsight.ai is almost pure Nim).
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.
ziofill
> In fact, Nim first compiles to C which in turn is compiled to machine code by the C compiler of your choice (gcc/clang).
Can one use the zig compiler after nim has compiled to C?
blashyrk
Yes, I tried it recently for easy cross-compilation. You can use basically any C/C++ compiler, even TinyCC works (in most scenarios) if you want an extremely fast edit/compile/test cycle.
Tiberium
You can, but zigcc is essentially Clang bundled with extra stuff to make cross compilation easy.
binary132
The main reason I never got into Nim is that I seem to recall it depending on mingw and that frankly always sets a language into a second-class category for me. Maybe now it’s different, I don’t know.
zero0529
What a low effort article. I have done some programming in Nim. It’s a nice language but I felt frustrated whenever I wanted to do something I knew I could do in python but that didn’t work in Nim. I just missed some of the syntactic sugar of python, that being said I would love to get back into Nim again.
polotics
You know what, I mostly do python, but then had to get quite high performance on some lib. Converting to Nim and importing with nimpy has been a blast. The result is just one more python module, colleagues don't get frightened when they see the code, it's just seamless and nifty. I much prefer it to Cython.
Tiberium
Can you provide some examples if you still remember?
zero0529
If I remember correctly it was when working with collections but I can’t remember a concrete example though. Their std library is by no means bad it is just different enough from python to hurt my productivity. My initial motivation for chosing Nim was because I was doing an algorithm course at the time and I wanted to archive fastest runtimes in shortest amount of code
mrbluecoat
From a promotional marketing perspective, that webpage misses quite a few basics, like linking to the Nim site [0] and explaining what it actually does:
Nim is a statically typed programming language that compiles to native dependency-free executables in C, C++ or JavaScript.
quotemstr
You mean the language also known as NIM, n_iM, and NI_m?
Tiberium
The first character is actually not considered for case insensitivity, although it was in the past. :) And case insensitivity itself comes to Nim from Pascal.
quotemstr
The underscore thing gets me more than the case insensitivity, FWIW. We have tools for case insensitive greps, but underscore normalizing ones are rare.
xigoi
By this logic, C++ is the same as C, C# is a syntax error and PHP should be named $PHP :D
I feel like Nim made me fall in love with programming again.
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...