10 ms·

Author of “Unix in Rust” Abandons Rust in Favour of Nim

149 points by dom96 12y ago

marijn 12y ago
Last time I looked at Nim, I was put off by the lack of algebraic data types and pattern matching. I still can't find anything about them in the manual. Am I missing something, or is this something it just doesn't have?
- def- 12y ago
  Instead of ADTs there are object variants in Nim: http://nim-lang.org/manual.html#object-variants http://nim-lang.org/manual.html#object-variants With ADTs: data Shape a = Rectangle { x :: Float , y :: Float , width :: Float , height :: Float } | Circle { x :: Float , y :: Float , radius :: Float } With Object Variants, note that we don't have to repeat x and y: type ShapeKind = enum Rectangle, Circle Shape = object x, y: float case kind: ShapeKind of Rectangle: width, height: float of Circle: radius: float The pattern matching in Nim is quite limited. Something like this works: let (x, y) = getCoordinates() But Nim doesn't have (x,y) = (y,x) for example, instead swap can be used. You could implement your own pattern matching using metaprogramming: http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag/240165321 http://www.drdobbs.com/open-source/nimrod-a-new-systems-prog...
def- 12y ago
There was a discussion about this on r/rust before: https://www.reddit.com/r/rust/comments/2vqy81/author_of_unix_in_rust_abandons_rust_in_favor_of/ https://www.reddit.com/r/rust/comments/2vqy81/author_of_unix... My reasons for using Nim can be found in my blog: http://hookrace.net/ http://hookrace.net/
acomjean 12y ago
Basically he likes the way Nim compiles to C fairly cleanly. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. He seems to like Rust it just likes Nim better, feels currently its better suited. Actually fairly calm about it. Different people prefer different languages for a variety of reasons. Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times.
- aidenn0 12y ago
  > Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions: Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. > Basically he likes Nim compiled to C better than just Rust. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. I'm also wary of the mentioned productivity gains; I simply do not feel as confident in the correctness of Nim code I write as I do Rust code I write. This actually isn't solely due to the enforced move semantics of Rust, but due to a lot of the comments about Nim in the article linked in the issue; Nim and Rust surprise me about the same amount, but with Rust the surprise would yield (sometimes inscrutable) errors from the compiler; Nim was more likely to yield surprising runtime behavior. The two languages I use most often are C and Common Lisp. C has some surprising runtime corners, but the language (at least pre C11, which I haven't used much yet, so can't comment on) is small enough that I can keep it all in my own head. Common Lisp also has some surprising behaviors, and it's a big language, but this is mitigated by 2 things: 1) Common Lisp allows very concise code; this very often lets me keep all of the portion of the software I'm working on in my head (versus C, where I keep all the language in my head) 2) Superior tooling; SLIME lets you very quickly drill down and look at what's happening. Combined with #1 it is very fast to find where the model of the code in my head diverges from reality, so most bugs are short lived.
  - def- 12y ago
    > Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. I would say "performant C" is the target, it being rather readable is nice too, though. I have a list of some benchmarks down here: https://github.com/def-/nim-benchmarksgame#nim-implementations-for-the-computer-language-benchmarks-game https://github.com/def-/nim-benchmarksgame#nim-implementatio...
keslag 12y ago
I think the reasoning is sound, but this isn't an indication of either language being better than the other. Only that it's easier to look under the hood of Nim. I find Nim easier to read, and then as is with ruby, probably more productive for prototypes, but I'd like to see more use cases before I start to move in that direction. It does make me wonder if we'll ever see a Nim to rust transpiler.
- jeffreyrogers 12y ago
  > It does make me wonder if we'll ever see a Nim to rust transpiler. I'm not really sure what you'd get from that? They seem to share most of the same features, with rust focusing a bit more on safety via its type system. I'm personally more partial to Nim since it seems simpler to me, but Rust may be good for things I don't program regularly.
- aikah 12y ago
  2 different languages for 2 different use cases. Seems to me that Nim is more in league with Go and D while Rust is lower level with some syntactic sugar. Might be wrong but that's how I feel about these. Anyway it's great to have new french languages that you can still link to C libs when you need it.
  - aikah 12y ago
    Edit: meant fresh not french ,of course.
  - Mikeb85 12y ago
    I would agree. I don't think they compete directly, the only real similarities is they both compile to native code, and both are fast. Nim is more of a Pascal/Python/Coffeescript hybrid with easy interoperability with C and nice tooling.
