10 ms·

Nim Language Draws from Best of Python, Rust, Go, and Lisp

64 points by vasili111 10y ago

mixedCase 10y ago
The problem I have with Nim is that it misses the simplicity of Go and the extra safety at high performance of Rust. At least I, personally don't see the need for a middle-of-the-road language. I wish them however the best of luck. Compiling down to C means being able to leverage a lot of mature tools, and if they manage to simplify a lot of the language they may rival Go for projects when you need high performance but desire to retain high productivity regardless of how big and diverse your dev team is.
- beagle3 10y ago
  If Nim continues at the same pace, it may displace Python. It is "as fun as" Python to start with, it has the knobs that made python popular in many niches. It has official JS, C, C++ and Objective-C backends (with perfectly compatible and natively fast FFI in each case). It compiles down to small, efficient executables like Go does. It has some of the best metaprogramming facilities (in a non-lisp language), which makes it possible to introduce "source native" notation for e.g. XML and JSON. It also has an LLVM backend, though it is not yet complete. Nim is a big and complicated language, but so is Python. The size of a language itself is not a problem, as Python shows. Unlike C++, you don't have to be familiar with every small metaclass/descriptor/base-class-lookup issue to use the language. I believe Nim shares Python's "it's ok to ignore the details until you need them" feature.
  - dwringer 10y ago
    Perhaps it would be more informative to speculate on the reasons why Python would be displaced by any new language, rather than why any given language might displace Python.
    - squarefoot 10y ago
      Because albeit it got a lot better with time, it's still a lot slower than C for medium to big projects. Displace is probably not the right term as Python like many others has its strengths, I would rather think of using the right tool for the job, and to me for medium to big projects when performance is important, Python doesn't seem the best choice.
  - bsder 10y ago
    > If Nim continues at the same pace, it may displace Python. Um, no. Look at how long it took Python to displace Perl. And Perl was actively shooting itself in the brain for years or that probably wouldn't have happened. Python is far more embedded in certain areas now than Perl ever was.
    - flukus 10y ago
      Even python (3) is struggling to replace python (2).
  - rspeer 10y ago
    I can't imagine a language even starting to displace Python without a good REPL. Not just a hacked-together "lol does this work" REPL, something you can rely on, and preferably something you can use as a Jupyter backend.
- coldtea 10y ago
  >The problem I have with Nim is that it misses the simplicity of Go and the extra safety at high performance of Rust. At least I, personally don't see the need for a middle-of-the-road language. I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. That could be D or Nim or some schemes, for example, but I also want a community and tooling.
  - wtetzner 10y ago
    OCaml might be another choice.
    - coldtea 10y ago
      Yeah, been meaning to try it more, was thrown off by the lack of good tooling/documentation initially.
      - wtetzner 10y ago
        Yeah, OCaml is as close to the ideal language for me as I've found so far (it's still pretty far from my ideal, but it's closer than everything else I've tried). But it definitely has tooling issues. Tooling issues have pushed me away from it for more than one project. By far the biggest issue is dependency management/build tooling. Opam was a huge improvement in package management, so things are better than they used to be. But OCaml is missing something like Rust's Cargo, that makes creating and building projects simple and easy, and something that allows devs to avoid wasting time on build systems. OCaml also has issues with Windows support. OCaml works on Windows, but currently getting Opam to work on Windows requires Cygwin.
  - mixedCase 10y ago
    >I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. The problem is this mentality is one that produces unmaintainable software in the long run. In the case of Go, the simplicity of the language can be frustrating when it comes to expressing one's ideas in "clever" ways; but the code you write may be easily grokked by a junior developer that started with Go last week. On the other hand, things like metaprogramming allow you to build a castle of abstractions which you yourself will have trouble navigating after six months without touching the codebase, and will be a pain of legacy code to any other engineer. Sure, you don't have to use all of it at first, or ever, but that's what I mean "in the long run", either you cave in or someone else in your team does. It's hard to say Go is poorly designed, because it does what it was meant to do extraordinarily well, even if there are a few things that could be even further simplified and yes, things like generics (where the complexity tradeoff is not that high due to its ubiquitous nature) that could be added (and this discussion seems to be back on the table according to Russ Cox). As for Rust, without all the ceremony you cannot summon the demons that grant you perfect memory safety without paying for GC as well as absence of data races. Nim simply cannot provide this despite all the complexity it comes with, and really, if you're okay with that much complexity you might as well just stick with C++ and the gargantuan momentum behind it. The committee is making strides towards making the language more palatable so the appeal for Nim diminishes with each new release.
