[HN Gopher] Nim 2.2.6
___________________________________________________________________
Nim 2.2.6
Author : xz18r
Score : 143 points
Date : 2025-10-31 14:15 UTC (8 hours ago)
(HTM) web link (nim-lang.org)
(TXT) w3m dump (nim-lang.org)
| synergy20 wrote:
| 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.
| netbioserror wrote:
| 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.
| almostgotcaught wrote:
| > other than very robust metaprogramming
|
| lol then i guess zig's comptime isn't a "whiz-bang-pow killer
| feature" either
| netbioserror wrote:
| 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.
| QQ00 wrote:
| what programming languages have the metaprogramming
| capabilities that a lisper would want to look at to
| learn/use it?
| elcritch wrote:
| 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.
| metaltyphoon wrote:
| > python syntax
|
| I don't mind but many do so I don't see this as a plus.
| tinfoilhatter wrote:
| 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.
| cenamus wrote:
| With hard fork do you mean the 2.x.x version?
| tinfoilhatter wrote:
| Apologies for not providing a link!
|
| https://github.com/nim-works/nimskull is the hard fork I
| was referring to.
| vintagedave wrote:
| > 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?
| tinfoilhatter wrote:
| > 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.
| wmf wrote:
| Zig seems to be even more in flux than Nim yet people can't
| get enough of it.
| miguel_martin wrote:
| > 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.
| tinfoilhatter wrote:
| > 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.
| austinjp wrote:
| > 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.
| foresto wrote:
| > 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.
| tinfoilhatter wrote:
| 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.
| PMunch wrote:
| > 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.
| tinfoilhatter wrote:
| 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.
| planetis wrote:
| 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.
| austinjp wrote:
| tinfoilhatter lists some specifics elsewhere in his thread.
| planetis wrote:
| These aren't specifics, it's the same tired tactic: you
| disagree with me, so I'll try to ruin your reputation.
| austinjp wrote:
| 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.
| postepowanieadm wrote:
| How does it compare with Crystal?
| michaelcampbell wrote:
| Syntactically, like Python compares to Ruby.
| xigoi wrote:
| One of the main differences is that Nim is not object-
| oriented.
| alberth wrote:
| 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
| netbioserror wrote:
| 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.
| sld wrote:
| 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
| jp57 wrote:
| 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.
| cenamus wrote:
| 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.
| whalesalad wrote:
| 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)
| pansa2 wrote:
| 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)`.
| johnisgood wrote:
| Yeah, the code doesn't seem very Perl-ish to me.
| SJMG wrote:
| `@` 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.
| juki wrote:
| 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])
| auxym wrote:
| @[] 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.
| cb321 wrote:
| 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...
| miguel_martin wrote:
| 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.
| jp57 wrote:
| 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.
| treeform wrote:
| 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.
| SJMG wrote:
| You've done a lot for the community yourself! Thank you for
| your excellent libraries and high-visibility usage of Nim at
| Reddit.
| treeform wrote:
| Thanks!
| pansa2 wrote:
| > _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?
| tinfoilhatter wrote:
| 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.
| netbioserror wrote:
| 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.
| Karrot_Kream wrote:
| 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.
| zozbot234 wrote:
| 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.
| Karrot_Kream wrote:
| 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.
| vindarel wrote:
| > 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/t
| ree/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.
| treeform wrote:
| 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?
| xigoi wrote:
| Nim is a complex language, but unlike C/C++/Rust, you can
| write useful and efficient programs without knowing much
| about the language.
| didibus wrote:
| I had completely forgot about Nim. It was trending a while back,
| but now it seems all the fanfare is around Zig instead.
| seanw444 wrote:
| 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?
| ThomasTJdev wrote:
| 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.
| cb321 wrote:
| 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).
| xwowsersx wrote:
| My monthly reminder that I really should resume my Learning Nim
| series :( https://www.youtube.com/@Nimward
| tokyovigilante wrote:
| 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.
| banashark wrote:
| 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?
___________________________________________________________________
(page generated 2025-10-31 23:02 UTC)