I find it amazing (for good) that Nim, a language that was made in obscurity by a handful developers managed to be compared to a high visibility language backed by many organizations and people.
Rust is trying to do something far more complicated. Memory-safety enforced by the compiler is a big deal, but it remains to be seen if it's practical. I am really looking forward if rust can make it work, zero-cost memory-safety would really be something amazing to have in a language.
Nim seems to be a nice, low-level, gc-ed and practical language. It doesn't do anything radical, it's pretty small and it does what's already there right. It could become big.
This kinda reminds of linux vs minix. Doesn't mean it will play out the same way, but still.
Rust feels a bit difficult to get into right now, but if they smooth over the impractical bits, it could become the systems language in 10 years. Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
Hell yes!
Nim really looks like it might have the potential to become the "faster Ruby" (or faster Python) that many of us are waiting for.
For all the progress in academic (Rust, Haskell) and special purpose (Go, Dart) languages, a new iteration on the "general purpose workhorse" is more than overdue.
I hadn't made this connection before, but now i see it put like this, i'm interested in Nim.
The only language to have entered this "faster, statically typed, and generally less surprising Ruby" niche so far is Go. Other languages which are faster, safer, and saner than either Ruby or Go come with various showstopping problem: Java has too much baggage, Scala and Rust are too difficult, Clojure is too scary-looking, etc. Go, despite being fairly mediocre, it combines some concrete advantages over Ruby with a very low barrier to entry.
Nim, though, looks like it should do this even better. It apparently has the same straightforwardness as Go, similar performance, but with even less verbosity, a more powerful (but not scary!) type system, and comprehensively more modern facilities.
I don't know if Nim has some equivalent to Goroutines, but i think Goroutines are overblown anyway. Go isn't really all that great for concurrency, and the people i know who are using Go aren't using it for concurrency.
I believe that the decisive fronts will be mindshare and tooling.
I have no idea how Nim can build mindshare on the same scale as Go; i don't know if the current level of grassroots interest can grow, or if it needs a corporate backer like Google, a celebrity figurehead like Rob Pike, or some technical hook like Goroutines. Perhaps someone will build something amazing in it, and become a poster child.
Tooling is clearer. Go has some simple, well-liked tooling in the box: go fmt for formatting, go vet for linting, go fix for version upgrades, and go get for dependency management. It also has a bit of a weird story around compiling and linking, but it all works in practice. For Nim to overtake Go, it will need an equally good or better story about all these things. Fortunately, this doesn't seem all that hard; the most important area is, IMHO, dependency management and building complex projects, and Go's tools are pretty poor here. go get is simple, but the lack of versioning is a huge hole. Maybe someone should just write a Gradle plugin for Nim?
One thing people never seem to mention is how dead simple it is to cross-compile Go code. For me to consider Nim or Rust, I need to know that I can do something as simple as GOARCH=arm GOOS=linux go build.
Since Nim uses C as an intermediate representation, cross-compilation support should be as good as your C compiler's.
Rust's cross-compilation seems to not be that great at the moment. Although i believe that's because it hasn't been done yet, rather than having been done badly.
Rust's cross-compilation works, but it's not as easy as it could be. One issue is that you need a cross-compiled version of the standard library lying around.
On the other hand, if you run "an unsupported Unix" that implies you are a bit more tech-savvy (and willing to put in the effort) than most when it comes to these issues.
My impression is that Nim was in the right place at the right time and unintentionally piggybacked on the interest surrounding languages such as Rust and Go. This perception may be completely wrong. However, I do remember all these languages started gaining popularity within the span of several months. Before that Nim (then Nimrod) existed, but remained in obscurity.
I do remember a well-timed post on reddit/r/programming about Nimrod (as it was called back then), shortly after Go's release. It contained a lot of "Go is disappointing (to put it mildly), this looks so much better"-comments about the language. The backlash against Go was pretty huge.
I don't remember the guy behind Nim doing much trash-talking, which probably helped as well, especially in the long run.
The problem of Go is the hypocrisy of its community when it comes to the expression problem. Obviously Go isn't expressive at all. Which make it verbose when one tries to write abstractions with it.
A lot of devs just want a fast,type safe,memory safe language,that doesn't need a hungry VM to run but is expressive enough so "scripters" feel at home. Why is it so hard to get a language that does that? IDK .
Exactly my feeling and I also feel that sometimes we underestimate the "ability and efficiency" of small teams. I start to believe that a small core team (not to read few contributors) can have a larger impact than an organization.
certain core systems components are often developed by small teams or individuals even within large organizations. the .net GC was written/maintained by 1 dev for a long time (Patrick Dussud, later Maoni Stephens), the Windows thread scheduler was written and maintained by Dave Cutler over many releases, etc.
some development efforts are just really hard to scale out.
Language maturity takes time. When Go and Rust went public, there were already languages in the very same niche, aiming to be a C++ replacement, and developped in the open.
Go and Rust had the very same self-positioning as C++ replacement, but because of different visions of what C++ is for they are now in largely unrelated niches. It is hard to imagine, for example, that someone would choose Go to rewrite Webkit, or LLVM, or any C++ math/modelling library (for other reason than proving it's possible). Just as an idea of writing website business logic in Rust would make me scratch my head.
While I agree that writing backends in Rust may not be the best, Crates.io uses Rust as a backend for Ember, and it seems to be working out really well. I'm skeptical, but interested to see how it develops.
Then check out Iron.rs and Nickel.rs - web-frameworks in Rust :)
Yes, Rust is more complicated language but sometimes you are ready to pay this price just to get back joy of programming. And at some point in time, bugs in runtime (because of types or memory safety or race conditions) becomes so annoying, that you are ready to be thankful to any tool which can find them on compilation, even with price of more verbose code. "Typing is not a bottleneck".
"Joy" -- I feel like I spend all my time bookkeeping -- which is about the least fun thing imaginable. The guarantees keep me interested, but just barely at this point.
I think lots of programming languages are been created, and the vast majority of them fall into obscurity, but some have nice features and grain a bit of traction, which is what is happening right now with Nim. If you forgive me the comparison, I would say that Nim is to the programming languages what Flappy Birds is to the video games: a successful product built by a talented programmer in a place where lots of people try their own - of course, the analogy is not completely right since the barrier to create a programming language is much, much higher than to create a small video game.
