12 ms·

Nim Version 1.6.6 Released

126 points by shaftoe444 4y ago

WithinReason 4y ago
There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason
- cardanome 4y ago
  People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.
  - ezst 4y ago
    What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
    - xigoi 4y ago
      The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.
- rich_sasha 4y ago
  It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.
  - nimmer 4y ago
    Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.
    - rich_sasha 4y ago
      If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.
      - PMunch 4y ago
        The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python. And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
        rich_sasha 4y ago
        Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main... I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions? IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools. The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then? In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
- christophilus 4y ago
  It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.
  - PMunch 4y ago
    Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.
  - sausage_dog 4y ago
    Nim has a tool called nimpretty similar to gofmt
    - xigoi 4y ago
      As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.
  - xigoi 4y ago
    gofmt doesn't seem to ensure consistency in naming styles.
- Symmetry 4y ago
  My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.
  - nimmer 4y ago
    This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.
    - Symmetry 4y ago
      If you define them both yes, but you're still free to use them both. var my_var = 1 myVar += 1 echo(my_var) Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
      - def- 4y ago
        nim --styleCheck:error c x This enforces the same capitalization style in your code: x.nim(1, 5) Error: 'my_var' should be: 'myVar'
      - nimmer 4y ago
        You can use --styleCheck:usages or a linter to ensure that the style is uniform. You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion. Also you can use nimgrep if have to search across projects written by different people.
      - arc776 4y ago
        Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.
styeco 4y ago
I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds real-life adoption of the whole thing to a halt.
- jthrowsitaway 4y ago
  MS Defender flags binaries that have been compressed by upx. It's really annoying because upx is a great way to shrink binaries.
- PMunch 4y ago
  We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.
  - GordonS 4y ago
    Are Nim Windows binaries signed with Authenticode? If not, it's possible to get reasonably priced code signing certificates.
  - guiriduro 4y ago
    Yep, I mean, if the virus defence community took the same blanket, lazy approach with C and C++ compilers because viruses can be written in those, too (shock horror!) they'd be shutdown by some big players very fast.
    - nyanpasu64 4y ago
      I hear (but have not personally seen recently) that MinGW-compiled EXEs are falsely detected as malware by some programs: https://stackoverflow.com/questions/62364507/compiled-c-executable-is-detected-as-a-virus-by-windows-defender https://stackoverflow.com/questions/62364507/compiled-c-exec...
ZoomZoomZoom 4y ago
For all those who are really interested in the language and have at least a small amount of experience with it already: Nim is ripe for contributing! While the main team works on bigger things drawing v2 closer, there's still lots of issues of various magnitude and lots of housekeeping bits that can be done while getting yourself acquainted with the project's structure. Here's a few links for your consideration: * https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aope... * https://dev.to/xflywind/best-ways-to-make-your-first-contribution-to-nim-language-4ml2 https://dev.to/xflywind/best-ways-to-make-your-first-contrib... * https://nim-lang.github.io/Nim/contributing.html https://nim-lang.github.io/Nim/contributing.html
- the_duke 4y ago
  What's on the roadmap for v2?
  - WithinReason 4y ago
    https://github.com/nim-lang/RFCs/issues/437 https://github.com/nim-lang/RFCs/issues/437
cumshitpiss 4y ago
Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus
- PMunch 4y ago
  Well it depends a bit on your usecases. Nim certainly has a stricter type system, and since it is compiled you can be fairly certain that a program you have compiled won't suddenly start to misbehave (e.g. no JavaScript leftpad issue since it won't pull in libraries on runtime). The packaging system is fine for most purposes, and it recently got better with the introduction of lock-files. Once you get comfortable with the standard library and your favorite packages it's also very fast to write, maybe even more so than Python because it has less boilerplate. As for numpy there are libraries that allow you to work with Python from Nim, and vice-versa. Not entirely sure how well they work for numpy as I haven't tried that myself. But there are also packages which does similar things in Nim. However packages will probably be your biggest hurdle when converting stuff to Nim. The Nim ecosystem is definitely smaller than Pythons, so it's a bit hit-or-miss if it has the packages you need for your specific usecases. You are more than welcome to join the Discord/IRC/Matrix room and ask around though.
- cardanome 4y ago
  I think out of the bunch of new system programming languages it sure is the most friendly towards users coming from dynamic programming languages. My nim solutions were actually more concise than my JS code when doing some Advent Of Code puzzles. And it has nimpy which is a bridge to the Python world though I haven't used it personally. The only downside I can think of regarding nim is that the standard library is OK-ish I guess but not great. Still needs some work but I think they are aware of it.
- deleted 4y ago
  [deleted]
