8 ms·

> Why use Nim? > One language to rule them all: from shell scripting to web frontend and backend, scientific computing, deep learning, blockchain client, gamede

> Why use Nim? > One language to rule them all: from shell scripting to web frontend and backend, scientific computing, deep learning, blockchain client, gamedev, embedded, see also some companies using Nim. Does that work in practice? I can't really imagine a single language that would be a good choice for "everything".

sp33der89 5y ago
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!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For something Flask-like: https://github.com/dom96/jester https://github.com/dom96/jester or something with more defaults https://github.com/planety/prologue https://github.com/planety/prologue * Scientific computing: the wonderful SciNim https://github.com/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= https://github.com/status-im?q=&type=&language=nim&sort= * Gamedev: Also used in production: https://github.com/pragmagic/godot-nim 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 https://github.com/elcritch/nesper or https://github.com/PMunch/badger https://github.com/PMunch/badger for fun Nim+embedded stuff! Most of the disadvantages come from tooling and lack of $$$ support.
- tyingq 5y ago
  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.
  - dom96 5y ago
    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 :)
- rgrmrts 5y ago
  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!
  - kevin_thibedeau 5y ago
    When using Nim for "scripting" it is recommended to use TCC for rapid compilation. It is genuinely fast.
  - sp33der89 5y ago
    The proof is in the link! > Fast compile times: a full compiler rebuild takes ~12s (Rust: 15min, gcc: 30min+, clang: 1hr+, Go: 90s) [2]. The compiler is really big and self-hosted too. For large nim projects check out: https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer or https://github.com/treeform/pixie https://github.com/treeform/pixie (personal faves).
    - rgrmrts 5y ago
      Thanks for the links, I’ll check those out.
- pathsjs 5y ago
  > 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
  - short_sells_poo 5y ago
    This is exactly right. What is the REPL story with NIM? Having used a REPL, I cannot even imagine doing research & analytics without one. FWIW, this comparison between R, Pandas and Nim dataframes is quite encouraging: https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d204f84 https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d20... 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).
    - sp33der89 5y ago
      My statement was mostly an exaggeration, than an absolute truth. REPLs are really nice, but it's story with Nim is less nice. There is: https://github.com/inim-repl/INim https://github.com/inim-repl/INim and the builtin `nim secret`. There is also a Jupyter kernel: https://github.com/stisa/jupyternim https://github.com/stisa/jupyternim
    - pietroppeter 5y ago
      I did quench (most of) my thirst for a Repl building a notebook system (plug): https://github.com/pietroppeter/nimib https://github.com/pietroppeter/nimib Based on that and using a book theme, scinim getting started documentation is being built, e.g.: https://scinim.github.io/getting-started/basics/data_wrangling.html https://scinim.github.io/getting-started/basics/data_wrangli...
- DennisP 5y ago
  Also one of Ethereum's proof-of-stake clients is written in Nim: https://nimbus.team/docs/index.html https://nimbus.team/docs/index.html
  - michaelsbradley 5y ago
    Direct link: https://github.com/status-im/nimbus-eth2 https://github.com/status-im/nimbus-eth2
- enthus1ast 5y ago
  * Backend: For something Jinja/Twig-like: https://github.com/enthus1ast/nimja https://github.com/enthus1ast/nimja
kettunen 5y ago
Yeah, these kind of statements feel very “empty” to me. That’s probably true that you could do everything with Nim, it’s also true that you can do everything with every language. Should you? That is another question.
- GavinMcG 5y ago
  You say "empty", but each of the listed uses links to a project as evidence, and the claim is followed up with specific evidence about small binaries, fast compile times, native performance, multiplatform targeting, etc. Given all that, what are you still looking for to make the statement non-empty?