- pcwalton 12y ago
  > It does make me wonder if we'll ever see a Nim to rust transpiler. Impossible, unless you compile to the unsafe Rust dialect. Nim is not memory safe in multithreaded mode, last I checked, while Rust is. So (unsafe) things expressible in Nim will not be expressible in Rust, because Rust's type system prevents them.
jeffreyrogers 12y ago
Here is the unix kernel (in Nim) that he mentions: https://github.com/ckkashyap/nim-xv6 https://github.com/ckkashyap/nim-xv6. It is based off of the xv6 OS: http://pdos.csail.mit.edu/6.828/2014/xv6.html http://pdos.csail.mit.edu/6.828/2014/xv6.html
pkulak 12y ago
Isn't Nim GCed? How are you going to build a kernel like that?
- chroem- 12y ago
  GC in Nim is highly configurable: you can pause GC or even delay it indefinitely. Plus there's lots of tweaks you can make to how GC treats your code using Nim's pragma system. And no, the standard library does not rely on GC like in D.
  - pcwalton 12y ago
    My issue with this approach is that it seems inherently racy in multithreaded programs. Nim gets around that issue by having a per-thread GC and segfaulting if you send pointers to other threads (unless you use the Boehm GC, last I checked)—your only backup seems to be manual memory management—but I don't see that as a scalable approach for large-scale software with dozens or hundreds of threads. (Not to mention that not having a thread-safe GC neglects a major benefit of a GC for lock-free data structures; having to use hazard pointers if you're a GC'd language seems like a shame.)
  - ptx 12y ago
    > And no, the standard library does not rely on GC like in D. Does this mean that all of the standard library is written using manual memory management? Wouldn't this slow down its development and expose it to all the same reliability and security problems C has?
  - gfasdgsfd 12y ago
    > And no, the standard library does not rely on GC like in D. This isn't correct, it relies heavily on GC.
- falcolas 12y ago
  The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or co-routine. This doesn't prevent writing Kernels or userspace applications in Rust.