- junk_disposal 10y ago
  Unfortunately, the problem with Nim (as well as D) is the lack of big player support jump starting public opinion. Languages are inherently vendor-locked* (There isn't any way to foolproofly translate code from language A to language B), so I won't write code in a language which may disappear tomorrow or drop support for my system. * It's true that there's no real vendor lock-in by OS code, but unless there's a large community around the language which can pick up where the inventor dropped off (like C), you're on your own, and unlike small projects, languages have huge codebases which also require specialized knowledge to maintain.
- nimmer 10y ago
  "middle-of-the-road" sounds a bit unfair. Nim compile and execution times are closer to C/C++ than most languages, maybe in the 10 percentile. Its expressiveness is, arguably, close to Python. It compiles to C, Objective-C, javascript, which many other languages do not. The C target runs even on arduino boards.
sqeaky 10y ago
I don't see the appeal of Nim. We have the choice of C++14, Rust and Go for well supported robust languages with different focuses. C++14 has the best execution performance, Rust is the most safe and it seems likely go tries to be the simplest. What does Nim do better than any of these? Presuming it does do anything better than those learning Nim is hard because the examples are stale and the documentation lacking. I don't mean just the official docs, which might be great, but where are all the answers on SO and community made books or tutorials.
- adamnemecek 10y ago
  Nim is trying to be a better Python I believe.
  - baldfat 10y ago
    I have been following Nim and Racket and it really looks like Racket has been gaining more and more momentum. Really it is a Win/Win both do great things that might be able to fix some of the weakness of Python.
    - TylerE 10y ago
      The thing that can't be overstated with Nim is how fast it is. We're talking C/C++ level performance - and that's on "normal" code, not some abomination with tons of annotations or other cheats. It's also very unlike Rust in that it's a very low ceremony language. Simple scripts are no more verbose than they would be in Python or Ruby.
- rbehrends 10y ago
  C++ and Rust don't have garbage collection, Go's type system is very simplistic. Obviously, depending on what you do, this can be either an advantage or a disadvantage. My point is that there are clear differentiating factors. The closest competitor for Nim is probably D, not any of the languages you name.
  - 10y ago
Drup 10y ago
Nim always looked to me as a modern version of OCaml made by someone who has no idea how to do static type systems properly. The language as a whole might have a nice feeling and convenient features, but the type system is really not good ... D's type system, at least, is better designed. On the other hand, I always considered Rust as the result of an ML programmer looking at C++ and thinking "this is bullshit, I can do it cleaner". I might have a very ML view of the programming world, but that's ok, most other people have an ALGOL/C view of it. ;)
- jackmott 10y ago
  yeah i have fever dreams of C and ML having some sort of super baby. rust and nim are close but not quite
  - yawaramin 10y ago
    I dream of something like https://github.com/pikatchu/LinearML https://github.com/pikatchu/LinearML one day coming into the scene.
    - zem 10y ago
      mezzo looks promising: http://protz.github.io/mezzo/ http://protz.github.io/mezzo/
      - yawaramin 10y ago
        Interesting, thank you. It looks a bit complex at first sight.
  - zem 10y ago
    some others worth checking out (all largely single-developer efforts): http://www.ats-lang.org/ http://www.ats-lang.org/ [ml + c + everything dialled up to eleven. linear and dependent types. comes out of academia, but under active development and slowly beginning to gather a community.] https://eigenstate.org/myrddin/ https://eigenstate.org/myrddin/ [not really familiar with this one but it looks interetsing. close to the metal, has pattern matching over algebraic datatypes but seems more towards the c than the ml end of the spectrum from the brief glance i took.] http://mythryl.org/ http://mythryl.org/ [never took off, sadly; i really liked the looks of this one and its ambitious goals. strong sml influence, with better posix integration and some c-like surface features. developer is currently battling cancer: http://mythryl.org/pipermail/mythryl/2016-April/000942.html http://mythryl.org/pipermail/mythryl/2016-April/000942.html] http://felix-lang.org/ http://felix-lang.org/ [spawn of ml + c++ rather than ml + c. under enthusiastic if haphazard development.] there have been a few others i've seen pop up over the years; i keep meaning to make a website or at least a github awesome-style list cataloguing and tracking them.
amyjess 10y ago
There's also a lot of Modula-3 in there. Actually, the whole language is full of Pascal-isms, but I'm not sure how many come directly from Pascal and how many come via Modula-3.
alexeiz 10y ago
I don't know about Nim, but Infoworld is a pile of garbage.
rurban 10y ago
But Wikipedia editors decided it is not notable, and speedy deleted it under Nimrod. After that debacle, Wikipedia decided Nim is finally good enough for them, and they even link now Nimrod_(programming_language) to https://en.wikipedia.org/wiki/Nim_(programming_language) https://en.wikipedia.org/wiki/Nim_(programming_language)

