Thank you for working on the Nim Compiler. This is great. Another great release. The Nim Compiler continues to move forward.
Thank you very much to everyone who has contributed to the development of this superior language. Nim Compiler continues to be one of the most wonderful languages I have worked with. With the speed of C and the simplicity of Python, it has allowed me to write a lot of cool software.
I do not know where I would be if Nim did not exist in my life.
Not the OP, but as an individual who has programmed in Nim on and off for a decade, I feel qualified to answer. The similarities are definitely only skin-deep, and Nim is just as complex, if not more complex than Python.
Nim is much closer to Pascal / Modula / Oberon than Python. The whole - ease/simplicity of Python and speed of C is mostly marketing jargon that the Nim community has been using as long as I've been aware of the project.
I've used Nim a bit, though it's been a while. I've been primarily a Python developer for the past 20 years, with a sprinkling of other languages and paradigms - including languages like Scala and Haskell, so not just OOP stuff.
I characterize Nim as Python with one major difference: where Python prioritizes "developer happiness", Nim prioritized performance. As a result, the syntax looks very similar, the edges are quite a bit rougher, and performance is exponentially better.
It still "feels like" Python in a lot of ways. The ways places if differs feel a lot like Haskell IMO.
How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync.
Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.
Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.
This sounds to me like you don't like Python's syntax and abstraction model more than anything else. Which is fine, there's plenty of languages out there.
I find that python has this simplicity other languages lack. Nim has it too. It's hard to strictly define it? Its a bit syntax, a bit lists or dicts, batteries included? A bit how you run it. Maybe a culture of straightforward code - at least in the python 2.x days. Maybe its just you write an algorithm and its easy to follow?
with some limitations: https://github.com/nimpylib/nimpylib/tree/master/doc/mustRew... no "end" argument in print, no triple quote and newline, no "a not in b" (write not (a in b)), no variable named _ (underscore), or double underscore, no slice as foo[:b] where the left part of the slice is not specified, rewrite foo[0:b], etc.
In practice, it means that unlike most native-compiled languages, if you want a data-oriented approach without having to worry about system details at all, you can do that. Your program will still be strongly typed, but you're not obligated to worry about allocation, reference vs value semantics, ownership, or initialization details. For programs that shouldn't have to worry about those details, the Nim team has done a lot of work to make sure the language gets out of the way and lets you process data. Then, you get a fast binary comparable to the results you'd get from C++ (with a lot more effort).
In buzzword-speak, it's easy to write programs composed of nearly pure business logic while getting C++-level performance.
While it's ecosystem probably does not even match Julia's let alone Python's or the C/FORTRAN-verses, since Nim has been around for almost 20 years and publicly since 2008, there are still a lot of accumulated packages. Some are listed at: https://github.com/ringabout/awesome-nim for really a large (and even so still incomplete!) list of things you might be interested in. Hard to say how well maintained they are. That said, you do probably have to be prepared to do a lot of work yourself and work around compiler limitiations/bugs. Also, binding to C libs is very straightforward with a near trivial FFI.
I suppose it very much depends on the programmer & setting, but like 3 times I've looked for Rust projects similar to Nim ones and found the performance of the Rust quite lacking. Of course, any language that allows you access to assembly makes things ultimately "only" a matter of programmer effort, but the effort to get performance out of Nim seems very competitive in my experience. I've seen at least one ancient 1990s C project be more flexible and much faster in Nim at like 6% the LOC (https://github.com/c-blake/procs for the curious).
It's too bad that the BDFL of Nim (Araq / Andreas) treats the language like his personal compiler development playground. This has led to a hard fork of the compiler, many experienced and frustrated developers leaving the community and language behind, and an extremely fragmented ecosystem.
He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
> He is also very difficult to work with and isn't very welcoming to newcomers.
This hasn't been my experience at all.
When I first tried Nim, years ago, I came across an inconsistency in a database connector in the standard library after only a couple of weeks. I pinged him to ask if I was understanding it correctly and confirm it was a bug. He agreed it should be updated, so I put together a pull request. It was reviewed quickly, we went back and forth a couple of times over some details, he asked me to include some documentation updates, and it was merged without issue in a couple of days in total.
Given that I came to the language as a complete newcomer and had commits to the standard library less than three weeks later with the BDFL's approval, I simply can't agree that he's difficult to work with or not welcoming.
> language like his personal compiler development playground
re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.
> He is also very difficult to work with and isn't very welcoming to newcomers
I don't have full context on the drama behind the fork, but I don't see Araq not being very "welcoming". Araq replies on the forums very consistently, replying to new-comer questions, which one might consider as "simple questions". Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.
From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.
Personally, I see no reason to use the fork (Nimskull) over Nim, nor would I ever see any individual or company picking up Nimskull unless they were very deeply familiar with Nim (this is a small population of people). From a skim of the Nimskull repo, there is no website (there is a copy of the Nim manual), no forums (just some chatrooms), no clear documentation on the future direction, no documentation on differences for someone not familiar with Nim, etc. - why would anyone pick up Nimskull unless they knew Nim well? Please take this as constructive criticism. e.g. if any feature of the language/compiler/tooling is "better" or planned to be better: highlight it, summarize the long GitHub issue/projects discussions in a blog, etc.
> re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.
Araq likes to work on the shiny flashy things he finds fun / interesting to work on. I'm not going to fault him for that, but things like atomics on Windows are still broken. People have been complaining about the stdlib and documentation + lack of a formal specification for at least a decade.
> From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.
There was quite a bit of drama that caused the hard fork to materialize. Differences in communication styles is definitely describing the drama that unfolded, extremely mildly. I don't work on the fork or use it, but some of the more talented compiler developers who were previously contributing to Nim, left Nim to go work on Nimskull.
> Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.
Nope. This is a sop, an equivalent to the non-apology "I'm sorry you took what I said so badly".
Aggression masquerading as "honesty" has no place in any organisation that wants to be taken seriously.
It's most certainly not "OK" when Andreas' personal opinions are expressed in ad-hominem attacks.
Nim unfortunately has a toxic Dictator at the top, and his subordinates defend his behaviours. While this continues nobody should take Nim seriously.
> Nim unfortunately has a toxic Dictator at the top
Araq has opinions that he defends, but you can and absolutely should try to sway or change them. I see this all the time on Discord and Forum. And I see people win over just as much as them losing.
I don't have a strong opinion if this is healthy or not, but it's probably why I would be a bad BDFL =). All in all, I don't think dictatorship is a right word here.
If someone stumbles upon this comment, don't be quick to discard the Nim language. Please do your own research and make your own opinion on the matter.
I believe this and many of comments by tinfoilhatter under this post are not in good faith and in the most charitable interpretation written by a uninformed person or are severely outdated.
> Thanks for the offer, but there's a reason why Nim hemorrhages users as fast as it gains them, and a big reason for that, IMO, is the toxic community which definitely includes the moderation team.
I have to challenge this, because for the last couple years, there have been almost no incidents or drama. Moderation was almost exclusively dealing with spam messages. I think, on the forum, a couple posts were closed because of heated or offtopic discussions. But in all cases, participants were agreeing with the decision of mods (you can see them leaving a 'like' on mod's message).
> There was quite a bit of drama that caused the hard fork to materialize. Differences in communication styles is definitely describing the drama that unfolded, extremely mildly. I don't work on the fork or use it, but some of the more talented compiler developers who were previously contributing to Nim, left Nim to go work on Nimskull.
I know that some of people that left were also the ones causing problems with moderation and being toxic. I don't want anyone to draw strong conclusions, but Nim community was much healthier and friendly after the fork people and certain moderator leaving the project.
> He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
This is just false. You can see Araq answering the noob questions on the forum all the time. He might be not the best person to do that, because his answers on the short side. I believe, noobs often need more context, examples and explanations than he's providing. But it's thought and effort that counts. Some people even hate when you treat them as complete beginner and try to nourture them common CS knowledge.
> The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
I certainly hope this isn't the case any longer. As one of the moderators I feel the current group is very patient and welcoming. At least that's what we're trying for, no one is perfect so I'm certain you can find counter examples. But as a whole I think we're doing pretty well. If you have any specific complaints we would love to hear them. They can be left anonymously in our community feedback form, or you can find we anywhere in the community for a chat.
It makes sense you feel that way, as you're one of the moderators. I feel quite differently. Thanks for the offer, but there's a reason why Nim hemorrhages users as fast as it gains them, and a big reason for that, IMO, is the toxic community which definitely includes the moderation team.
> He is also very difficult to work with and isn't very welcoming to newcomers.
That's a charitable way to describe him. In our one direct interaction, he was condescending to the point of insult. (I believe he was incorrect as well, but even if he was always correct, I would consider it wrong to treat someone badly.) After browsing the Nim forum and issue tracker, I found that this was routine behavior for him.
Nim has some nice features, but I don't want to depend on anything that's subject to the whims of a personality like that, and I certainly don't want to interact with him again.
You're right - I probably am being too charitable in my description of him. To his credit, he's gotten better over the years, but I still check in on the forums and find examples of this behavior. Andreas could be the most talented compiler developer in the world, but as long as community members are being treated poorly for asking questions, the language will continue to languish in relative obscurity.
Unfortunately this has been my experience. Andreas was extremely abrasive towards me personally, and views he expressed to me regarding climate change were bizarre and aggressive. His behaviour led me to ditch Nim and explore Go instead, and I couldn't be happier. Sadly Nim is a permanent no-go for me.
This isn’t constructive feedback, it’s just you venting and throwing insults. If you actually had something meaningful to discuss, you’d bring specifics, proposals, or examples instead of blanket accusations.
We’re not here to entertain derailments, hostility, or attempts to stir up drama. If your goal is to have a conversation, you need to do better than this.
Then offer specifics that contradict mine? It should be easy if all I'm doing is being a contrarian. There are at least a few comments in reply to this post that have echoed my experiences regarding unpleasant interactions with Nim's leadership and community.
I'd like nothing more than for Nim to succeed as a modern systems programming language. Unfortunately, giant egos and personalities constantly get in the way of that goal. There's certainly something holding Nim back from achieving widespread adoption, and if you want to suggest it's me and some sort of concerted effort to toss shade at the language and its evangelists, then that is your perrogative. It certainly isn't moving the language forward.
> I’m sure there’s a lot of context I’m missing. But what is the story behind this?
There was a falling out between the Nim core development team and several volunteer compiler developers. The former seemed to be paying more attention to their personal projects, while still desiring to maintain their positions of control and authority over Nim and its direction. The latter group grew increasingly frustrated, the situation became extremely toxic, and ultimately Nim lost several talented compiler developers to the hard fork.
I believe the goal of being incompatible with Nim resulted from the developers involved in the hard fork feeling like the Nim development team had done a poor job of designing certain portions of the language and compiler. I'm pretty sure they ditched the C++ backend, and made some substantial changes to the langauge to bring it more inline with their ideals.
I'm not involved in the development of either project, so a much better source of information would be the Nimskull project's developers themselves and the core Nim development team.
Last non-bot commit was over 2 weeks ago, and it seems to be mostly 1 account working on it. I don't think it looks active enough to be the big schism it's made out to be?
Nim itself has very few core developers. Comparing the number of developers involved in a hard fork to the number of Nim developers is silly, in my opinion at least.
The project has 21.5k commits authored, most of them oriented at replacing the existing compiler backend with a CPS-oriented one. Nim 3.0 is replacing the backend with one that is focused on CPS. There is no doubt that the developers responsible for the hard fork of Nim inspired Nim 3.0.
Yes, it very much is the big schism it's made out to be. I don't know what kind of activity level you expect, when the Nim language itself has few core developers working on it.
It doesn't seem as exciting as those because it doesn't have a whiz-bang-pow killer feature (other than very robust metaprogramming), but it's very mature, and breezy to write high-performance software.
It’s not really. Zig emphasis on it to replace generics is somewhat unique, but ultimately it’s not different than what Nim (and D) have also done for many years.
Nim has a full compile time VM. You can even compile it into a program to run Nim scripts.
Metaprogramming isn't exactly new. I guess the novelty is that its history in the systems language space is spotty, and has only recently become usable in the way a Lisper might want to use it.
Nim, for one. It has an incredibly powerful macro and template system. But other languages with similar macro power include Elixir and Julia.
D has a generic system similar to Nim's, and a mixin system similar to Nim's templates, but doesn't have a powerful AST-manipulating macro system like the above languages.
It's also not a huge issue in most cases because the default is stack-managed pointers passed around by value. So effectively automatic invisible unique pointers. You can construct whole programs without ever touching the `ref` keyword. I've done this in a live commercial deployment.
Nim has a python-like syntax, but I wish they'd gone farther, using `def` instead of `proc` and a `print` function instead of the `echo` statement. Though even if they did those things, I'm not sure it would really feel like programming Python.
As a long-time Python programmer, I was drawn to trying the language partly because of the syntax, but as soon as I tried to write something substantial, Nim's heritage in languages like Pascal, Modula, and Ada starts to show. Syntax notwithstanding, programming in it really felt more like programming in Pascal/Modula.
I in fact did not know anything about Nim's history or design choices when I started using it, but I'm old enough to have written a fair amount of Pascal, and I was not long into using Nim when I started thinking, "this feels weirdly familiar." `type` and `var` blocks, ordinal types, array indexing with enums, etc.
Procedure used to be the common term as opposed to a function which is a mathematical entity that has no side effects. And indeed in Nim func is syntactic sugar for proc {.noSideEffect.}. Naming it def would not make sense because Nim also provides an iterator and a method keyword, whereas def stands for define.
Actually echo is not a statement - Nim's syntax is just much more flexible than Python so what looks like a statement in Python is actually just a UFCS/Command-Line "call" (of macro/template/generic/procedure aka "routine"). It is super easy to roll your own print function [1] and there is no penalty for doing so except that the std lib does not provide a "common parlance". So, that wheel might get reinvented a lot.
A lot of things like this in cligen because it is a leaf dependency (the literally 1..3 identifier CLI "api") and so many "drive by" PLang tester-outers might want to roll a little CLI around some procs their working on.
Also, beyond the echo x,y is same as echo(x,y) or x.echo(y) or x.echo y, the amount of syntax flexibility is dramatically more than Python. You can have user-defined operators like `>>>` or `!!!` or `.*`. There are also some experimental and probably buggy compiler features to do "term re-writing macros" so that your matrix/bignum library could in theory re-write some bz*ax+y expression into a more one-pass loop (or maybe conditionally depending upon problem scale).
I sometimes summarize this as "Nim Is Choice". Some people don't like to have to/get to choose. To others it seems critical.
Someone even did some library to make `def` act like `proc`, but I forget its name. Nim has a lot more routine styles than Python, including a special iterator syntax whose "call" is a for-construct.
If your really want to use the keyword def instead of proc: you can do that with sed.
In all serious-ness, don't do that. I've used Python a lot, but Nim is a different language. Writing the proc keyword helps condition your brain to realize you are writing Nim, not Python.
Nim is indeed a different language, which was the point of my comment, for those who got past the first sentence. However, if folks are going to tout its “python-like” syntax as a selling point, it’s not really fair to then turn around and say, “no, it’s a different language”, when a Python programmer points out that it’s not really all that python-like after all, and maybe it could be more so.
If one is going to take pains to point out that there are good reasons why it is different from Python, then we can carry that as far as we like. There’s no particular reason to use indentation to denote blocks. BEGIN and END worked just fine, after all, and would be more true to Nim’s intellectual heritage. Or maybe just END, and continue to open the block with a colon.
I have been meaning to explore Nim for a while because it feels like "golang, but python syntax and dev experience." I vibe coded a simple tool, tt, that allows me to track time to a central log from all my devices. Realllly simple:
$ tt stats
Time Tracking Stats
Total entries: 39
First entry: Oct 21, 2025 23:04
Last entry: Oct 30, 2025 18:29
Tracking since: 228h 34m
Days tracked: 5
$ tt "working on xyz today"
Logged at 11:38:44
$ tt today
Today (1 entries)
11:38:44 working on xyz today
The code is pretty damn ugly though, I feel like I am working with perl:
proc groupIntoThreads(entries: seq[Entry], threshold: Duration): seq[seq[Entry]] =
if entries.len == 0:
return @[]
var sorted = entries
sorted.sort(proc (a, b: Entry): int =
if a.timestamp < b.timestamp: -1
elif a.timestamp > b.timestamp: 1
else: 0
)
result = @[]
var currentThread = @[sorted[0]]
for i in 1..<sorted.len:
let gap = sorted[i].timestamp - sorted[i-1].timestamp
if gap > threshold:
result.add(currentThread)
currentThread = @[sorted[i]]
else:
currentThread.add(sorted[i])
if currentThread.len > 0:
result.add(currentThread)
What are the `@` characters for? Are they what makes it feel like Perl?
Because other than them I don’t think the equivalent Python code would look much different. Maybe more concise, e.g. you could replace the second section with something like `sorted = entries.sorted(key=lambda entry: entry.timestamp)`.
There are shorter options in Nim too, depending on your stylistic preferences
let sorted = entries.sorted(proc (a, b: Entry): int = cmp(a.timestamp, b.timestamp))
let sorted = entries.sorted((a, b) => cmp(a.timestamp, b.timestamp))
let sorted = entries.sortedByIt(it.timestamp)
I suppose you could change the whole proc to something like
proc groupIntoThreads(entries: seq[Entry], threshold: int): seq[seq[Entry]] =
let sorted = entries.sortedByIt(it.timestamp)
for i, entry in sorted:
if i == 0 or entry.timestamp - sorted[i - 1].timestamp > threshold:
result.add(@[sorted[i]])
else:
result[^1].add(sorted[i])
@[] is syntax for a "seq", which is similar to a C++ vector, ArrayList in Java/C#, or a python list. It's a heap-allocated array that automatically resizes.
In contrast with [], which is mostly identical to a C array: fixed size and lives on the stack.
Nice! Nim has been great for us - fast to code in and even faster once compiled! We're using it for the backend and microservices at https://cxplanner.com and loving it.
The main release note here is more stable async. I’m curious how folks using nim feel about the async situation.
One of the most recent opinions from the discord is:
“ we have async and asyncdispatch but its leaky and bug prone esp when used with threads and causes deep ownership issues, i prefer using taskman when possible but it leaves the IO problem yet unsolved ”
I’ve also been told to just use regular threads whenever possible.
Agreed, Nim is a fantastic language and heavily under-rated. Moved from Swift about 12 months ago and development has never been more
Pleasant.
My only complaint is that the threading/async model and how memory and GC pools are managed per thread took me a bit to get used to, but the speed and C FFI are fantastic.
Also would say that the community is very helpful, particularly on the Discord/IRC channels I have used.
I wish for both to succeed. I'm more of a Nim guy, but it's nice that there is a modernized C-like alternative to C gaining traction.
My biggest complaint about both is the lack of built-in run-time polymorphism. Rust gets you comptime and runtime polymorphism in one complete package. Nim makes use of shallow inheritance, which I find hacky, because it only lets you go one level deep. And Zig's stdlib makes it the norm to construct vtables manually, which is absolutely grotesque in my opinion. Why are we manually creating vtables in a "modern" language in 2025?
I feel qualified to offer a guess as to why: in Zig (and Odin) reuse is mainly done through what basically is templates. This reduces the need for vtables only when true ”plugin” type of objects are the only solution. For Zig and Odin, the only stdlib usages are for allocators and streams. These few usecases are way too few to motivate a full fledged interface feature, and consequently it’s not added.
So it’s both a lack of usecases, as well as a desire to prefer templates over interfaces for reuse, typically due to performance concerns.
Thank you for working on the Nim Compiler. This is great. Another great release. The Nim Compiler continues to move forward.
Thank you very much to everyone who has contributed to the development of this superior language. Nim Compiler continues to be one of the most wonderful languages I have worked with. With the speed of C and the simplicity of Python, it has allowed me to write a lot of cool software.
I do not know where I would be if Nim did not exist in my life.
> with the simplicity of Python
So, not simple at all, then? Python is a very complex language hiding behind friendly syntax.
Do you just mean “with the syntax of Python”? Or does Nim’s similarity to Python go more than skin-deep?
Not the OP, but as an individual who has programmed in Nim on and off for a decade, I feel qualified to answer. The similarities are definitely only skin-deep, and Nim is just as complex, if not more complex than Python.
Nim is much closer to Pascal / Modula / Oberon than Python. The whole - ease/simplicity of Python and speed of C is mostly marketing jargon that the Nim community has been using as long as I've been aware of the project.
I've used Nim a bit, though it's been a while. I've been primarily a Python developer for the past 20 years, with a sprinkling of other languages and paradigms - including languages like Scala and Haskell, so not just OOP stuff.
I characterize Nim as Python with one major difference: where Python prioritizes "developer happiness", Nim prioritized performance. As a result, the syntax looks very similar, the edges are quite a bit rougher, and performance is exponentially better.
It still "feels like" Python in a lot of ways. The ways places if differs feel a lot like Haskell IMO.
How do you find a simple language with abstraction? Pretty much all the "complexity" of the language is juggling its abstraction overhead. Whether that's Haskell's monad transformer stacks or Rust's Send + Sync.
Given the space it's tackling I think Nim is a great effort and refreshing as it keeps a Python like syntax with a Pascal-like feel, which I feel is an underexplored evolution of languages.
Abstraction overhead is very much worth it for non-trivial programs. The "simpler" syntax of languages like Python is a one-time initial gain (and even then, it really only "saves" a tiny bit of boilerplate) that ultimately turns into a big drawback as programs grow more complex and your abstraction possibilities are severely limited due to an overly simplistic initial approach to the code.
This sounds to me like you don't like Python's syntax and abstraction model more than anything else. Which is fine, there's plenty of languages out there.
I find that python has this simplicity other languages lack. Nim has it too. It's hard to strictly define it? Its a bit syntax, a bit lists or dicts, batteries included? A bit how you run it. Maybe a culture of straightforward code - at least in the python 2.x days. Maybe its just you write an algorithm and its easy to follow?
> with the syntax of Python
this library should allow that: https://github.com/hraban/metabang-bind (never tried)
with some limitations: https://github.com/nimpylib/nimpylib/tree/master/doc/mustRew... no "end" argument in print, no triple quote and newline, no "a not in b" (write not (a in b)), no variable named _ (underscore), or double underscore, no slice as foo[:b] where the left part of the slice is not specified, rewrite foo[0:b], etc.
Nim is a complex language, but unlike C/C++/Rust, you can write useful and efficient programs without knowing much about the language.
In practice, it means that unlike most native-compiled languages, if you want a data-oriented approach without having to worry about system details at all, you can do that. Your program will still be strongly typed, but you're not obligated to worry about allocation, reference vs value semantics, ownership, or initialization details. For programs that shouldn't have to worry about those details, the Nim team has done a lot of work to make sure the language gets out of the way and lets you process data. Then, you get a fast binary comparable to the results you'd get from C++ (with a lot more effort).
In buzzword-speak, it's easy to write programs composed of nearly pure business logic while getting C++-level performance.
You've done a lot for the community yourself! Thank you for your excellent libraries and high-visibility usage of Nim at Reddit.
Thanks!
Also of interest, but not yet finished is Nimony (Nim 3.0):
https://nim-lang.org/araq/nimony.html https://github.com/nim-lang/nimony
While it's ecosystem probably does not even match Julia's let alone Python's or the C/FORTRAN-verses, since Nim has been around for almost 20 years and publicly since 2008, there are still a lot of accumulated packages. Some are listed at: https://github.com/ringabout/awesome-nim for really a large (and even so still incomplete!) list of things you might be interested in. Hard to say how well maintained they are. That said, you do probably have to be prepared to do a lot of work yourself and work around compiler limitiations/bugs. Also, binding to C libs is very straightforward with a near trivial FFI.
I suppose it very much depends on the programmer & setting, but like 3 times I've looked for Rust projects similar to Nim ones and found the performance of the Rust quite lacking. Of course, any language that allows you access to assembly makes things ultimately "only" a matter of programmer effort, but the effort to get performance out of Nim seems very competitive in my experience. I've seen at least one ancient 1990s C project be more flexible and much faster in Nim at like 6% the LOC (https://github.com/c-blake/procs for the curious).
nim is memory safe, python syntax, emits c/c++/js. It really deserves more love and publicity.
more mature than zig, much easier than rust.
It's too bad that the BDFL of Nim (Araq / Andreas) treats the language like his personal compiler development playground. This has led to a hard fork of the compiler, many experienced and frustrated developers leaving the community and language behind, and an extremely fragmented ecosystem.
He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
> He is also very difficult to work with and isn't very welcoming to newcomers.
This hasn't been my experience at all.
When I first tried Nim, years ago, I came across an inconsistency in a database connector in the standard library after only a couple of weeks. I pinged him to ask if I was understanding it correctly and confirm it was a bug. He agreed it should be updated, so I put together a pull request. It was reviewed quickly, we went back and forth a couple of times over some details, he asked me to include some documentation updates, and it was merged without issue in a couple of days in total.
Given that I came to the language as a complete newcomer and had commits to the standard library less than three weeks later with the BDFL's approval, I simply can't agree that he's difficult to work with or not welcoming.
YMMV, obviously.
> language like his personal compiler development playground
re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.
> He is also very difficult to work with and isn't very welcoming to newcomers
I don't have full context on the drama behind the fork, but I don't see Araq not being very "welcoming". Araq replies on the forums very consistently, replying to new-comer questions, which one might consider as "simple questions". Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.
From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.
Personally, I see no reason to use the fork (Nimskull) over Nim, nor would I ever see any individual or company picking up Nimskull unless they were very deeply familiar with Nim (this is a small population of people). From a skim of the Nimskull repo, there is no website (there is a copy of the Nim manual), no forums (just some chatrooms), no clear documentation on the future direction, no documentation on differences for someone not familiar with Nim, etc. - why would anyone pick up Nimskull unless they knew Nim well? Please take this as constructive criticism. e.g. if any feature of the language/compiler/tooling is "better" or planned to be better: highlight it, summarize the long GitHub issue/projects discussions in a blog, etc.
> re personal compiler development playground: I don't see this for Nim 2. Nimony/Nim3 is more of a "playground", but rightfully so: he is creating a new major version of the language and aiming to improve the architecture of the compiler.
Araq likes to work on the shiny flashy things he finds fun / interesting to work on. I'm not going to fault him for that, but things like atomics on Windows are still broken. People have been complaining about the stdlib and documentation + lack of a formal specification for at least a decade.
> From what I can tell the fork seems to be due to differences in direction of the language and w.r.t working together: differences in communication styles. But again, I don't know.
There was quite a bit of drama that caused the hard fork to materialize. Differences in communication styles is definitely describing the drama that unfolded, extremely mildly. I don't work on the fork or use it, but some of the more talented compiler developers who were previously contributing to Nim, left Nim to go work on Nimskull.
> Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.
Nope. This is a sop, an equivalent to the non-apology "I'm sorry you took what I said so badly".
Aggression masquerading as "honesty" has no place in any organisation that wants to be taken seriously.
It's most certainly not "OK" when Andreas' personal opinions are expressed in ad-hominem attacks.
Nim unfortunately has a toxic Dictator at the top, and his subordinates defend his behaviours. While this continues nobody should take Nim seriously.
> Nim unfortunately has a toxic Dictator at the top
Araq has opinions that he defends, but you can and absolutely should try to sway or change them. I see this all the time on Discord and Forum. And I see people win over just as much as them losing.
I don't have a strong opinion if this is healthy or not, but it's probably why I would be a bad BDFL =). All in all, I don't think dictatorship is a right word here.
If someone stumbles upon this comment, don't be quick to discard the Nim language. Please do your own research and make your own opinion on the matter.
I believe this and many of comments by tinfoilhatter under this post are not in good faith and in the most charitable interpretation written by a uninformed person or are severely outdated.
> Thanks for the offer, but there's a reason why Nim hemorrhages users as fast as it gains them, and a big reason for that, IMO, is the toxic community which definitely includes the moderation team.
I have to challenge this, because for the last couple years, there have been almost no incidents or drama. Moderation was almost exclusively dealing with spam messages. I think, on the forum, a couple posts were closed because of heated or offtopic discussions. But in all cases, participants were agreeing with the decision of mods (you can see them leaving a 'like' on mod's message).
> There was quite a bit of drama that caused the hard fork to materialize. Differences in communication styles is definitely describing the drama that unfolded, extremely mildly. I don't work on the fork or use it, but some of the more talented compiler developers who were previously contributing to Nim, left Nim to go work on Nimskull.
I know that some of people that left were also the ones causing problems with moderation and being toxic. I don't want anyone to draw strong conclusions, but Nim community was much healthier and friendly after the fork people and certain moderator leaving the project.
> He is also very difficult to work with and isn't very welcoming to newcomers. The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
This is just false. You can see Araq answering the noob questions on the forum all the time. He might be not the best person to do that, because his answers on the short side. I believe, noobs often need more context, examples and explanations than he's providing. But it's thought and effort that counts. Some people even hate when you treat them as complete beginner and try to nourture them common CS knowledge.
> The community "leaders" / moderation team is also full of abrasive individuals with fragile egos.
I certainly hope this isn't the case any longer. As one of the moderators I feel the current group is very patient and welcoming. At least that's what we're trying for, no one is perfect so I'm certain you can find counter examples. But as a whole I think we're doing pretty well. If you have any specific complaints we would love to hear them. They can be left anonymously in our community feedback form, or you can find we anywhere in the community for a chat.
It makes sense you feel that way, as you're one of the moderators. I feel quite differently. Thanks for the offer, but there's a reason why Nim hemorrhages users as fast as it gains them, and a big reason for that, IMO, is the toxic community which definitely includes the moderation team.
> He is also very difficult to work with and isn't very welcoming to newcomers.
That's a charitable way to describe him. In our one direct interaction, he was condescending to the point of insult. (I believe he was incorrect as well, but even if he was always correct, I would consider it wrong to treat someone badly.) After browsing the Nim forum and issue tracker, I found that this was routine behavior for him.
Nim has some nice features, but I don't want to depend on anything that's subject to the whims of a personality like that, and I certainly don't want to interact with him again.
You're right - I probably am being too charitable in my description of him. To his credit, he's gotten better over the years, but I still check in on the forums and find examples of this behavior. Andreas could be the most talented compiler developer in the world, but as long as community members are being treated poorly for asking questions, the language will continue to languish in relative obscurity.
Unfortunately this has been my experience. Andreas was extremely abrasive towards me personally, and views he expressed to me regarding climate change were bizarre and aggressive. His behaviour led me to ditch Nim and explore Go instead, and I couldn't be happier. Sadly Nim is a permanent no-go for me.
> ...and views he expressed to me regarding climate change...
Is that for real? I bet I can find some chocolate chip cookie recipe that the Go team would disagree with me. I ain't ever using Go again.
This isn’t constructive feedback, it’s just you venting and throwing insults. If you actually had something meaningful to discuss, you’d bring specifics, proposals, or examples instead of blanket accusations.
We’re not here to entertain derailments, hostility, or attempts to stir up drama. If your goal is to have a conversation, you need to do better than this.
tinfoilhatter lists some specifics elsewhere in his thread.
These aren’t specifics, it’s the same tired tactic: you disagree with me, so I’ll try to ruin your reputation.
Then offer specifics that contradict mine? It should be easy if all I'm doing is being a contrarian. There are at least a few comments in reply to this post that have echoed my experiences regarding unpleasant interactions with Nim's leadership and community.
I'd like nothing more than for Nim to succeed as a modern systems programming language. Unfortunately, giant egos and personalities constantly get in the way of that goal. There's certainly something holding Nim back from achieving widespread adoption, and if you want to suggest it's me and some sort of concerted effort to toss shade at the language and its evangelists, then that is your perrogative. It certainly isn't moving the language forward.
Zig seems to be even more in flux than Nim yet people can't get enough of it.
With hard fork do you mean the 2.x.x version?
Apologies for not providing a link!
https://github.com/nim-works/nimskull is the hard fork I was referring to.
> The project was started as a fork of Nim … The overall language will be evolved into something entirely different and incompatible.
A hard fork with a goal of being incompatible _sounds_ more strong behaviour on the part of those who forked, than on the original language owner.
I’m sure there’s a lot of context I’m missing. But what is the story behind this?
> I’m sure there’s a lot of context I’m missing. But what is the story behind this?
There was a falling out between the Nim core development team and several volunteer compiler developers. The former seemed to be paying more attention to their personal projects, while still desiring to maintain their positions of control and authority over Nim and its direction. The latter group grew increasingly frustrated, the situation became extremely toxic, and ultimately Nim lost several talented compiler developers to the hard fork.
I believe the goal of being incompatible with Nim resulted from the developers involved in the hard fork feeling like the Nim development team had done a poor job of designing certain portions of the language and compiler. I'm pretty sure they ditched the C++ backend, and made some substantial changes to the langauge to bring it more inline with their ideals.
I'm not involved in the development of either project, so a much better source of information would be the Nimskull project's developers themselves and the core Nim development team.
Last non-bot commit was over 2 weeks ago, and it seems to be mostly 1 account working on it. I don't think it looks active enough to be the big schism it's made out to be?
Nim itself has very few core developers. Comparing the number of developers involved in a hard fork to the number of Nim developers is silly, in my opinion at least.
The project has 21.5k commits authored, most of them oriented at replacing the existing compiler backend with a CPS-oriented one. Nim 3.0 is replacing the backend with one that is focused on CPS. There is no doubt that the developers responsible for the hard fork of Nim inspired Nim 3.0.
Yes, it very much is the big schism it's made out to be. I don't know what kind of activity level you expect, when the Nim language itself has few core developers working on it.
> python syntax
I don't mind but many do so I don't see this as a plus.
How does it compare with Crystal?
One of the main differences is that Nim is not object-oriented.
Syntactically, like Python compares to Ruby.
It doesn't seem as exciting as those because it doesn't have a whiz-bang-pow killer feature (other than very robust metaprogramming), but it's very mature, and breezy to write high-performance software.
> other than very robust metaprogramming
lol then i guess zig's comptime isn't a "whiz-bang-pow killer feature" either
It’s not really. Zig emphasis on it to replace generics is somewhat unique, but ultimately it’s not different than what Nim (and D) have also done for many years.
Nim has a full compile time VM. You can even compile it into a program to run Nim scripts.
Metaprogramming isn't exactly new. I guess the novelty is that its history in the systems language space is spotty, and has only recently become usable in the way a Lisper might want to use it.
what programming languages have the metaprogramming capabilities that a lisper would want to look at to learn/use it?
Nim, for one. It has an incredibly powerful macro and template system. But other languages with similar macro power include Elixir and Julia.
D has a generic system similar to Nim's, and a mixin system similar to Nim's templates, but doesn't have a powerful AST-manipulating macro system like the above languages.
Since Nim GC approach seems to be a common topic of discussion, providing link below on more details:
https://nim-lang.org/docs/mm.html
It's also not a huge issue in most cases because the default is stack-managed pointers passed around by value. So effectively automatic invisible unique pointers. You can construct whole programs without ever touching the `ref` keyword. I've done this in a live commercial deployment.
Nim has a python-like syntax, but I wish they'd gone farther, using `def` instead of `proc` and a `print` function instead of the `echo` statement. Though even if they did those things, I'm not sure it would really feel like programming Python.
As a long-time Python programmer, I was drawn to trying the language partly because of the syntax, but as soon as I tried to write something substantial, Nim's heritage in languages like Pascal, Modula, and Ada starts to show. Syntax notwithstanding, programming in it really felt more like programming in Pascal/Modula.
I in fact did not know anything about Nim's history or design choices when I started using it, but I'm old enough to have written a fair amount of Pascal, and I was not long into using Nim when I started thinking, "this feels weirdly familiar." `type` and `var` blocks, ordinal types, array indexing with enums, etc.
From https://nim-lang.org/faq.html :
Why is it named proc?
Procedure used to be the common term as opposed to a function which is a mathematical entity that has no side effects. And indeed in Nim func is syntactic sugar for proc {.noSideEffect.}. Naming it def would not make sense because Nim also provides an iterator and a method keyword, whereas def stands for define.
Actually echo is not a statement - Nim's syntax is just much more flexible than Python so what looks like a statement in Python is actually just a UFCS/Command-Line "call" (of macro/template/generic/procedure aka "routine"). It is super easy to roll your own print function [1] and there is no penalty for doing so except that the std lib does not provide a "common parlance". So, that wheel might get reinvented a lot.
A lot of things like this in cligen because it is a leaf dependency (the literally 1..3 identifier CLI "api") and so many "drive by" PLang tester-outers might want to roll a little CLI around some procs their working on.
Also, beyond the echo x,y is same as echo(x,y) or x.echo(y) or x.echo y, the amount of syntax flexibility is dramatically more than Python. You can have user-defined operators like `>>>` or `!!!` or `.*`. There are also some experimental and probably buggy compiler features to do "term re-writing macros" so that your matrix/bignum library could in theory re-write some bz*ax+y expression into a more one-pass loop (or maybe conditionally depending upon problem scale).
I sometimes summarize this as "Nim Is Choice". Some people don't like to have to/get to choose. To others it seems critical.
Someone even did some library to make `def` act like `proc`, but I forget its name. Nim has a lot more routine styles than Python, including a special iterator syntax whose "call" is a for-construct.
[1] https://github.com/c-blake/cligen/blob/master/cligen/print.n...
If your really want to use the keyword def instead of proc: you can do that with sed.
In all serious-ness, don't do that. I've used Python a lot, but Nim is a different language. Writing the proc keyword helps condition your brain to realize you are writing Nim, not Python.
Nim is indeed a different language, which was the point of my comment, for those who got past the first sentence. However, if folks are going to tout its “python-like” syntax as a selling point, it’s not really fair to then turn around and say, “no, it’s a different language”, when a Python programmer points out that it’s not really all that python-like after all, and maybe it could be more so.
If one is going to take pains to point out that there are good reasons why it is different from Python, then we can carry that as far as we like. There’s no particular reason to use indentation to denote blocks. BEGIN and END worked just fine, after all, and would be more true to Nim’s intellectual heritage. Or maybe just END, and continue to open the block with a colon.
I have been meaning to explore Nim for a while because it feels like "golang, but python syntax and dev experience." I vibe coded a simple tool, tt, that allows me to track time to a central log from all my devices. Realllly simple:
The code is pretty damn ugly though, I feel like I am working with perl:What are the `@` characters for? Are they what makes it feel like Perl?
Because other than them I don’t think the equivalent Python code would look much different. Maybe more concise, e.g. you could replace the second section with something like `sorted = entries.sorted(key=lambda entry: entry.timestamp)`.
There are shorter options in Nim too, depending on your stylistic preferences
I suppose you could change the whole proc to something like`@` makes the array (stack allocated) into a sequence (heap allocated).
Edit: Just read the second half of your post—
> I don’t think the equivalent Python code would look much different. Maybe more concise
He could be leveraging [std/sugar](https://nim-lang.org/docs/sugar.html) to make this look cleaner.
@[] is syntax for a "seq", which is similar to a C++ vector, ArrayList in Java/C#, or a python list. It's a heap-allocated array that automatically resizes.
In contrast with [], which is mostly identical to a C array: fixed size and lives on the stack.
Yeah, the code doesn't seem very Perl-ish to me.
Nice! Nim has been great for us - fast to code in and even faster once compiled! We're using it for the backend and microservices at https://cxplanner.com and loving it.
The main release note here is more stable async. I’m curious how folks using nim feel about the async situation.
One of the most recent opinions from the discord is:
“ we have async and asyncdispatch but its leaky and bug prone esp when used with threads and causes deep ownership issues, i prefer using taskman when possible but it leaves the IO problem yet unsolved ”
I’ve also been told to just use regular threads whenever possible.
Do others have more info or sentiments to share?
Agreed, Nim is a fantastic language and heavily under-rated. Moved from Swift about 12 months ago and development has never been more Pleasant.
My only complaint is that the threading/async model and how memory and GC pools are managed per thread took me a bit to get used to, but the speed and C FFI are fantastic.
Also would say that the community is very helpful, particularly on the Discord/IRC channels I have used.
I had completely forgot about Nim. It was trending a while back, but now it seems all the fanfare is around Zig instead.
I wish for both to succeed. I'm more of a Nim guy, but it's nice that there is a modernized C-like alternative to C gaining traction.
My biggest complaint about both is the lack of built-in run-time polymorphism. Rust gets you comptime and runtime polymorphism in one complete package. Nim makes use of shallow inheritance, which I find hacky, because it only lets you go one level deep. And Zig's stdlib makes it the norm to construct vtables manually, which is absolutely grotesque in my opinion. Why are we manually creating vtables in a "modern" language in 2025?
I feel qualified to offer a guess as to why: in Zig (and Odin) reuse is mainly done through what basically is templates. This reduces the need for vtables only when true ”plugin” type of objects are the only solution. For Zig and Odin, the only stdlib usages are for allocators and streams. These few usecases are way too few to motivate a full fledged interface feature, and consequently it’s not added. So it’s both a lack of usecases, as well as a desire to prefer templates over interfaces for reuse, typically due to performance concerns.
My monthly reminder that I really should resume my Learning Nim series :( https://www.youtube.com/@Nimward