jwecker 12y ago
We just switched from Rust to Nim for a very large proprietary project I've been involved with after rejecting proofs of concept in Go and Erlang earlier in the process. This despite the fact that we had formally decided on Rust, had tons of code developed in it, and only stumbled upon Nim by complete accident randomly one day. Even though many large components were already developed in Rust we have already reached par and have shot ahead of where we were at. I don't want to diss Rust in any way (or Go for that matter), but I figure they both have corporate backing and can easily speak for themselves, whereas Nim does not- so I don't feel too bad offering our somewhat informed opinion :-) In a nutshell, Go ended up not really being a systems language and Rust has the beautiful goal of memory safety and correctness without garbage collection but in the end feels like it's designed by committee. Nim, with Araq it's benevolent dictator, has had the opportunity to be highly opinionated. Much of the time that seems to simply allow projects to either shoot themselves in the foot or stagnate, but occasionally it produces true gems- and I really feel like that's what Nim is. Some aspects of Nim that keep blowing me away more and more: * Truly allows you to be close to the metal/OS/libraries (most beautiful and simple ffi ever) AND simultaneously allows you to think about the problem at hand in terms of the problem- i.e., high level abstractions and DSL creation like you can do with Ruby (but even cleaner in many ways). I always thought those were two opposite ends of a spectrum and didn't expect a language to even attempt to bridge the chasm- then along comes Nim and not only attempts but succeeds beyond what I ever would have thought possible. To illustrate: it has become my go-to language for quick scripting, faster to whip something together than shell or ruby or perl (and many orders of magnitude faster to run- often even including the automatic compilation the first time)- while also being the fastest, cleanest, safest way to do something low-level, like a mmapped memory-mirrored super-fast circular buffer or cpu-cache optimized lock-free message passing... * Even though it has C as an intermediate step, it doesn't feel or act anything like C. While not as strong as Rust in this area (I know, Rust goes straight to LLVM's IR instead of C- but the risks are the same)- it generates code that is much more safe (and concise) than writing it straight in C. I know, there are other language that do this well also- but usually by sacrificing the ability to easily and cleanly do system-level coding- like a raw OS system call, for example. * On a related note, despite feeling more high level than Rust, it can do so much more at a low level. For example, using musl instead of glibc (which at least last time I checked wasn't possible in Rust due to some accidental coupling). * So fast. While premature optimization is considered the root of all evil, and linear optimization often does not end up adding significant real value, I've been reminded more in the last few weeks than ever before that when speedups are around 2+ orders of magnitude _it is often a complete game changer_- it often allows you to model the problem in a completely new way (don't have a generally understandable example for Nim offhand but take docker vs dual-boot for an extreme non-Nim example- VMs were a mostly linear improvement over dual-booting and other network-based workarounds, but only with linux containers and their orders-of-magnitude "startup" time, snapshotting, etc. etc. was docker able to say "these are so cheap and fast we can assume a single running process per 'image'"). * Even though it's not as formally safe as Rust yet, in practice it feels and acts as safe, without the cognitive overload. * Rust gets tons of new commits from tons of contributors every day. I worried when looking at Nim that the lower volume of commits meant that the language was less... alive or long-term-tenable. But on closer evaluation I realized that there was literally less that needed changing, and that the changes that seemed to need code to change all over the Rust repository would, given an equivalent scope in Nim, require trivial changes to just one or two files. (for example, Rust's massive [and extremely slow] bootstrapping pipeline and parsing architecture, vs Nim's built in PEG syntax and 5-line loop that keeps compiling itself using the last iterations' outputs until the outputs don't change anymore). In short: - All the simple beauty (IMO) and conciseness of a python-like/pseudocode-like syntax without all the plumbing and pedantic one-way that comes with python. In other words, beats python at python's own strengths (not even mentioning speed or language features etc...) - Top-down modeling and DSL affinity like Ruby with less feeling of magic- e.g., better "grep"-ability and tracing. In fact, the DSLs and up being cleaner than idiomatic Ruby ones. So beats Ruby IMO at one of Ruby's core strengths. - Seems as safe as Rust with much cleaner syntax and simpler semantics. (this is something we're actively quantifying at the moment). Easily 10x the productivity. _Almost_ beats Rust at its core strength. - Easiest FFI integration of any language I've worked with, including possibly C/C++. - All the low-level facilities of C/C++ without the undefined-behavior, with better static checking, much better meta-programming, etc. etc. Beats C/C++ at their core strength. - Utterly intuitive obliteration of autotools/configure/makefile/directives type toolchains required for system development using C/C++. - It's very fast and efficient per-thread garbage-collection (when you want it) essentially allows it to eat Go and Java's lunch as well. - It's a genuinely fun language (for us at least). I've already been too verbose and am out of time but I should include for some sense of completeness some current weaknesses of Nim. None of these ended up being remotely show-stoppers for us, but at least initially we worried about: * Too much attention to windows (doing nix and even linux-only development is so easy it has turned out to be a non-issue). Less safety than Rust when doing manual memory management (hasn't been an issue and we believe unlikely to be an issue in practice). * Lack of (implied) long-term corporate support (already more stable than some others and community is strong where it counts. Also, no matter how much corporate support they get- Rust will still be more verbose and designed by committee and Go will still fall short of being a true to-the-metal systems programming language and neither will ever have Ruby and Lisp's moldability and endless potential to get out of your way). * Smaller community/package ecosystem than many others (so easy to do FFI or to even _reimplement something done in C using 1/5 the code_ that it also has turned out to be a non-issue. Now I worry that it's so easy to code that it will have a library-bloat issue like Ruby requiring something like ruby-toolbox) * "How have I not heard about this before?? Why isn't it bigger? Is something wrong with it?" I start worrying about things like D's standard-library wars or lisp & scheme's utter flexibility combined with poor readability... Nope, just new and only spread through word-of-mouth, like Ruby, Python, and Perl long ago... [there, once I've written three separate lists in a single comment I can safely say I've said too much and should get back to work].
tokyo1000 12y ago
What is Nim's community like? I ask because I first learned about Nim a few weeks ago when some people were chatting about it on Slashdot. One comment [http://slashdot.org/comments.pl?sid=6771453&cid=48860921 http://slashdot.org/comments.pl?sid=6771453&cid=48860921] quoted from that day's Nim irc logs and well it was a little disturbing. There was a lot of insulting and name calling going on and it didn't leave a good impression on me. I don't want to judge the entire Nim community of course but I was taken aback by those many very negative quotations. I don't think I've ever seen that kind of animosity in the Rust irc channels I mean.
- jwecker 12y ago
  In my experience it's very responsive and rational. It benefits as a language from being opinionated which is sure to ruffle feathers from time-to-time. Obviously not as big of a community as some others, but that hasn't been an issue for us. I've seen heated flamewars about important issues rarely, about non-important/emotional issues only very rarely and only in IRC (where the current official policy is "we're a new language so don't kick someone out unless absolutely necessary"). More often with Nim you'll see the occasional "wtf- who implemented this? it needs to change to ---". To be honest, IRC isn't the best place to judge a "community"- trolls and good people venting have disproportionate voice there. And to be honest, if that exchange referenced was disturbing... just hope you never have to be involved in a decision with the Linux kernel team or (the most abrasive example I have first-hand knowledge of) the Apache development team 10 years ago ;-) Notice there's only one comment there from Araq and it's trying to de-escalate things. If you were to pop onto IRC and ask something technical or philosophical that wanted a rational response Araq or many of the others not represented in that slashdot comment will most likely answer very politely and rationally within a minute or so (I think he's in Germany though? so timing may be an issue). I think a better "feel" for a community can be gauged by the tone and quality of blog entries coming out and threads in github issues / pull-requests than IRC snippets. That and the fact that if you decide to use Nim based on its technical merits then you _are_ the community- and at this early stage you can easily influence the tenor of discussions and decision-making for good if you choose.
  - 12y ago
