Actually, that’s not far from the truth. The reasons are:
Lack of contribution. If someone isn’t doing actual programming work, doesn’t have time management to maintain libraries, or isn’t contributing successful applications, it’s hard to take constant criticism seriously.
Only showing up to complain. Some people disappear for months and then reappear only to complain about design decisions, like "Why were multimethods removed in v3?" or "Why isn’t the pragma syntax like Python’s?" That tends to lead to the assumption that the language is "someone’s toy" just because features change or it’s not a drop-in Python replacement.
Focusing on gossip instead of technical merit. Complaining that a moderator was unfriendly is missing the point. Moderators change over time. The question should be whether the language and the ecosystem are valuable to you, not whether you personally get along with every individual on the forum.
That's total BS btw, I've been part of the Nim community for over 7 years now and never had an bad interactions with the project's lead. But I did witness behavior from certain individuals that was out of line. Some of them went on to blame Araq in other places, I have read their criticism, which I found very hypocritical. You should take their views less seriously.
And it works pretty well, coming from 6+ years of experience. It's not that strange if consider case insensitive filesystems and email addresses. But on the internet you only hear the opinion of the loudest minority.
I will add that as a library, it has a big potential to be used in resource restricted envs, such as microcontrollers. Every other JSON library under the sun uses HashMaps or Btrees to structure the tree which end up wasting space. Another interesting one called Araq/packedjson whose ideas I borrowed, might be the most space efficient design so far, however it looses on speed comparisons on operations that involve removing items. That's because some structure should be maintained and this library provides the best trade-off between complexity and space efficiency.
Nim has also a powerful deep learning library called Arraymancer. It's selling point is that you don't have to rewrite your code from research to production. It's used in various machine learning projects, but one recent one that caught my eye was https://github.com/amkrajewski/nimCSO "Composition Space Optimization"
It seems to overlook that the language model was developed using a large corpora of code, which probably includes structured fuzzers for file formats such as GIF. Plus, the scope of the "unknown" format introduced is limited.
Actually the Nim wrapper use none of the above, instead compiles and links the static library per project, recompiling only when the C source files has changed. Allows for the best flexibility if you are using nim.