- xet7 5y ago
  Unfortunately, it's not possible to do everything with every programming language. If thinking of rewrite of some software, it depends does all dependencies, database drivers, authentication, etc exist for some other programming language.
  - arc776 5y ago
    Being able to compile to C, C++, ObjC, and JavaScript natively (and LLVM using https://github.com/arnetheduck/nlvm https://github.com/arnetheduck/nlvm ), along with an excellent FFI (including to and from Python) means you don't need to rewrite dependencies as you can use them directly. Nim is great at glue code - arguably better/easier than Python. Along with general language characteristics such as being high level and productive like Python, but with intricate "bare metal" control when you want it, really does make it suitable for writing almost everything.
- xigoi 5y ago
  Can you show me how to write a frontend web app with C? Or how to make a keyboard driver with Python?
haxscramper 5y ago
Adjacent comment already has a list of concrete libraries/frameworks for large number of areas, so I just want to mention that nim has a very good metaprogramming capabilities, and if the /language/ itself does not feel up to the task you have a lot more freedom when it comes to implementing things. So it really comes down to the community size and amount of money poured in the development, and not fundamental problems with the language design. This is mostly an argument about "technically you can write anything with anything", except in nim's case it is also backed by extremely high flexibility. EDIT: by flexibility I mean - different backends they covet very huge ecosystems (Js and C, and by extension anything they you can interface with using C (like python)) - already mentioned metaprogramming - support for low-level convenience features like custom operators - different memory management options. If you want you can turn off automatic mm completely and write code that deals with pointers and stuff like that directly - more niche things like support for embedding nim interpreter in your programs https://peterme.net/using-nimscript-as-a-configuration-language-embedding-nimscript-pt-1.html https://peterme.net/using-nimscript-as-a-configuration-langu...
- sp33der89 5y ago
  Yes, this is something I should have mentioned as well, Nim does a lot of things just right and adds all the right things so it stays out of your way, is not too verbose but still has enough safety guards where you can just do what you want to do.
benob 5y ago
C interop is very easy, so you can do embedded dev by disabling memory management and standard lib, and staying very close to the generated C code. Or you can do high level stuff thanks to well though generics and meta programming. The js backend is not mature enough to cover high performance web apps. It is more like a gimmick currently. Maybe a wasm layer could be as successful as rust's...
- auxym 5y ago
  > Or you can do high level stuff thanks to well though generics and meta programming. Metaprogramming is also surprisingly useful for low-level, embedded programming. Eg, using compile-time logic (branching, looping) to decide which bit in which register you want to twiddle, instead of doing it at runtime, which saves computation and (sometimes) code size.
sph 5y ago
> I can't really imagine a single language that would be a good choice for "everything". Full stack Javascript enthusiasts are nowhere to be seen in this thread, but are writing their backend, frontend, desktop and mobile JS, WASM, Ethereum backend and the next ARM instruction set to speed up JS code natively, silently working towards total world domination. The nanomachines that will bring forth the end of the world will be running Node.js. But I agree with you.
- rattray 5y ago
  JS is also great for scripting, but really isn't popular for ML or data science (no pandas/numpy/scipy equivalents I think, other than tensorflow.js). I'm curious how Nim fares for DS/ML.
  - chubot 5y ago
    JS is also not fast enough at string manipulation to express its own dev tools, at least if you want to build in seconds and not minutes. The latest incarnation of JS tools seem to be written in Go and Rust (esbuild and another one), not JS. GC is an issue for compilers, or even just front ends, which create huge, fine-grained, linked data structures
    - rattray 5y ago
      Sure, JS isn't ideal for compilers, but it is quite good - typescript is a better and more performant compiler than many languages have, as just one example. You wouldn't be crazy for choosing JS for a new compiler project, even for work that had nothing to do with JavaScript. (You would be pretty crazy to choose js to build a rich data science backend, in comparison). I do agree the GC rules out some use-cases like many gaming applications.
      - 1_player 5y ago
        Please don't write a compiler, that has nothing to do with JavaScript, in JavaScript. It needs correctness, safety and speed, none of which are JS (nor TS) strengths. You can, but that's a prerogative of all Turing-complete languages. There are much better languages fit for the purpose, which is the point of this comment thread.
Zababa 5y ago
I think Nim is in the sweet spot for it. You start with basically OCaml, which is already a great start, add some knobs for tweaking memory management, some for high performance, and you're in a great places. Compiling to native and to JS allows you to do web, cli tooling, applications, high level gamedev. Fast compilation is important for scripting, high level gamedev, exploratory programming, scripting. High performance allows you to do low level gamedev, deep learning, stuff like that. Being bootstapable from C and compiling to it with the memory management tweaks opens you the world of embedded. There's also the fact that not all language are perfect. If they all are, the general language would always lose to the specific in every niche, so you need to do different things for the general to be worth. But languages aren't perfect, and you could prefer the general language even in niches.
- haxscramper 5y ago
  I can't remember exact place where I've seen this discussion (I think it was on the nim IRC), but if I recall correctly, the original line of thought with nim was to take C (because fast/compiled/available-everywhere) and LISP (because flexible/extensible/good-ideas) and add more syntax sugar, so that user would not have to reimplement most of the syntax from scratch (using reader macros/special functions and so on). There are of course a lot of other languages that influenced the syntax and semantics (like Ada, python, C++ and so on), and I omitted a huge number of extra considerations.
  - dom96 5y ago
    Indeed, in fact the original line of thought was[1]: > [combining] Lisp's power with Python's readability and C's performance. I'd say Nim still satisfies this very well. 1 - https://web.archive.org/web/20110704041631/http://force7.de/nimrod/ https://web.archive.org/web/20110704041631/http://force7.de/...
    - Zababa 5y ago
      Interesting, I think Julia was close to that too: > We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled. https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/
mst 5y ago
It's not necessarily the best choice for everything for any given team, but in the same way you'll see e.g. shops that have bought in heavily to using go by default using go for writing scripty tools as well as their main applications, using nim as 'the default language unless there's a use case specific reason to use something else' is surprisingly doable.
coliveira 5y ago
This is not a new concept, decades ago computer scientists started working on general purpose languages, that were supposed to be good for (almost) everything. The idea that a language has to serve a niche is a modern construction.
benttoothpaste 5y ago
I heard PL/I was the original language for “everything”. It’s not a new concept :)
mumblemumble 5y ago
The probable gaps I see are embedded and certain branches of gamedev, and shell scripting. Regardless of what Nim says in its sales pitch, it is a garbage collected language, and garbage collection is not really optional. The closest options are nothing, automatic reference counting (ARC), and automatic reference counting with cycle deletion (Nim calls this one ORC). Nothing at all might be fine for cloud lambda functions and command line utilities, but it generally isn't acceptable for long-running processes such as video games and firmware. ARC will still leak memory when there are cycles, so it can work if you are very careful about how you manage data. But it's trickier than what you get out of modern C++, and more resource-hungry than full manual memory management, so I can't really see this option being ideal for gamedev or embedded. And ORC is basically just Python's garbage collection algorithm, with all its strengths and weaknesses. For shell scripting, at the end of the day, it is still a statically typed, compiled language. This just doesn't hit the sweet spot for a scripting language. In that context, the performance of the language itself doesn't really matter, the entire operating context is irredeemably weakly typed, and nothing you do will ever grow large enough for static types to help much with maintainability. I'd much rather have the fast edit-test cycles of an interpreted dynamic language. That said, what I have successfully used Nim for is writing command-line tools that I interact with from shell scripts. But there, it's not replacing sh or perl or python, it's replacing C.
- PMunch 5y ago
  Nim works super well for embedded. The thing is that you can turn off the garbage collector and do manual memory allocation if you want to. Or simply use ARC which works a treat on embedded. I wrote my own keyboard firmware in Nim (and did a presentation of it during NimConf 2021: https://www.youtube.com/watch?v=dcHEhO4J29U https://www.youtube.com/watch?v=dcHEhO4J29U). It runs super fast and the code size is smaller than some simple "Hello world" level programs using the Arduino system. As for gamedev the ability to tune the GC by turning off automatic collection and then running it with a time-limit is perfect for preventing lag-spikes when a lot of stuff is going on (looking at you Java..). Nim actually performs very well, and the garbage collector does a great job of just getting out of the way and letting your programs fly. Your point about shell-scripting is kind of valid, it is indeed a weakly typed world. But with how fast Nim compiles the edit-test cycle feels as fast as Python, and you save a lot of time from having a silly typo that you only encounter after having run your script for a little while. The reason why Nim is good for pretty much anything is that the speed of the compiler and the garbage collection will rarely if ever stand in your way, and the flexibility of the syntax that stems from meta-programming allows it to be molded perfectly to the use-case.
systemvoltage 5y ago
Comparing with Julia, which claims to be a do-all fit-all language, I'd take Nim any day. I've used Julia in production for many years and it is an absolute nightmare to maintain. Nim seems to be what python should have been from the beginning. It is a breath of fresh air.

sp33der89 5y ago

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!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For something Flask-like: https://github.com/dom96/jester https://github.com/dom96/jester or something with more defaults https://github.com/planety/prologue https://github.com/planety/prologue * Scientific computing: the wonderful SciNim https://github.com/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= https://github.com/status-im?q=&type=&language=nim&sort= * Gamedev: Also used in production: https://github.com/pragmagic/godot-nim 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 https://github.com/elcritch/nesper or https://github.com/PMunch/badger https://github.com/PMunch/badger for fun Nim+embedded stuff! Most of the disadvantages come from tooling and lack of $$$ support.

tyingq 5y ago
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.
- dom96 5y ago
  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 :)