bhouston 12y ago
An idividual drawn to novel immature languages switches their interest as language matures.
lxc 12y ago
Nim is the most fun language I have tried. I feel way more productive in it :)
Mikeb85 12y ago
Having played with both Nim and Rust, I also prefer Nim. Basically Rust is a slightly more pleasant C++, but still huge, complicated, things break all the time, and there's no IDE support to help you make sense of anything. It's probably more robust, maybe faster as things get big, but I haven't got there yet. Nim is as easy to write as Python, the toolchain is very easy to set up, creating Nim interfaces (with documentation) to your favourite C or C++ library is dirt simple (thanks to tools that come with the compiler), and the language is shockingly fast. Right now, it's just so much easier to get things done with Nim. Reminds me of Coffee-Script - because it compiles to another language, you get access to a million libraries and platforms for free.
- kevin_thibedeau 12y ago
  It's a shame that it doesn't have the mindshare: 27 nim/nimrod questions on SO, 1548 rust. Still not "notable" enough for a Wikipedia entry. I can see nim getting stuck lingering on the margin like Objective-C did before OSX.
  - Mikeb85 12y ago
    It's possible. I personally just hope that Araq and others keep working on it. Right now it's quite easy to use without a lot of libraries written in Nim, because of interoperability. Besides, I see Nim more as a 'secret weapon' sort of language, or something that individual programmers use. Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it.
    - pcwalton 12y ago
      > Besides, I see Nim more as a 'secret weapon' sort of language, or something that individual programmers use. Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it. I don't think that "big idea" languages [1] are necessarily the provenance of corporations/committees as opposed to individuals. If anything, the opposite tends to be true, as large languages such as C++ and C# have tended to grow to encompass more and more features over time as their feature sets expand to accommodate more and more stakeholders. Rust in particular started out as an individual project, with a set of design constraints—those of low-level memory-safe systems programming—that have remained unchanged throughout its lifetime. [1] I'm not really a fan of that term anyway, as "big ideas" are just design constraints, things that all languages have. Rust just happens to have a unique (among industry languages, save maybe ATS) set of them.
thiht 12y ago
Maybe it'll be renamed "Nimix", that's a great name!

149 points by dom96 12y ago

Last time I looked at Nim, I was put off by the lack of algebraic data types and pattern matching. I still can't find anything about them in the manual. Am I missing something, or is this something it just doesn't have?

