4 ms·

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 rea

• moe 12y ago
  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.
  • twic 12y ago
    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?
    • wtf_is_up 12y ago
      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.
      • twic 12y ago
        Cross-compilation looks pretty simple in Nim: http://nim-lang.org/nimc.html#cross-compilation http://nim-lang.org/nimc.html#cross-compilation 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.
        • steveklabnik 12y ago
          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.
          • __david__ 12y ago
            Isn't that an issue with every compiled language? I remember always having to cross-compile newlib when I set cross-compiled gcc environments.
            • steveklabnik 12y ago
              It's true, but you can make this easier or harder, depending. We don't make it particularly easy. It's a mater of polish.
            • Matthias247 12y ago
              For Go you don't. I found it quite awesome when I could cross-compile something for my raspberry-pi from a Windows PC.