rgrmrts 5y ago
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!
- kevin_thibedeau 5y ago
  When using Nim for "scripting" it is recommended to use TCC for rapid compilation. It is genuinely fast.
- sp33der89 5y ago
  The proof is in the link! > Fast compile times: a full compiler rebuild takes ~12s (Rust: 15min, gcc: 30min+, clang: 1hr+, Go: 90s) [2]. The compiler is really big and self-hosted too. For large nim projects check out: https://github.com/mratsim/Arraymancer https://github.com/mratsim/Arraymancer or https://github.com/treeform/pixie https://github.com/treeform/pixie (personal faves).
  - rgrmrts 5y ago
    Thanks for the links, I’ll check those out.
pathsjs 5y ago
> 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
- short_sells_poo 5y ago
  This is exactly right. What is the REPL story with NIM? Having used a REPL, I cannot even imagine doing research & analytics without one. FWIW, this comparison between R, Pandas and Nim dataframes is quite encouraging: https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d204f84 https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d20... 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).
  - sp33der89 5y ago
    My statement was mostly an exaggeration, than an absolute truth. REPLs are really nice, but it's story with Nim is less nice. There is: https://github.com/inim-repl/INim https://github.com/inim-repl/INim and the builtin `nim secret`. There is also a Jupyter kernel: https://github.com/stisa/jupyternim https://github.com/stisa/jupyternim
  - pietroppeter 5y ago
    I did quench (most of) my thirst for a Repl building a notebook system (plug): https://github.com/pietroppeter/nimib https://github.com/pietroppeter/nimib Based on that and using a book theme, scinim getting started documentation is being built, e.g.: https://scinim.github.io/getting-started/basics/data_wrangling.html https://scinim.github.io/getting-started/basics/data_wrangli...