def- 12y ago
Instead of ADTs there are object variants in Nim: http://nim-lang.org/manual.html#object-variants http://nim-lang.org/manual.html#object-variants With ADTs: data Shape a = Rectangle { x :: Float , y :: Float , width :: Float , height :: Float } | Circle { x :: Float , y :: Float , radius :: Float } With Object Variants, note that we don't have to repeat x and y: type ShapeKind = enum Rectangle, Circle Shape = object x, y: float case kind: ShapeKind of Rectangle: width, height: float of Circle: radius: float The pattern matching in Nim is quite limited. Something like this works: let (x, y) = getCoordinates() But Nim doesn't have (x,y) = (y,x) for example, instead swap can be used. You could implement your own pattern matching using metaprogramming: http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag/240165321 http://www.drdobbs.com/open-source/nimrod-a-new-systems-prog...

def- 12y ago

There was a discussion about this on r/rust before: https://www.reddit.com/r/rust/comments/2vqy81/author_of_unix_in_rust_abandons_rust_in_favor_of/ https://www.reddit.com/r/rust/comments/2vqy81/author_of_unix... My reasons for using Nim can be found in my blog: http://hookrace.net/ http://hookrace.net/

acomjean 12y ago

Basically he likes the way Nim compiles to C fairly cleanly. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. He seems to like Rust it just likes Nim better, feels currently its better suited. Actually fairly calm about it. Different people prefer different languages for a variety of reasons. Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times.

aidenn0 12y ago
> Not sure compiling to C as an extra step is going to do to reliablity or performance in Nim but we'll see. Interesting times. Having worked with languages that target C, machine code and C, I will make a few predictions: Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. > Basically he likes Nim compiled to C better than just Rust. Helps him because he knows and understands C, and reading between the lines he wants to target systems that already have C compilers, but not Rust ones. Maybe someone else can confirm, but I think right now Rust can't cross-compile; I would hope that this changes after 1.0, as LLVM makes it fairly easy to do. I'm also wary of the mentioned productivity gains; I simply do not feel as confident in the correctness of Nim code I write as I do Rust code I write. This actually isn't solely due to the enforced move semantics of Rust, but due to a lot of the comments about Nim in the article linked in the issue; Nim and Rust surprise me about the same amount, but with Rust the surprise would yield (sometimes inscrutable) errors from the compiler; Nim was more likely to yield surprising runtime behavior. The two languages I use most often are C and Common Lisp. C has some surprising runtime corners, but the language (at least pre C11, which I haven't used much yet, so can't comment on) is small enough that I can keep it all in my own head. Common Lisp also has some surprising behaviors, and it's a big language, but this is mitigated by 2 things: 1) Common Lisp allows very concise code; this very often lets me keep all of the portion of the software I'm working on in my head (versus C, where I keep all the language in my head) 2) Superior tooling; SLIME lets you very quickly drill down and look at what's happening. Combined with #1 it is very fast to find where the model of the code in my head diverges from reality, so most bugs are short lived.
- def- 12y ago
  > Compiling to C shouldn't hurt reliability anymore than compiling to LLVM. Performance will likely be somewhat less, particularly as "readable C" is the target, not arbitrary C. I would say "performant C" is the target, it being rather readable is nice too, though. I have a list of some benchmarks down here: https://github.com/def-/nim-benchmarksgame#nim-implementations-for-the-computer-language-benchmarks-game https://github.com/def-/nim-benchmarksgame#nim-implementatio...

keslag 12y ago

I think the reasoning is sound, but this isn't an indication of either language being better than the other. Only that it's easier to look under the hood of Nim. I find Nim easier to read, and then as is with ruby, probably more productive for prototypes, but I'd like to see more use cases before I start to move in that direction. It does make me wonder if we'll ever see a Nim to rust transpiler.

jeffreyrogers 12y ago
> It does make me wonder if we'll ever see a Nim to rust transpiler. I'm not really sure what you'd get from that? They seem to share most of the same features, with rust focusing a bit more on safety via its type system. I'm personally more partial to Nim since it seems simpler to me, but Rust may be good for things I don't program regularly.
aikah 12y ago
2 different languages for 2 different use cases. Seems to me that Nim is more in league with Go and D while Rust is lower level with some syntactic sugar. Might be wrong but that's how I feel about these. Anyway it's great to have new french languages that you can still link to C libs when you need it.
- aikah 12y ago
  Edit: meant fresh not french ,of course.