- pietroppeter 4y ago
  yes, definitely for me nim has replaced python as my go to language even for small tasks. I find it even more productive than python thanks to the typing system. An often neglected highlight that I appreciate a lot is the fact that static typing + procedure overload has the additional benefit that names of functions tend to be very natural (you can reuse the name of function if the type signature is different). That along with UFCS (universal function call syntax), allows to create great apis in no times. Also template are a very easy way to boost productivity and allow to write great DSLs. See also an old but still relevant and very valid introduction of Nim for Python programmers [0] It can work with numpy and even better there is a performant numpy replacement called arraymancer. Take into account that since you do not need to be afraid of loops, even working with standard sequences is very performant. See also the SciNim getting started book [1] [0]: https://blog.zdsmith.com/posts/nim-for-python-programmers.html https://blog.zdsmith.com/posts/nim-for-python-programmers.ht... [1]: https://scinim.github.io/getting-started/ https://scinim.github.io/getting-started/
rosetremiere 4y ago
A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.
- sharno 4y ago
  Lean the theorem proving language?
  - rosetremiere 4y ago
    Indeed, though I have no quote or link for this "claim".
    - xigoi 4y ago
      Well, functional programming is very natural for theorem provers, especially those based on the Curry-Howard correspondence.
- rkallos 4y ago
  It sounds to me like you might enjoy SML or OCaml.
  - maleldil 4y ago
    The ergonomics of both are more oriented towards functional programming rather than imperative. Rust is still primarily imperative with great APIs for functional programming.
- eklavya 4y ago
  Absolutely, I think there is a huge opportunity here. A rust+gc lang which has seamless ffi with rust would be a killer in my opinion.
  - 4y ago
carterza 4y ago
I started programming in Nim around 2015 and still write code in it from time to time. At this point I would have a tough time suggesting the language to anyone for much. While you can certainly accomplish almost any programming task with Nim, how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off. There are other major warts with Nim, which I'll outline briefly below. 1) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed. 2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community. 3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project. Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull https://github.com/nim-works/nimskull Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them. My advice would be to look elsewhere.
- SolitudeSF 4y ago

126 points by shaftoe444 4y ago

There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason

cardanome 4y ago
People really care about weird stuff. There is trade offs to both sensitivity and insensitivity. Just because you are used to one approach from your favorite programming language does not mean the other way is "wrong". Want a consistent style? Use that nice --styleCheck:usages option. No problem at all. Honestly, I think Nim should keep the current approach just to filter out certain people.
- ezst 4y ago
  What are the arguments for insensitivity? I'm not used to it, and it seems to my rookie eyes that it only opens venues for confusion (forcing to pay closer attention to symbols to mentally "de duplicate" them), inconsistencies within a same/foreign code base that make joining a project/jumping into an external library just slightly harder, and more vim/emacs/tab/spaces jihads.
  - xigoi 4y ago
    The main advantage is that you can follow a consistent style in your codebase even if your dependencies follow a different style, so you don't have a situation like in Python where if you use the unittest module, you're forced into not following PEP8.
rich_sasha 4y ago
It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.
- nimmer 4y ago
  Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.
  - rich_sasha 4y ago
    If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.
    - PMunch 4y ago
      The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python. And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
      - rich_sasha 4y ago
        Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main... I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions? IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools. The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then? In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
christophilus 4y ago
It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.
- PMunch 4y ago
  Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.
- sausage_dog 4y ago
  Nim has a tool called nimpretty similar to gofmt
  - xigoi 4y ago
    As a frequent Nim user, I've tried it a few times and it doesn't seem to do much, other than reflow lines in not very logical places. I'd prefer an uncompromising formatter like Black/Prettier/StyLua.
- xigoi 4y ago
  gofmt doesn't seem to ensure consistency in naming styles.
Symmetry 4y ago
My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.
- nimmer 4y ago
  This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.
  - Symmetry 4y ago
    If you define them both yes, but you're still free to use them both. var my_var = 1 myVar += 1 echo(my_var) Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
    - def- 4y ago
      nim --styleCheck:error c x This enforces the same capitalization style in your code: x.nim(1, 5) Error: 'my_var' should be: 'myVar'
    - nimmer 4y ago
      You can use --styleCheck:usages or a linter to ensure that the style is uniform. You cane enable styleCheck:usages by default in the compiler. Also, most editors do variable/proc autocompletion. Also you can use nimgrep if have to search across projects written by different people.
    - arc776 4y ago
      Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it. Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.

styeco 4y ago

I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds real-life adoption of the whole thing to a halt.

jthrowsitaway 4y ago
MS Defender flags binaries that have been compressed by upx. It's really annoying because upx is a great way to shrink binaries.
PMunch 4y ago
We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.
- GordonS 4y ago
  Are Nim Windows binaries signed with Authenticode? If not, it's possible to get reasonably priced code signing certificates.
