Disclaimer: Note that I don't want to attack anyone, this is just my personal opinion.
I've wanted to talk about this for a while now: Nim, specifically the compiler, is very buggy in my experience. And I'm not talking about experimental features, where bugs are to be expected, but (supposedly) stable language features, like iterators, generics and templates. I also found quite some bugs myself (something I haven't managed with any other language so far, although Nim is smaller than those, so my perception may be skewed), simply by playing around a bit, testing stuff from the manual or even running the test suites on all backends (C, JS, VM). Sometimes, I see people calling Nim mature, which strikes me as odd, since my experience is exactly the opposite. I'll be honest, I've never used Nim for more than playing around (and contributing to the stdlib), in fact, I don't feel confident in using it for anything bigger, since I'm almost certain that I'd find more bugs, which is demotivating.
I know, Nim has very few core contributors and they have lots of stuff to do (and they're doing a great job), but I don't think that's the only problem. It seems to me that many features are implemented without a proper spec or considering edge cases (e.g. #19013, #17632). I also feel like bugs aren't prioritized enough (especially when they're about edge cases, that "noone will encounter", e.g. #18777 (comment), #16361 (comment)). And please, don't come at me with "Why don't you fix these bugs yourself?", that's not how it works (note that I don't mean something like RFC #392 (comment)). Contributing to the compiler is not as easy as it may seem, especially when you have no idea how it works. I might try to contribute in the future (I already did technically, though that was a really minor change), but I doubt comments like this actually encourage anyone to contribute.
If you're considering whether or not to learn Nim: I don't want to discourage you, I think it's a good language with lots of great ideas and high potential and you should definitely check it out! However, I don't think it's mature enough to be used in production (although I've never done any professional programming, so what do I know).
No one is really obligated to do anything except what they get paid for, so you need some kind of motivation. This motivation is not easy to come by if you don't have a specific goal. I don't think Nim has a specific goal (so it's "general purpose"), and I'm perfectly fine with this. There are some very good things that Nim has that no other languages have; it's already bad that other languages don't have those features, it would be even worse if they were locked behind whatever specific niche Nim would fulfill.
In that sense sometimes I find myself preferring a slightly buggy or hacky language that does cool things (or things that seem cool) rather than be bogged down by a lame but supposedly robust language. My other options are usually languages like Java and Python which are both lame and unreliable. It's just a compromise you have to live with. If great products existed, that would be great, but it's not really easy to make them great and it's not like anyone's life is at stake on it. For the time being, it's good enough, if not who can you hold responsible lol.
It seems to me that many features are implemented without a proper spec or considering edge cases
This is very true in my view, many issues where "X should work but does not" is simply someone forgetting some obscure AST can exist since many steps require you to think deeply about "what AST could exist here". For instance type A[T] = distinct seq[T] does not work in borrows since there is no mechanism to realize "Hey A[T] is a generic distinct". Or how iterable has been implemented, cannot use iterable in inline iterators even though they're just fancy templates which means we lack any composition.
I also feel like bugs aren't prioritized enough
This is also true in my view, in September I got bored and looked at a bunch of low hanging fruits and fixed quite a few bugs that existed from a year to a few years, in relatively short time. (Which sadly I now realize what I should've done when fixing those bugs was record myself doing it and commentate what/why I was doing and publish those videos to have some educational content on how to work with the compiler on fixing small bugs.)
With those comments aside, I think there needs to be more open conversations and documentation about the compiler and how to work with it to encourage people that are scared of the compiler to pick it up. It may seem like a complex beast, but if I'm capable of fixing bugs anyone is. The biggest blocker to entry is that the compiler is mostly devoid of comments so you have to do research yourself for "Why is X done this way" or "What does this do". Which means only people with an abundance of time or effort will really be able to contribute.
I've never had a problem with Nim that was the compiler's fault. It was typically lack of documentation or examples. But people on the forum are helpful and I always found a way forward.
Now I plan to deploy a system (Production) by around March 2022. Similarly to sdmcallister, Nim is the least of my problems. In fact, Nim has saved me many hours compared to if I had used C/C++.
The compiler being hard to understand would not necessarily be fixed by documenting it. It just isn't always written in some mathematically perfect way. Ideally you would make things more straightforward over time but realistically only the original author can do that if it's so eldritch. The "if it works it works" attitude is not necessarily bad, but not following up is.
However I understand things like iterable being half features because every feature around them (iterators, template arguments, weird typeclasses, ...) are indicated to seem like they need or will get a significant overhaul, usually by community consensus (many RFCs and issues). I don't use distinct borrows, iterators that aren't extremely trivial, and some other features with the knowledge that they are broken or unfinished, and I don't exactly find myself thinking "god I wish those features worked so I could use them" even when it would make things much easier for me. But it is possible if they were superceded by an actually well designed feature that I would enjoy using it then. So the problem here is not with the compiler development itself IMO.
In every case, communication is hard. It's very common to see good ideas get obliterated because of insufficient communication, no matter how hard everyone tries. I don't really have a good conclusion here and I don't mean to sound patronizing or anything (I don't know shit) but sometimes these overly abstract discussions keep going too long and culminate in nothing.
Disclaimer: Note that I don't want to attack anyone, this is just my personal opinion.
Unfortunately, I have also had some experiences with bugs in nim-lang. I am a beginner and have therefore only worked on the surface with nim. I would not expect to find any bugs at this level. But unfortunately there are. One bug is already reported and confirmed. This is ONLY in connection with "choosenim". But it is still annoying. Another bug I found is related to a selfmade test suite. A very simple code (no File-I/O, no GUI) runs under Linux without problems and under Windows the program crashes. When I have isolated the bug better I will report.
If you have to make such experiences with a language as a beginner it is very frustrating. It simply demotivates. You first search like crazy because you assume that the error is with you only to find that it is not so.
I read "Efficient, expressive, elegant" on the main page. That sounded so confidence-inspiring and inviting. At the moment I am annoyed.
I continue to believe in nim-lang. The language is special, but criticism must be.
I would be happy if more emphasis is put on testing, quality and better documentation.
What would be the following attitude? We only add new features when we think nim.lang is really bug-free and the documentation is rated "premium" by all users.
For god's sake? Yes, then there will be no new features for 2 years... so what?!
What do you think why there is so much junk software out there? It's all a question of inner attitude.
Sorry, but I had to let off some steam.
in my opinion it would be better to first fix the bug and then worry about how to optimize this
.. uses 2 features that have basically no purpose but pandering to humans, one being for syntax for iterators, the other being using a special infix operator. This implies there could be some compromise to its behavior for how convenient it is. People won't expect more compromise for things like correctness on top of this. It's not too bad for it to be optimized while something like countup which is more comprehensive could benefit from resilience.
Going to ramble a bit. I honestly do not really care to defend these things. As cheesy as it sounds things like the standard library, GC, syntax etc will never be perfect tools for each user, no matter the language. People either write things themselves or they choose something that has written things how they would write it. There is no end to this debate, the best thing you can do is make your product flexible, but you should still not go too crazy.
Nim has a theoretically strong foundation that you can specialize for your own needs. It's when this foundation breaks that's the problem. If macros have a bug that requires a simple, obvious workaround, it's not really a big deal, it would be cool if you didn't have to deal with it though. If the compiler segfaults for random reasons whenever you write a slightly complex macro yeah you're going to want to stop using the language, or at least just macros.
Dealing with issues like this can be hindered by either no one solving them yet, or by some superficial human factor that stops solutions from being adopted. The latter part is honestly not the problem of 90% of us
Nim has a theoretically strong foundation
And the theoretically strong foundation is.... what?
TL;DR Distributing Nim with a rich standard library or with a bundle of "core" libraries is important for many use cases.
In some organizations the same team writes software, selects 3rd party dependencies, builds, deploys and runs it. Despite the popularity of continuous deployment, the majority of software in the world is not written / packaged / build / maintained within the same organization.
When it comes to smaller organizations or individuals, having a battery-included Nim can help:
A lot of software runs for 5+ years after the last release and might need small fixes after the upstream development has stopped. (There are also extreme cases: the CIP project aims to ship a small Linux distribution and backport security fixes for 25 years to support critical infrastructure like power plants)
Personally, I like to know that if I build something against the compiler shipped in Debian I'll be able to easily backport a fix and rebuild it for 5+ years.
No one is really obligated to do anything except what they get paid for, so you need some kind of motivation.
This motivation is not easy to come by if you don't have a specific goal.
I don't think Nim has a specific goal (so it's "general purpose"), and I'm perfectly fine with this.
There are some very good things that Nim has that no other languages have; it's already bad that other languages don't have those features, it would be even worse if they were locked behind whatever specific niche Nim would fulfill.
In that sense sometimes I find myself preferring a slightly buggy or hacky language that does cool things (or things that seem cool) rather than be bogged down by a lame but supposedly robust language.
My other options are usually languages like Java and Python which are both lame and unreliable.
It's just a compromise you have to live with.
If great products existed, that would be great, but it's not really easy to make them great and it's not like anyone's life is at stake on it.
For the time being, it's good enough, if not who can you hold responsible lol.
We have been using Nim since 0.18.0 and the bugs we have ran into is minimal compared to the development speed. Some fixes were needed when upgrading Nim versions but all were manageable.
We are very happy for the scope of the standard library - and without it we wouldn't have chosen Nim. We do use Nimble packages, but we keep a local copy of each of the used packages in case the repo owner decides to take down the repo.
I basically agree with the sentiment- my impression is, as well, that there is a bit of cavalier attitude in the Nim community with regards to getting the little things right. Now no one is saying this directly but it appears to me that there seems to be the assumption that because Nim is doing some really advanced stuff, it is okay to underperform in the more mundane plumbing aspects of the language.
In a way this is perfectly understandable- if Nim wasn't, conceptually, the language to rule them all, I wouldn't be using it. I do want to be able to write a macro if I need to (although I never really needed to so far for my needs). And if you want to keep up development speed of advanced features, it's perfectly natural to just get ahead with things already and not worry too much about things like code readability.
But, the price of all that is that Nim can be frustrating for new programmers. Not conceptually at all, but simply because of those little things. Why are there two regex modules in the standard library? That's just sloppy. One of those needs to be deprecated now and killed in Nim 2.0. I did raise that issue a bit but I got a lot of foot-dragging. Again, that's perfectly understandable- the authors are busy doing some really advanced stuff and are loath to get distracted out of that by something as mundane as a bit of regex confusion. And yet, here we are, writing code in the language to rule them all that can't decide on a regex API feeling a little flaky.
I'm not exactly sure what do do about this. But I do have an approach here that might help. Such things as we are talking about, fixing little bugs and finding obscure crashes, that is simply a matter of throwing bodies at the problem. It's just "Schlep" work, unrewarding in itself, endless, yet vitally important. How you get more people like us to do that work is pretty much part of the chicken egg problem of a language. I try to do a little bit, e.g. I fixed a silly regex split bug that shouldn't have been there. But there simply needs to be more people doing that and the problem will go away. I kind of get why the lead devs aren't doing it- they are forced to get the advanced design right in order to sell people like us on the language so we will be motivated to fix bugs.
So perhaps the real problem is that Nim underestimates the power of marketing. I read somewhere that Andreas is counting on people recognizing the quality of the computer science in Nim and using it. Now it worked for me, but I know of a lot of "kids" I know (and I don't mean kids by age, I consider people "kids" in information technology if they are prone to buying into the groupthink of "hip" technology). So the question here is how to reach the kids, and we get those with marketing... or even worse, hard sales. If you look around what Rust is doing in terms of marketing, these guys are better at it than Jehova's witnesses. You post something about some library you did and you have ten guys trying to get you to re-write it in Rust. Now, perhaps there is a more pleasant variant of that, but I believe that what the Rust folks do get that good Marketing is mark of quality that is inherent to the software, because it attracts more people who will use the language and fix bugs. In Nim, the awareness of the importance of marketing, and the knowledge how to do it will, seems to exist but is most certainly an afterthought. Another great example here is git vs mercurial- I read once that with mercurial, users were just happily using the thing, but with git, they were posting on forums and shouting from rooftops and actively badgering projects to switch. We need this.
Another aspect of marketing is the approachability of the code base, so this is where the mentioned lack of documentation and added focus on code readability come in. And the third aspect that would probably help would be some kind of top-down messaging like organizing bug-spotting and bug-fixing drives and so on.
Now, that's as far as my thoughts have come on the subject, but like many I'm probably still sitting around a bit unsure what they greatest place would be to start. Because I do really love Nim and I don't think it would need much improvement in order to truly fulfill its promise of being the Language To Rule Them All.
"One language to rule them all" is pretty unrealistic. I did a talk on where I think Nim specifically would shine (https://youtu.be/d2VRuZo2pdA).
I echo OP's experience with bugs or at least surprising behavior and unfortunate limitations in type inference that make, eg. Option difficult to work with. For these reasons I stick with a conservative of subset of Nim.
Regarding a more approachable compiler, better testing and less rough edges around language features: there is the recent NimSkull project (basically a hard-fork of Nim), which - among other things - aims for these things.
In the future, maybe some of their efforts can be integrated back into Nim?
PS: I hope it's okay to mention NimSkull here on the forum? As far as I can tell, it hasn't been mentioned here yet. A cursory search also yielded no results on what the official stance on that project is