- Mikeb85 12y ago
  I would agree. I don't think they compete directly, the only real similarities is they both compile to native code, and both are fast. Nim is more of a Pascal/Python/Coffeescript hybrid with easy interoperability with C and nice tooling.
pcwalton 12y ago
> It does make me wonder if we'll ever see a Nim to rust transpiler. Impossible, unless you compile to the unsafe Rust dialect. Nim is not memory safe in multithreaded mode, last I checked, while Rust is. So (unsafe) things expressible in Nim will not be expressible in Rust, because Rust's type system prevents them.

jeffreyrogers 12y ago

Here is the unix kernel (in Nim) that he mentions: https://github.com/ckkashyap/nim-xv6 https://github.com/ckkashyap/nim-xv6. It is based off of the xv6 OS: http://pdos.csail.mit.edu/6.828/2014/xv6.html http://pdos.csail.mit.edu/6.828/2014/xv6.html

pkulak 12y ago

Isn't Nim GCed? How are you going to build a kernel like that?

chroem- 12y ago
GC in Nim is highly configurable: you can pause GC or even delay it indefinitely. Plus there's lots of tweaks you can make to how GC treats your code using Nim's pragma system. And no, the standard library does not rely on GC like in D.
- pcwalton 12y ago
  My issue with this approach is that it seems inherently racy in multithreaded programs. Nim gets around that issue by having a per-thread GC and segfaulting if you send pointers to other threads (unless you use the Boehm GC, last I checked)—your only backup seems to be manual memory management—but I don't see that as a scalable approach for large-scale software with dozens or hundreds of threads. (Not to mention that not having a thread-safe GC neglects a major benefit of a GC for lock-free data structures; having to use hazard pointers if you're a GC'd language seems like a shame.)
- ptx 12y ago
  > And no, the standard library does not rely on GC like in D. Does this mean that all of the standard library is written using manual memory management? Wouldn't this slow down its development and expose it to all the same reliability and security problems C has?
- gfasdgsfd 12y ago
  > And no, the standard library does not rely on GC like in D. This isn't correct, it relies heavily on GC.
falcolas 12y ago
The presence or lack of a GC has nothing to do with the Kernel. The Kernel is simply another program, with specific requirements and limitations. So long as your language allows you to write and call raw assembly, you can write a Kernel. It's worth remembering that Rust has a form of GC as well - it uses a reference counting collection mechanism which is executed at scope boundaries instead of as a separate thread or co-routine. This doesn't prevent writing Kernels or userspace applications in Rust.

jwecker 12y ago

