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.
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.