64 points by vasili111 10y ago

The problem I have with Nim is that it misses the simplicity of Go and the extra safety at high performance of Rust. At least I, personally don't see the need for a middle-of-the-road language. I wish them however the best of luck. Compiling down to C means being able to leverage a lot of mature tools, and if they manage to simplify a lot of the language they may rival Go for projects when you need high performance but desire to retain high productivity regardless of how big and diverse your dev team is.

beagle3 10y ago
If Nim continues at the same pace, it may displace Python. It is "as fun as" Python to start with, it has the knobs that made python popular in many niches. It has official JS, C, C++ and Objective-C backends (with perfectly compatible and natively fast FFI in each case). It compiles down to small, efficient executables like Go does. It has some of the best metaprogramming facilities (in a non-lisp language), which makes it possible to introduce "source native" notation for e.g. XML and JSON. It also has an LLVM backend, though it is not yet complete. Nim is a big and complicated language, but so is Python. The size of a language itself is not a problem, as Python shows. Unlike C++, you don't have to be familiar with every small metaclass/descriptor/base-class-lookup issue to use the language. I believe Nim shares Python's "it's ok to ignore the details until you need them" feature.
- dwringer 10y ago
  Perhaps it would be more informative to speculate on the reasons why Python would be displaced by any new language, rather than why any given language might displace Python.
  - squarefoot 10y ago
    Because albeit it got a lot better with time, it's still a lot slower than C for medium to big projects. Displace is probably not the right term as Python like many others has its strengths, I would rather think of using the right tool for the job, and to me for medium to big projects when performance is important, Python doesn't seem the best choice.
- bsder 10y ago
  > If Nim continues at the same pace, it may displace Python. Um, no. Look at how long it took Python to displace Perl. And Perl was actively shooting itself in the brain for years or that probably wouldn't have happened. Python is far more embedded in certain areas now than Perl ever was.
  - flukus 10y ago
    Even python (3) is struggling to replace python (2).
- rspeer 10y ago
  I can't imagine a language even starting to displace Python without a good REPL. Not just a hacked-together "lol does this work" REPL, something you can rely on, and preferably something you can use as a Jupyter backend.
coldtea 10y ago
>The problem I have with Nim is that it misses the simplicity of Go and the extra safety at high performance of Rust. At least I, personally don't see the need for a middle-of-the-road language. I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. That could be D or Nim or some schemes, for example, but I also want a community and tooling.
- wtetzner 10y ago
  OCaml might be another choice.
  - coldtea 10y ago
    Yeah, been meaning to try it more, was thrown off by the lack of good tooling/documentation initially.
    - wtetzner 10y ago
      Yeah, OCaml is as close to the ideal language for me as I've found so far (it's still pretty far from my ideal, but it's closer than everything else I've tried). But it definitely has tooling issues. Tooling issues have pushed me away from it for more than one project. By far the biggest issue is dependency management/build tooling. Opam was a huge improvement in package management, so things are better than they used to be. But OCaml is missing something like Rust's Cargo, that makes creating and building projects simple and easy, and something that allows devs to avoid wasting time on build systems. OCaml also has issues with Windows support. OCaml works on Windows, but currently getting Opam to work on Windows requires Cygwin.
- mixedCase 10y ago
  >I'd very much like a more expressive and better designed than Go language, without the ceremony and straight-jacket of Rust. The problem is this mentality is one that produces unmaintainable software in the long run. In the case of Go, the simplicity of the language can be frustrating when it comes to expressing one's ideas in "clever" ways; but the code you write may be easily grokked by a junior developer that started with Go last week. On the other hand, things like metaprogramming allow you to build a castle of abstractions which you yourself will have trouble navigating after six months without touching the codebase, and will be a pain of legacy code to any other engineer. Sure, you don't have to use all of it at first, or ever, but that's what I mean "in the long run", either you cave in or someone else in your team does. It's hard to say Go is poorly designed, because it does what it was meant to do extraordinarily well, even if there are a few things that could be even further simplified and yes, things like generics (where the complexity tradeoff is not that high due to its ubiquitous nature) that could be added (and this discussion seems to be back on the table according to Russ Cox). As for Rust, without all the ceremony you cannot summon the demons that grant you perfect memory safety without paying for GC as well as absence of data races. Nim simply cannot provide this despite all the complexity it comes with, and really, if you're okay with that much complexity you might as well just stick with C++ and the gargantuan momentum behind it. The committee is making strides towards making the language more palatable so the appeal for Nim diminishes with each new release.
