9 ms·

Nim 2.2.6

164 points by xz18r 11mo ago

synergy20 11mo ago
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 11mo ago
  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 11mo ago
    > other than very robust metaprogramming lol then i guess zig's comptime isn't a "whiz-bang-pow killer feature" either
    - netbioserror 11mo ago
      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 11mo ago
        what programming languages have the metaprogramming capabilities that a lisper would want to look at to learn/use it?
        netbioserror 11mo ago
        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.
        almostgotcaught 11mo ago
        this is like asking which restaurants have mom's cooking - none but there are plenty that are close enough and don't require you to travel all the way back to wherever your moms lives.
      - almostgotcaught 11mo ago
        > Metaprogramming isn't exactly new My guy what exactly do you think comptime is? More to the point: what exactly do you think metaprogramming is...?
        netbioserror 11mo ago
        Metaprogramming is writing programs that generate programs. It's been around since the beginning of programming languages. I'm still not sure what you're trying to dunk on me with here.
    - elcritch 11mo ago
      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 11mo ago
  > python syntax I don't mind but many do so I don't see this as a plus.
- tinfoilhatter 11mo ago
  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 11mo ago
    With hard fork do you mean the 2.x.x version?
    - tinfoilhatter 11mo ago
      Apologies for not providing a link! https://github.com/nim-works/nimskull https://github.com/nim-works/nimskull is the hard fork I was referring to.
      - vintagedave 11mo ago
        > 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 11mo ago
        > 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.
- postepowanieadm 11mo ago
  How does it compare with Crystal?
  - michaelcampbell 11mo ago
    Syntactically, like Python compares to Ruby.
  - xigoi 11mo ago
    One of the main differences is that Nim is not object-oriented.
- stefantalpalaru 11mo ago
  [dead]
alberth 11mo ago
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 https://nim-lang.org/docs/mm.html
- netbioserror 11mo ago
  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 11mo ago
Also of interest, but not yet finished is Nimony (Nim 3.0): https://nim-lang.org/araq/nimony.html https://nim-lang.org/araq/nimony.html https://github.com/nim-lang/nimony https://github.com/nim-lang/nimony
jp57 11mo ago
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 11mo ago
  From https://nim-lang.org/faq.html 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 11mo ago
  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)
treeform 11mo ago
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 11mo ago
  You've done a lot for the community yourself! Thank you for your excellent libraries and high-visibility usage of Nim at Reddit.
  - treeform 11mo ago
    Thanks!
- pansa2 11mo ago
  > 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 11mo ago
    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 11mo ago
    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.
didibus 11mo ago
I had completely forgot about Nim. It was trending a while back, but now it seems all the fanfare is around Zig instead.
- seanw444 11mo ago
  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?
  - lerno 11mo ago
    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.
ThomasTJdev 11mo ago
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 https://cxplanner.com and loving it.
cb321 11mo ago
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 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 https://github.com/c-blake/procs for the curious).
xwowsersx 11mo ago
My monthly reminder that I really should resume my Learning Nim series :( https://www.youtube.com/@Nimward https://www.youtube.com/@Nimward
- stOneskull 11mo ago
  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 https://github.com/stOneskull/nim
tokyovigilante 11mo ago
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 11mo ago
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?
- b3morales 11mo ago
  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.

164 points by xz18r 11mo ago

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 11mo ago
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 11mo ago
  > other than very robust metaprogramming lol then i guess zig's comptime isn't a "whiz-bang-pow killer feature" either
  - netbioserror 11mo ago
    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 11mo ago
      what programming languages have the metaprogramming capabilities that a lisper would want to look at to learn/use it?
      - netbioserror 11mo ago
        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.
      - almostgotcaught 11mo ago
        this is like asking which restaurants have mom's cooking - none but there are plenty that are close enough and don't require you to travel all the way back to wherever your moms lives.
    - almostgotcaught 11mo ago
      > Metaprogramming isn't exactly new My guy what exactly do you think comptime is? More to the point: what exactly do you think metaprogramming is...?
      - netbioserror 11mo ago
        Metaprogramming is writing programs that generate programs. It's been around since the beginning of programming languages. I'm still not sure what you're trying to dunk on me with here.
  - elcritch 11mo ago
    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 11mo ago
> python syntax I don't mind but many do so I don't see this as a plus.
tinfoilhatter 11mo ago
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 11mo ago
  With hard fork do you mean the 2.x.x version?
  - tinfoilhatter 11mo ago
    Apologies for not providing a link! https://github.com/nim-works/nimskull https://github.com/nim-works/nimskull is the hard fork I was referring to.
    - vintagedave 11mo ago
      > 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 11mo ago
        > 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.
postepowanieadm 11mo ago
How does it compare with Crystal?
- michaelcampbell 11mo ago
  Syntactically, like Python compares to Ruby.
- xigoi 11mo ago
  One of the main differences is that Nim is not object-oriented.
stefantalpalaru 11mo ago
[dead]

alberth 11mo ago

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 https://nim-lang.org/docs/mm.html

netbioserror 11mo ago
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 11mo ago

Also of interest, but not yet finished is Nimony (Nim 3.0): https://nim-lang.org/araq/nimony.html https://nim-lang.org/araq/nimony.html https://github.com/nim-lang/nimony https://github.com/nim-lang/nimony

jp57 11mo ago

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 11mo ago
From https://nim-lang.org/faq.html 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 11mo ago
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)

treeform 11mo ago

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 11mo ago
You've done a lot for the community yourself! Thank you for your excellent libraries and high-visibility usage of Nim at Reddit.
- treeform 11mo ago
  Thanks!
pansa2 11mo ago
> 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 11mo ago
  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 11mo ago
  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.

didibus 11mo ago

I had completely forgot about Nim. It was trending a while back, but now it seems all the fanfare is around Zig instead.

seanw444 11mo ago
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?
- lerno 11mo ago
  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.

ThomasTJdev 11mo ago

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 https://cxplanner.com and loving it.

cb321 11mo ago

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 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 https://github.com/c-blake/procs for the curious).

xwowsersx 11mo ago

My monthly reminder that I really should resume my Learning Nim series :( https://www.youtube.com/@Nimward https://www.youtube.com/@Nimward

stOneskull 11mo ago
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 https://github.com/stOneskull/nim

tokyovigilante 11mo ago

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 11mo ago

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?

b3morales 11mo ago
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.