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.
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 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 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.
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.
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.
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)
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.
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.
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.
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.
As one who was interested by Nim and tried it out for some personal projects, I found that this was the biggest problem with the project. There's several options for any given need (including internal tools like LSP or installing the compiler) with very little clear way to choose between them. Each will have different (dis)advantages that you must discover primarily by digging through forum posts or GitHub issues.
In some ways it's the sign of a very strong language, like the curse of Lisp: someone can easily just write their own version of whatever they need. But as a user trying to navigate the ecosystem it is frustrating. I do keep meaning to try it out again though; the language itself is very pleasant to use.
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?
for anyone reading this, and curious, i'm learning nim with raylib. (naylib is the nim wrapper around raylib). and i'm making the code comments and the display show what's happening, making the nim files into discrete lessons, for myself as well as you. as of today's date, i've done the vectors and most of the graphics lessons, with sound effects coming soon.. https://github.com/stOneskull/nim
treeform|4 months ago
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.
pansa2|4 months ago
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?
SJMG|4 months ago
sld|4 months ago
https://nim-lang.org/araq/nimony.html https://github.com/nim-lang/nimony
cb321|4 months ago
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).
synergy20|4 months ago
more mature than zig, much easier than rust.
netbioserror|4 months ago
metaltyphoon|4 months ago
I don't mind but many do so I don't see this as a plus.
postepowanieadm|4 months ago
tinfoilhatter|4 months ago
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.
stefantalpalaru|4 months ago
[deleted]
ThomasTJdev|4 months ago
jp57|4 months ago
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.
cenamus|4 months ago
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.
cb321|4 months ago
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...
whalesalad|4 months ago
miguel_martin|4 months ago
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.
alberth|4 months ago
https://nim-lang.org/docs/mm.html
netbioserror|4 months ago
tokyovigilante|4 months ago
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.
banashark|4 months ago
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?
b3morales|4 months ago
In some ways it's the sign of a very strong language, like the curse of Lisp: someone can easily just write their own version of whatever they need. But as a user trying to navigate the ecosystem it is frustrating. I do keep meaning to try it out again though; the language itself is very pleasant to use.
didibus|4 months ago
seanw444|4 months ago
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?
xwowsersx|4 months ago
stOneskull|3 months ago