We just switched from Rust to Nim for a very large proprietary project I've been involved with after rejecting proofs of concept in Go and Erlang earlier in the process. This despite the fact that we had formally decided on Rust, had tons of code developed in it, and only stumbled upon Nim by complete accident randomly one day. Even though many large components were already developed in Rust we have already reached par and have shot ahead of where we were at. I don't want to diss Rust in any way (or Go for that matter), but I figure they both have corporate backing and can easily speak for themselves, whereas Nim does not- so I don't feel too bad offering our somewhat informed opinion :-) In a nutshell, Go ended up not really being a systems language and Rust has the beautiful goal of memory safety and correctness without garbage collection but in the end feels like it's designed by committee. Nim, with Araq it's benevolent dictator, has had the opportunity to be highly opinionated. Much of the time that seems to simply allow projects to either shoot themselves in the foot or stagnate, but occasionally it produces true gems- and I really feel like that's what Nim is. Some aspects of Nim that keep blowing me away more and more: * Truly allows you to be close to the metal/OS/libraries (most beautiful and simple ffi ever) AND simultaneously allows you to think about the problem at hand in terms of the problem- i.e., high level abstractions and DSL creation like you can do with Ruby (but even cleaner in many ways). I always thought those were two opposite ends of a spectrum and didn't expect a language to even attempt to bridge the chasm- then along comes Nim and not only attempts but succeeds beyond what I ever would have thought possible. To illustrate: it has become my go-to language for quick scripting, faster to whip something together than shell or ruby or perl (and many orders of magnitude faster to run- often even including the automatic compilation the first time)- while also being the fastest, cleanest, safest way to do something low-level, like a mmapped memory-mirrored super-fast circular buffer or cpu-cache optimized lock-free message passing... * Even though it has C as an intermediate step, it doesn't feel or act anything like C. While not as strong as Rust in this area (I know, Rust goes straight to LLVM's IR instead of C- but the risks are the same)- it generates code that is much more safe (and concise) than writing it straight in C. I know, there are other language that do this well also- but usually by sacrificing the ability to easily and cleanly do system-level coding- like a raw OS system call, for example. * On a related note, despite feeling more high level than Rust, it can do so much more at a low level. For example, using musl instead of glibc (which at least last time I checked wasn't possible in Rust due to some accidental coupling). * So fast. While premature optimization is considered the root of all evil, and linear optimization often does not end up adding significant real value, I've been reminded more in the last few weeks than ever before that when speedups are around 2+ orders of magnitude _it is often a complete game changer_- it often allows you to model the problem in a completely new way (don't have a generally understandable example for Nim offhand but take docker vs dual-boot for an extreme non-Nim example- VMs were a mostly linear improvement over dual-booting and other network-based workarounds, but only with linux containers and their orders-of-magnitude "startup" time, snapshotting, etc. etc. was docker able to say "these are so cheap and fast we can assume a single running process per 'image'"). * Even though it's not as formally safe as Rust yet, in practice it feels and acts as safe, without the cognitive overload. * Rust gets tons of new commits from tons of contributors every day. I worried when looking at Nim that the lower volume of commits meant that the language was less... alive or long-term-tenable. But on closer evaluation I realized that there was literally less that needed changing, and that the changes that seemed to need code to change all over the Rust repository would, given an equivalent scope in Nim, require trivial changes to just one or two files. (for example, Rust's massive [and extremely slow] bootstrapping pipeline and parsing architecture, vs Nim's built in PEG syntax and 5-line loop that keeps compiling itself using the last iterations' outputs until the outputs don't change anymore). In short: - All the simple beauty (IMO) and conciseness of a python-like/pseudocode-like syntax without all the plumbing and pedantic one-way that comes with python. In other words, beats python at python's own strengths (not even mentioning speed or language features etc...) - Top-down modeling and DSL affinity like Ruby with less feeling of magic- e.g., better "grep"-ability and tracing. In fact, the DSLs and up being cleaner than idiomatic Ruby ones. So beats Ruby IMO at one of Ruby's core strengths. - Seems as safe as Rust with much cleaner syntax and simpler semantics. (this is something we're actively quantifying at the moment). Easily 10x the productivity. _Almost_ beats Rust at its core strength. - Easiest FFI integration of any language I've worked with, including possibly C/C++. - All the low-level facilities of C/C++ without the undefined-behavior, with better static checking, much better meta-programming, etc. etc. Beats C/C++ at their core strength. - Utterly intuitive obliteration of autotools/configure/makefile/directives type toolchains required for system development using C/C++. - It's very fast and efficient per-thread garbage-collection (when you want it) essentially allows it to eat Go and Java's lunch as well. - It's a genuinely fun language (for us at least). I've already been too verbose and am out of time but I should include for some sense of completeness some current weaknesses of Nim. None of these ended up being remotely show-stoppers for us, but at least initially we worried about: * Too much attention to windows (doing nix and even linux-only development is so easy it has turned out to be a non-issue). Less safety than Rust when doing manual memory management (hasn't been an issue and we believe unlikely to be an issue in practice). * Lack of (implied) long-term corporate support (already more stable than some others and community is strong where it counts. Also, no matter how much corporate support they get- Rust will still be more verbose and designed by committee and Go will still fall short of being a true to-the-metal systems programming language and neither will ever have Ruby and Lisp's moldability and endless potential to get out of your way). * Smaller community/package ecosystem than many others (so easy to do FFI or to even _reimplement something done in C using 1/5 the code_ that it also has turned out to be a non-issue. Now I worry that it's so easy to code that it will have a library-bloat issue like Ruby requiring something like ruby-toolbox) * "How have I not heard about this before?? Why isn't it bigger? Is something wrong with it?" I start worrying about things like D's standard-library wars or lisp & scheme's utter flexibility combined with poor readability... Nope, just new and only spread through word-of-mouth, like Ruby, Python, and Perl long ago... [there, once I've written three separate lists in a single comment I can safely say I've said too much and should get back to work].