- guiriduro 4y ago
  Yep, I mean, if the virus defence community took the same blanket, lazy approach with C and C++ compilers because viruses can be written in those, too (shock horror!) they'd be shutdown by some big players very fast.
  - nyanpasu64 4y ago
    I hear (but have not personally seen recently) that MinGW-compiled EXEs are falsely detected as malware by some programs: https://stackoverflow.com/questions/62364507/compiled-c-executable-is-detected-as-a-virus-by-windows-defender https://stackoverflow.com/questions/62364507/compiled-c-exec...

ZoomZoomZoom 4y ago

For all those who are really interested in the language and have at least a small amount of experience with it already: Nim is ripe for contributing! While the main team works on bigger things drawing v2 closer, there's still lots of issues of various magnitude and lots of housekeeping bits that can be done while getting yourself acquainted with the project's structure. Here's a few links for your consideration: * https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/nim-lang/Nim/issues?q=is%3Aissue+is%3Aope... * https://dev.to/xflywind/best-ways-to-make-your-first-contribution-to-nim-language-4ml2 https://dev.to/xflywind/best-ways-to-make-your-first-contrib... * https://nim-lang.github.io/Nim/contributing.html https://nim-lang.github.io/Nim/contributing.html

the_duke 4y ago
What's on the roadmap for v2?
- WithinReason 4y ago
  https://github.com/nim-lang/RFCs/issues/437 https://github.com/nim-lang/RFCs/issues/437

cumshitpiss 4y ago

Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus

PMunch 4y ago
Well it depends a bit on your usecases. Nim certainly has a stricter type system, and since it is compiled you can be fairly certain that a program you have compiled won't suddenly start to misbehave (e.g. no JavaScript leftpad issue since it won't pull in libraries on runtime). The packaging system is fine for most purposes, and it recently got better with the introduction of lock-files. Once you get comfortable with the standard library and your favorite packages it's also very fast to write, maybe even more so than Python because it has less boilerplate. As for numpy there are libraries that allow you to work with Python from Nim, and vice-versa. Not entirely sure how well they work for numpy as I haven't tried that myself. But there are also packages which does similar things in Nim. However packages will probably be your biggest hurdle when converting stuff to Nim. The Nim ecosystem is definitely smaller than Pythons, so it's a bit hit-or-miss if it has the packages you need for your specific usecases. You are more than welcome to join the Discord/IRC/Matrix room and ask around though.
cardanome 4y ago
I think out of the bunch of new system programming languages it sure is the most friendly towards users coming from dynamic programming languages. My nim solutions were actually more concise than my JS code when doing some Advent Of Code puzzles. And it has nimpy which is a bridge to the Python world though I haven't used it personally. The only downside I can think of regarding nim is that the standard library is OK-ish I guess but not great. Still needs some work but I think they are aware of it.
deleted 4y ago
[deleted]
pietroppeter 4y ago
yes, definitely for me nim has replaced python as my go to language even for small tasks. I find it even more productive than python thanks to the typing system. An often neglected highlight that I appreciate a lot is the fact that static typing + procedure overload has the additional benefit that names of functions tend to be very natural (you can reuse the name of function if the type signature is different). That along with UFCS (universal function call syntax), allows to create great apis in no times. Also template are a very easy way to boost productivity and allow to write great DSLs. See also an old but still relevant and very valid introduction of Nim for Python programmers [0] It can work with numpy and even better there is a performant numpy replacement called arraymancer. Take into account that since you do not need to be afraid of loops, even working with standard sequences is very performant. See also the SciNim getting started book [1] [0]: https://blog.zdsmith.com/posts/nim-for-python-programmers.html https://blog.zdsmith.com/posts/nim-for-python-programmers.ht... [1]: https://scinim.github.io/getting-started/ https://scinim.github.io/getting-started/

rosetremiere 4y ago

A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo). I've heard the claim that lean is going in this direction.

sharno 4y ago
Lean the theorem proving language?
- rosetremiere 4y ago
  Indeed, though I have no quote or link for this "claim".
  - xigoi 4y ago
    Well, functional programming is very natural for theorem provers, especially those based on the Curry-Howard correspondence.
rkallos 4y ago
It sounds to me like you might enjoy SML or OCaml.
- maleldil 4y ago
  The ergonomics of both are more oriented towards functional programming rather than imperative. Rust is still primarily imperative with great APIs for functional programming.
eklavya 4y ago
Absolutely, I think there is a huge opportunity here. A rust+gc lang which has seamless ffi with rust would be a killer in my opinion.
- 4y ago

carterza 4y ago

I started programming in Nim around 2015 and still write code in it from time to time. At this point I would have a tough time suggesting the language to anyone for much. While you can certainly accomplish almost any programming task with Nim, how much frustration you will encounter fighting the compiler and broken / under-specified language features and semantics might be a turn-off. There are other major warts with Nim, which I'll outline briefly below. 1) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed. 2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community. 3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project. Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull https://github.com/nim-works/nimskull Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them. My advice would be to look elsewhere.

SolitudeSF 4y ago