junk_disposal 10y ago
Unfortunately, the problem with Nim (as well as D) is the lack of big player support jump starting public opinion. Languages are inherently vendor-locked* (There isn't any way to foolproofly translate code from language A to language B), so I won't write code in a language which may disappear tomorrow or drop support for my system. * It's true that there's no real vendor lock-in by OS code, but unless there's a large community around the language which can pick up where the inventor dropped off (like C), you're on your own, and unlike small projects, languages have huge codebases which also require specialized knowledge to maintain.
nimmer 10y ago
"middle-of-the-road" sounds a bit unfair. Nim compile and execution times are closer to C/C++ than most languages, maybe in the 10 percentile. Its expressiveness is, arguably, close to Python. It compiles to C, Objective-C, javascript, which many other languages do not. The C target runs even on arduino boards.

sqeaky 10y ago

I don't see the appeal of Nim. We have the choice of C++14, Rust and Go for well supported robust languages with different focuses. C++14 has the best execution performance, Rust is the most safe and it seems likely go tries to be the simplest. What does Nim do better than any of these? Presuming it does do anything better than those learning Nim is hard because the examples are stale and the documentation lacking. I don't mean just the official docs, which might be great, but where are all the answers on SO and community made books or tutorials.

adamnemecek 10y ago
Nim is trying to be a better Python I believe.
- baldfat 10y ago
  I have been following Nim and Racket and it really looks like Racket has been gaining more and more momentum. Really it is a Win/Win both do great things that might be able to fix some of the weakness of Python.
  - TylerE 10y ago
    The thing that can't be overstated with Nim is how fast it is. We're talking C/C++ level performance - and that's on "normal" code, not some abomination with tons of annotations or other cheats. It's also very unlike Rust in that it's a very low ceremony language. Simple scripts are no more verbose than they would be in Python or Ruby.
rbehrends 10y ago
C++ and Rust don't have garbage collection, Go's type system is very simplistic. Obviously, depending on what you do, this can be either an advantage or a disadvantage. My point is that there are clear differentiating factors. The closest competitor for Nim is probably D, not any of the languages you name.
- 10y ago

Drup 10y ago

Nim always looked to me as a modern version of OCaml made by someone who has no idea how to do static type systems properly. The language as a whole might have a nice feeling and convenient features, but the type system is really not good ... D's type system, at least, is better designed. On the other hand, I always considered Rust as the result of an ML programmer looking at C++ and thinking "this is bullshit, I can do it cleaner". I might have a very ML view of the programming world, but that's ok, most other people have an ALGOL/C view of it. ;)

jackmott 10y ago
yeah i have fever dreams of C and ML having some sort of super baby. rust and nim are close but not quite
- yawaramin 10y ago
  I dream of something like https://github.com/pikatchu/LinearML https://github.com/pikatchu/LinearML one day coming into the scene.
  - zem 10y ago
    mezzo looks promising: http://protz.github.io/mezzo/ http://protz.github.io/mezzo/
    - yawaramin 10y ago
      Interesting, thank you. It looks a bit complex at first sight.
- zem 10y ago
  some others worth checking out (all largely single-developer efforts): http://www.ats-lang.org/ http://www.ats-lang.org/ [ml + c + everything dialled up to eleven. linear and dependent types. comes out of academia, but under active development and slowly beginning to gather a community.] https://eigenstate.org/myrddin/ https://eigenstate.org/myrddin/ [not really familiar with this one but it looks interetsing. close to the metal, has pattern matching over algebraic datatypes but seems more towards the c than the ml end of the spectrum from the brief glance i took.] http://mythryl.org/ http://mythryl.org/ [never took off, sadly; i really liked the looks of this one and its ambitious goals. strong sml influence, with better posix integration and some c-like surface features. developer is currently battling cancer: http://mythryl.org/pipermail/mythryl/2016-April/000942.html http://mythryl.org/pipermail/mythryl/2016-April/000942.html] http://felix-lang.org/ http://felix-lang.org/ [spawn of ml + c++ rather than ml + c. under enthusiastic if haphazard development.] there have been a few others i've seen pop up over the years; i keep meaning to make a website or at least a github awesome-style list cataloguing and tracking them.

amyjess 10y ago

There's also a lot of Modula-3 in there. Actually, the whole language is full of Pascal-isms, but I'm not sure how many come directly from Pascal and how many come via Modula-3.

alexeiz 10y ago

I don't know about Nim, but Infoworld is a pile of garbage.

rurban 10y ago

But Wikipedia editors decided it is not notable, and speedy deleted it under Nimrod. After that debacle, Wikipedia decided Nim is finally good enough for them, and they even link now Nimrod_(programming_language) to https://en.wikipedia.org/wiki/Nim_(programming_language) https://en.wikipedia.org/wiki/Nim_(programming_language)