tokyo1000 12y ago

What is Nim's community like? I ask because I first learned about Nim a few weeks ago when some people were chatting about it on Slashdot. One comment [http://slashdot.org/comments.pl?sid=6771453&cid=48860921 http://slashdot.org/comments.pl?sid=6771453&cid=48860921] quoted from that day's Nim irc logs and well it was a little disturbing. There was a lot of insulting and name calling going on and it didn't leave a good impression on me. I don't want to judge the entire Nim community of course but I was taken aback by those many very negative quotations. I don't think I've ever seen that kind of animosity in the Rust irc channels I mean.

jwecker 12y ago
In my experience it's very responsive and rational. It benefits as a language from being opinionated which is sure to ruffle feathers from time-to-time. Obviously not as big of a community as some others, but that hasn't been an issue for us. I've seen heated flamewars about important issues rarely, about non-important/emotional issues only very rarely and only in IRC (where the current official policy is "we're a new language so don't kick someone out unless absolutely necessary"). More often with Nim you'll see the occasional "wtf- who implemented this? it needs to change to ---". To be honest, IRC isn't the best place to judge a "community"- trolls and good people venting have disproportionate voice there. And to be honest, if that exchange referenced was disturbing... just hope you never have to be involved in a decision with the Linux kernel team or (the most abrasive example I have first-hand knowledge of) the Apache development team 10 years ago ;-) Notice there's only one comment there from Araq and it's trying to de-escalate things. If you were to pop onto IRC and ask something technical or philosophical that wanted a rational response Araq or many of the others not represented in that slashdot comment will most likely answer very politely and rationally within a minute or so (I think he's in Germany though? so timing may be an issue). I think a better "feel" for a community can be gauged by the tone and quality of blog entries coming out and threads in github issues / pull-requests than IRC snippets. That and the fact that if you decide to use Nim based on its technical merits then you _are_ the community- and at this early stage you can easily influence the tenor of discussions and decision-making for good if you choose.
- 12y ago

bhouston 12y ago

An idividual drawn to novel immature languages switches their interest as language matures.

lxc 12y ago

Nim is the most fun language I have tried. I feel way more productive in it :)

Mikeb85 12y ago

Having played with both Nim and Rust, I also prefer Nim. Basically Rust is a slightly more pleasant C++, but still huge, complicated, things break all the time, and there's no IDE support to help you make sense of anything. It's probably more robust, maybe faster as things get big, but I haven't got there yet. Nim is as easy to write as Python, the toolchain is very easy to set up, creating Nim interfaces (with documentation) to your favourite C or C++ library is dirt simple (thanks to tools that come with the compiler), and the language is shockingly fast. Right now, it's just so much easier to get things done with Nim. Reminds me of Coffee-Script - because it compiles to another language, you get access to a million libraries and platforms for free.

kevin_thibedeau 12y ago
It's a shame that it doesn't have the mindshare: 27 nim/nimrod questions on SO, 1548 rust. Still not "notable" enough for a Wikipedia entry. I can see nim getting stuck lingering on the margin like Objective-C did before OSX.
- Mikeb85 12y ago
  It's possible. I personally just hope that Araq and others keep working on it. Right now it's quite easy to use without a lot of libraries written in Nim, because of interoperability. Besides, I see Nim more as a 'secret weapon' sort of language, or something that individual programmers use. Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it.
  - pcwalton 12y ago
    > Besides, I see Nim more as a 'secret weapon' sort of language, or something that individual programmers use. Rust is more of a 'big idea' language, so it makes sense a corporation is pushing it. I don't think that "big idea" languages [1] are necessarily the provenance of corporations/committees as opposed to individuals. If anything, the opposite tends to be true, as large languages such as C++ and C# have tended to grow to encompass more and more features over time as their feature sets expand to accommodate more and more stakeholders. Rust in particular started out as an individual project, with a set of design constraints—those of low-level memory-safe systems programming—that have remained unchanged throughout its lifetime. [1] I'm not really a fan of that term anyway, as "big ideas" are just design constraints, things that all languages have. Rust just happens to have a unique (among industry languages, save maybe ATS) set of them.

thiht 12y ago

Maybe it'll be renamed "Nimix", that's a great name!