DennisP 5y ago
Also one of Ethereum's proof-of-stake clients is written in Nim: https://nimbus.team/docs/index.html https://nimbus.team/docs/index.html
- michaelsbradley 5y ago
  Direct link: https://github.com/status-im/nimbus-eth2 https://github.com/status-im/nimbus-eth2
enthus1ast 5y ago
* Backend: For something Jinja/Twig-like: https://github.com/enthus1ast/nimja https://github.com/enthus1ast/nimja

kettunen 5y ago

Yeah, these kind of statements feel very “empty” to me. That’s probably true that you could do everything with Nim, it’s also true that you can do everything with every language. Should you? That is another question.

GavinMcG 5y ago
You say "empty", but each of the listed uses links to a project as evidence, and the claim is followed up with specific evidence about small binaries, fast compile times, native performance, multiplatform targeting, etc. Given all that, what are you still looking for to make the statement non-empty?
xet7 5y ago
Unfortunately, it's not possible to do everything with every programming language. If thinking of rewrite of some software, it depends does all dependencies, database drivers, authentication, etc exist for some other programming language.
- arc776 5y ago
  Being able to compile to C, C++, ObjC, and JavaScript natively (and LLVM using https://github.com/arnetheduck/nlvm https://github.com/arnetheduck/nlvm ), along with an excellent FFI (including to and from Python) means you don't need to rewrite dependencies as you can use them directly. Nim is great at glue code - arguably better/easier than Python. Along with general language characteristics such as being high level and productive like Python, but with intricate "bare metal" control when you want it, really does make it suitable for writing almost everything.
xigoi 5y ago
Can you show me how to write a frontend web app with C? Or how to make a keyboard driver with Python?

haxscramper 5y ago

Adjacent comment already has a list of concrete libraries/frameworks for large number of areas, so I just want to mention that nim has a very good metaprogramming capabilities, and if the /language/ itself does not feel up to the task you have a lot more freedom when it comes to implementing things. So it really comes down to the community size and amount of money poured in the development, and not fundamental problems with the language design. This is mostly an argument about "technically you can write anything with anything", except in nim's case it is also backed by extremely high flexibility. EDIT: by flexibility I mean - different backends they covet very huge ecosystems (Js and C, and by extension anything they you can interface with using C (like python)) - already mentioned metaprogramming - support for low-level convenience features like custom operators - different memory management options. If you want you can turn off automatic mm completely and write code that deals with pointers and stuff like that directly - more niche things like support for embedding nim interpreter in your programs https://peterme.net/using-nimscript-as-a-configuration-language-embedding-nimscript-pt-1.html https://peterme.net/using-nimscript-as-a-configuration-langu...

sp33der89 5y ago
Yes, this is something I should have mentioned as well, Nim does a lot of things just right and adds all the right things so it stays out of your way, is not too verbose but still has enough safety guards where you can just do what you want to do.

benob 5y ago

C interop is very easy, so you can do embedded dev by disabling memory management and standard lib, and staying very close to the generated C code. Or you can do high level stuff thanks to well though generics and meta programming. The js backend is not mature enough to cover high performance web apps. It is more like a gimmick currently. Maybe a wasm layer could be as successful as rust's...

auxym 5y ago
> Or you can do high level stuff thanks to well though generics and meta programming. Metaprogramming is also surprisingly useful for low-level, embedded programming. Eg, using compile-time logic (branching, looping) to decide which bit in which register you want to twiddle, instead of doing it at runtime, which saves computation and (sometimes) code size.

sph 5y ago

> I can't really imagine a single language that would be a good choice for "everything". Full stack Javascript enthusiasts are nowhere to be seen in this thread, but are writing their backend, frontend, desktop and mobile JS, WASM, Ethereum backend and the next ARM instruction set to speed up JS code natively, silently working towards total world domination. The nanomachines that will bring forth the end of the world will be running Node.js. But I agree with you.

rattray 5y ago
JS is also great for scripting, but really isn't popular for ML or data science (no pandas/numpy/scipy equivalents I think, other than tensorflow.js). I'm curious how Nim fares for DS/ML.
- chubot 5y ago
  JS is also not fast enough at string manipulation to express its own dev tools, at least if you want to build in seconds and not minutes. The latest incarnation of JS tools seem to be written in Go and Rust (esbuild and another one), not JS. GC is an issue for compilers, or even just front ends, which create huge, fine-grained, linked data structures
  - rattray 5y ago
    Sure, JS isn't ideal for compilers, but it is quite good - typescript is a better and more performant compiler than many languages have, as just one example. You wouldn't be crazy for choosing JS for a new compiler project, even for work that had nothing to do with JavaScript. (You would be pretty crazy to choose js to build a rich data science backend, in comparison). I do agree the GC rules out some use-cases like many gaming applications.
    - 1_player 5y ago
      Please don't write a compiler, that has nothing to do with JavaScript, in JavaScript. It needs correctness, safety and speed, none of which are JS (nor TS) strengths. You can, but that's a prerogative of all Turing-complete languages. There are much better languages fit for the purpose, which is the point of this comment thread.

Zababa 5y ago

I think Nim is in the sweet spot for it. You start with basically OCaml, which is already a great start, add some knobs for tweaking memory management, some for high performance, and you're in a great places. Compiling to native and to JS allows you to do web, cli tooling, applications, high level gamedev. Fast compilation is important for scripting, high level gamedev, exploratory programming, scripting. High performance allows you to do low level gamedev, deep learning, stuff like that. Being bootstapable from C and compiling to it with the memory management tweaks opens you the world of embedded. There's also the fact that not all language are perfect. If they all are, the general language would always lose to the specific in every niche, so you need to do different things for the general to be worth. But languages aren't perfect, and you could prefer the general language even in niches.

haxscramper 5y ago
I can't remember exact place where I've seen this discussion (I think it was on the nim IRC), but if I recall correctly, the original line of thought with nim was to take C (because fast/compiled/available-everywhere) and LISP (because flexible/extensible/good-ideas) and add more syntax sugar, so that user would not have to reimplement most of the syntax from scratch (using reader macros/special functions and so on). There are of course a lot of other languages that influenced the syntax and semantics (like Ada, python, C++ and so on), and I omitted a huge number of extra considerations.
- dom96 5y ago
  Indeed, in fact the original line of thought was[1]: > [combining] Lisp's power with Python's readability and C's performance. I'd say Nim still satisfies this very well. 1 - https://web.archive.org/web/20110704041631/http://force7.de/nimrod/ https://web.archive.org/web/20110704041631/http://force7.de/...
  - Zababa 5y ago
    Interesting, I think Julia was close to that too: > We want a language that's open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that's homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled. https://julialang.org/blog/2012/02/why-we-created-julia/ https://julialang.org/blog/2012/02/why-we-created-julia/

mst 5y ago

It's not necessarily the best choice for everything for any given team, but in the same way you'll see e.g. shops that have bought in heavily to using go by default using go for writing scripty tools as well as their main applications, using nim as 'the default language unless there's a use case specific reason to use something else' is surprisingly doable.

coliveira 5y ago

This is not a new concept, decades ago computer scientists started working on general purpose languages, that were supposed to be good for (almost) everything. The idea that a language has to serve a niche is a modern construction.

benttoothpaste 5y ago

I heard PL/I was the original language for “everything”. It’s not a new concept :)

