When reading the various posts comparing languages (including Nim) the conclusion many times says something like "Nim is everything you want in a language but ...". If it is highly regarded what's stopping it from gaining that critical mass required to be considered mainstream?
(A small digression here as I work for a small company (3-4 developers) using Java as the main dev language. The programming itself is fine but I'm seeing our cloud hosting costs climb as containerising Java ends up using a insignificant amount of server resources. I would like to prototype moving some of these Java systems to Nim microservices. However, there's no point doing that if I can't persuade my fellow developers that using Nim is a good move.)
So, a couple of points I think are stopping Nim from making the jump:
How to fix it?
If nimedit was dusted off and further developed could it become the go-to IDE for Nim, possibly itegrating GDB under the hood?
Really keen to hear other's thoughts. If you have a team of devs doing Nim development it would be great to hear details on your dev environment.
Disagree with the IDE comment. Most people use the editor/IDE of their choice. I'm not going to switch editor/IDE just for a new-to-me language. Any killer feature one editor/IDE has is usually replicated to other editor/IDEs in a matter of months.
I would enjoy seeing a debugger because I work in the embedded space. But I don't think that's a significant blocker to nim adoption. I feel that nim is quite a bit like Python (it fits my brain) and I rarely need to use a debugger with Python (exceptions during development are usually sufficient).
I think the #1 thing that nim faces is the combo of legacy languages and a handful of solid competitor "modern" languages. With such solid alternatives, it is difficult to achieve the momentum needed to get a plurality to join the bandwagon.
As far as I understand, the problem is not IDE, the problem is that it's very hard to create Nim "language server" (type checks, autocomplete etc.), and there's probably no way to make it work well until the Incremental Compilation is done.
As soon as you have "language server", the IDE part will be solved easily, just integrate it in any IDE, VSCode, Intellij IDEA, etc.
The main issue with this sort of question, imo, is they are based on the assumption that fixing some specific technical problem will make people use this particular language. Work on moving their codebase, learning new technology, tooling, quirks and pitfalls.
You need to know who you are selling the language to and what their needs are. Why should I care about the language for example. I'm happy in using my own solution X -- and so does the majority of the developers who use mainstream languages.
What problem does it solve for me, specifically? Most people are not out in the wild for some quest for enlightenment and better languages, they are looking to solve their problems.
And note, features of the language do not become problem solutions unless explained how they can actually be applied. Said explanations must also include suggestions on how to solve the new problems that come up when i transition to nim.
Pure features themselves are secondary here, because you need to know them well enough to be able to apply and come up with new problem solutions. It is the case of transitioning quantity into quality -- enable completely new ways to solve the problem. But this must come after identifying and advertising problems that can be solved directly.
Languages go mainstream because they can solve many problems for many people. Incrementally solving some problems a bit better is not good enough to squeeze into the mainstream, you need to solve completely new problems, ones that competition does not have. And don't introduce too many problems on your own.
The order of questions must be: What's in it for me? Why should I bother so much (where how 'much' newcomer is bothered defined by availability of documentation, tooling, libraries)?
Features are nice, but you need to orient people to something first, otherwise it is just throwing someone into a sea of possible solutions.
I also noticed that for the last two years nim stopped doing community survey. 2022 is missing, 2023 is also missing. Surveys can be useful to find what problems are actually being solved by nim. We know some stories, but they are mostly "can X be done in nim", not "how introducing nim helped to solve problem Y"
And I'm omitting billions of dollars of funding that goes into mainstream languages.
If there is one language that could effectively (and efficiently) replace JavaScript is Nim.
I know, a hot take.
Yet, think about it.
Nim officially had the motto of being the "one language to rule them all" (though @Araq later rephrased it into: "good for everything language"). Isn't that what JavaScript folks are trying to push (except, it is not fit for low-level systems programming)? And obviously, Nim is the better designed language and the one that spits out high performance code.
However, JavaScript is specified by TC39 which has a huge backing of all the major big-tech companies.
So, that results in much better documentation, marketing, and support. That makes it hugely popular.
I think the only way to make Nim go mainstream now is to give it to a foundation or some corporate body that has huge monetary backing.
However, I don't think @Araq and the others are not interested in that. I personally don't think it's a bad thing. I don't trust any of the major tech companies. Yet, I think that's the only way to make it "mainstream".
Getting to the top programming languages is somewhat random and often more an accident of history than a result of merit. That's why merely fixing a feature or any other single action will not suffice. Nim needs luck... and a killer library!
Most languages reached the top not on merit:
It's quite challenging for a language to gain popularity based solely on merit. It's much easier to become necessary for a platform or to be backed by a large company. Python and Ruby got there through a combination of luck, merit, and community, which is very rare. This approach seems to be the only realistic way for Nim to rise to the top. Nim needs to emulate the strategies of Python and Ruby and also have good fortune with several killer libraries.
What is Nim's lucky library?
Its fun, interesting, teaches you a ton of concepts and ideas you can make use of in most other languages or are generally useful to know and the ecosystem feels much more friendly to contributions than I got the feeling anywhere else (which is in part caused by the lack of libs in places).
It's not a coincidence that it was Nim that finally got me to write my first Open Source library rather than just an application for myself.
@giaco
I get a system programming language, a web programming language, a kinda scripting language, all in one package. It's not the best in any of these fields... (emphasis mine)
I think this is the significant appeal of Python, other than ease of use. It does many things reasonably well in an easy to use package, batteries included.
Sure it's definitely not the best at everything it does, but the point is that it can do it well enough to solve a significant majority of problems thrown at it. For specialist stuff, like high-performance real-time systems, etc., then that's where more suitable, and more difficult languages apply.
Nim could fill that niche: improving on what Python has solved for the programmer, sans the difficulty of raw C/C++ or Rust.
not sure if this forum has a "close" or "resolved" function, but this question should be marked as "resolved".
I just tested the line-by-line feature: https://marketplace.visualstudio.com/items?itemName=NimLang.nimlang
Python was a niche language for decades before it went mainstream.
Every language had an angle- web dev for ruby, science for Python.
Indy games seem to be a bit of an angle for Nim.
Cross device dev is also a growing one- write once, run natively on ios/android/osx/linux/windows. It depends on opengl as of now though, fine for games but a bit resource hungry for apps, and limited in os interaction (share, clipboard, menus) and too much friction to get started to be a nobrainer choice.
uing is an amazing development, although it's limited in capability.
A uing for native mobile apps would be really, really cool.
"rapid development everywhere" is the best I've come up with to explain why Nim is so good in a nutshell.