Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!):
* Gamedev: Also used in production: https://github.com/pragmagic/godot-nim and due to easy C and C++ interop, you get access to a lot of gamedev libraries!
> who needs interpretation when compile times are that fast!
Well, interpretation is pretty useful for a REPL. And a REPL is not just useful to avoid compilation, but also as a way to explore a new API. And, most importantly, to preserve the results of long computations when you do not know yet what to do with it. If computing a value takes half an hour, you certainly don't want to recompute it each time you change something. Rather, you keep an open session, such as a REPL or a notebook, and keep computing with the already existing value
This is one of the aspects that self professed R/Python datascience contenders often get wrong. The very bare minimum is a well supported and thought out dataframe library. Without that, the language is basically dead in the water. Nim seems to have a very well thought out API that also avoids many of the annoying aspects of Pandas (e.g. the huge waste coming from eagerly computing each vectorized operation into separate arrays).
Most of my work is time series analysis and I refuse to use an environment where samples are not explicitly labelled/timestamped and where the tooling does not support seamless operations that take this labeling into account.
So for my use case, a fully featured dataframe library is indeed a must.
See my comment from the other reply on this question for potential solutions, but as an fyi for those curious, Nim does come with a VIM that comes in very handy for such purposes: https://nim-lang.org/docs/nims.html
Had a project once where 70% or so of the 8 month runtime was de/serialization. 800gb or so data wad and 16gb of ram; all messily multiply interlinked and not even the indexes would fit into ram. it sucked.
but the architecture that imposed meat we were surprisingly resilient to power outages.
I looked at the emitted JS when the last Nim story came out. It needs some work there. Lots of globals with names that would likely collide with other existing JS.
Yeah, we definitely need to resolve this and it sounds like a fun project! If you or someone else has the time for this I (and I'm sure the rest of the community too) would love to help lead you in the right direction :)
I haven’t used nim outside of some hello world toying a few years back. Is compiling actually that fast? I thought the nim compiler compiled to C and then called gcc (or whatever system compiler), isn’t that slow in practice?
Any large nim projects that anyone can point me to would be helpful too, I’ll give the compiler a shot later today!
* Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell
* Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library.
* Backend: For something Flask-like: https://github.com/dom96/jester or something with more defaults https://github.com/planety/prologue
* Scientific computing: the wonderful SciNim https://github.com/SciNim
* Blockchain: Status has some of the biggest Nim codebases currently in production https://github.com/status-im?q=&type=&language=nim&sort=
* Gamedev: Also used in production: https://github.com/pragmagic/godot-nim and due to easy C and C++ interop, you get access to a lot of gamedev libraries!
* Embedded: this is a domain I know very little about but for example https://github.com/elcritch/nesper or https://github.com/PMunch/badger for fun Nim+embedded stuff!
Most of the disadvantages come from tooling and lack of $$$ support.