mumblemumble 5y ago

The probable gaps I see are embedded and certain branches of gamedev, and shell scripting. Regardless of what Nim says in its sales pitch, it is a garbage collected language, and garbage collection is not really optional. The closest options are nothing, automatic reference counting (ARC), and automatic reference counting with cycle deletion (Nim calls this one ORC). Nothing at all might be fine for cloud lambda functions and command line utilities, but it generally isn't acceptable for long-running processes such as video games and firmware. ARC will still leak memory when there are cycles, so it can work if you are very careful about how you manage data. But it's trickier than what you get out of modern C++, and more resource-hungry than full manual memory management, so I can't really see this option being ideal for gamedev or embedded. And ORC is basically just Python's garbage collection algorithm, with all its strengths and weaknesses. For shell scripting, at the end of the day, it is still a statically typed, compiled language. This just doesn't hit the sweet spot for a scripting language. In that context, the performance of the language itself doesn't really matter, the entire operating context is irredeemably weakly typed, and nothing you do will ever grow large enough for static types to help much with maintainability. I'd much rather have the fast edit-test cycles of an interpreted dynamic language. That said, what I have successfully used Nim for is writing command-line tools that I interact with from shell scripts. But there, it's not replacing sh or perl or python, it's replacing C.

PMunch 5y ago
Nim works super well for embedded. The thing is that you can turn off the garbage collector and do manual memory allocation if you want to. Or simply use ARC which works a treat on embedded. I wrote my own keyboard firmware in Nim (and did a presentation of it during NimConf 2021: https://www.youtube.com/watch?v=dcHEhO4J29U https://www.youtube.com/watch?v=dcHEhO4J29U). It runs super fast and the code size is smaller than some simple "Hello world" level programs using the Arduino system. As for gamedev the ability to tune the GC by turning off automatic collection and then running it with a time-limit is perfect for preventing lag-spikes when a lot of stuff is going on (looking at you Java..). Nim actually performs very well, and the garbage collector does a great job of just getting out of the way and letting your programs fly. Your point about shell-scripting is kind of valid, it is indeed a weakly typed world. But with how fast Nim compiles the edit-test cycle feels as fast as Python, and you save a lot of time from having a silly typo that you only encounter after having run your script for a little while. The reason why Nim is good for pretty much anything is that the speed of the compiler and the garbage collection will rarely if ever stand in your way, and the flexibility of the syntax that stems from meta-programming allows it to be molded perfectly to the use-case.

systemvoltage 5y ago

Comparing with Julia, which claims to be a do-all fit-all language, I'd take Nim any day. I've used Julia in production for many years and it is an absolute nightmare to maintain. Nim seems to be what python should have been from the beginning. It is a breath of fresh air.