5 ms·

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 f

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.

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.