5 ms·
Nimrod is very interesting. As a former Delphi hand, Nimrod looks very much like a modern upgraded version of ObjectPascal, with some heavy influence from Pytho
by lobster_johnson 13y ago
Nimrod is very interesting. As a former Delphi hand, Nimrod looks very much like a modern upgraded version of ObjectPascal, with some heavy influence from Python and possibly Ruby.
The language is actually pretty amazing — it's expressive and flexible (eg., type inference lets you omit types in most places, to the point that much of your code ends up looking something like Python/Ruby/Lua), and it's just amazingly fast, but not at the expense of ease of use. In almost every way, Nimrod is the "speed of C/C++, ease of Ruby" replacement that we have been looking for. Go's performance has been too disappointing, while Rust is a wee bit too complex. Nimrod feels just right.
As I wrote in a different thread, I and a colleague have been looking a little bit at using Nimrod as a game-logic language, as a replacement for Lua. Lua is pretty fast, but Nimrod is considerably faster; I'm personally also not a fan of Lua with its very weak table-based OO and rather idiosynchratic syntax, although I know it gets a lot of love on HN.
What makes Nimrod particularly suited to game development is that it's designed to integrate well with C. Nimrod compiles to C, and the generated C code provides the necessary bindings so that you can easily call Nimrod functions from C without an intermediate translation layer. In other words: If you write your core engine in C, scripting the game with Nimrod is (from what I can tell) as easy as with Lua. Very exciting.
- sergiotapia 13y ago>Go's performance has been too disappointing How so? Everything I've read online has been roses and unicorns in terms of it's speed and build times.
- lobster_johnson 13y agoBuild times are fantastic. Performance is still quite a bit worse than Java, actually. It has its own compiler, and so it doesn't benefit from the huge amount of work put into optimization in GCC and LLVM. Definitely not roses and unicorns.
- burntsushi 13y agoWhat is "quite a bit worse"? Is that 2-3x slower? Or 20-30x slower? It's my understanding that it's the former. And then there's memory consumption...
- lobster_johnson 13y agoThe former.
- MetaCosm 13y agoGo has MULTIPLE compilers, because Go is a language spec, not a compiler. Hence GCCGO (which for example, takes advantage of some of those GCC optimizations) can be used. Additionally, in most benchmarks, Go does fairly well and is young and constantly improving: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ You will also find Nimrod / Jester in those benchmarks, and can compare the performance for yourself.
- lobster_johnson 13y agoPedantry. When people talk about Go, they usually mean the official implementation. gccgo has too many issues (lags behind release, requires gcc recompile, etc.) to be useful to most people.
- MetaCosm 13y agoI disagree. I know most Go shops I have dealt with at least have looked into gccgo. We use gccgo in the wild (for all our image processing components), because it gave us a nice performance boost. With good testing, you can easily do A/B testing using gccgo to see where it makes sense for you in production. We have to dig through 30TB of images -- so the performance benefits we got from gccgo were worth the trivial effort it took to implement.
- barchar 13y agoGo is pretty much competing with java and not C, C++, FORTRAN, and Ada. Nimrod is up there with the best of them. Go is also somewhat designed around reducing build times, nimrod is not. However C and C++ (esp C++) pretty much manage to be designed around increasing build times, so Nimrod is much faster to compile than they are.
- pcwalton 13y agoWhat is too complex about Rust, in your view?
- lobster_johnson 13y agoPointer semantics. The syntax in general bugs me. It's too close to C++ for my taste -- too many braces and brackets and sigils.
- pcwalton 13y agoWell, the pointer and reference distinction is there because you can't do safe memory management without it, without a thread-safe garbage collector which will hinder your ability to reach C/C++ level performance. But yes, if you're fine with the performance tradeoff GC is certainly more convenient. I wouldn't say the syntax is complex because it's close to C++, but it isn't to everyone's taste (and that's fine; lots of people prefer that syntax and there's room for different languages for different folks).
- sanxiyn 13y agoThese days only complaints I here about Rust are pointer semantics and C++-like syntax. Both will not be fixed (design decision). I guess that means Rust achieved some sort of optimality now. :) More likely, probably people hate those two points so much that they forget to mention other problems. Which is a pity. Please tell us about other problems.
- pcwalton 13y agoI think the pointer semantics being unfamiliar is a reasonable complaint. But I think it's what you get from the pointers that makes it appealing: safe, deterministic, GC-free, thread-safe and race-free memory management. I think if the pointers bother you you're really objecting to the "safe, GC-free" space of languages as a whole, not the Rust language itself--as I still haven't seen any approach to memory safety without GC that doesn't use smart pointers and references.