
Consider the Nimrod Programming Language - geetduggal
http://geetduggal.wordpress.com/2014/03/03/consider-nimrod/
======
lobster_johnson
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
>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
Build 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.

~~~
MetaCosm
Go 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
Pedantry. 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
I 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.

------
CyberShadow
Seeing as how both Nimrod and D have invested into metaprogramming (and also
"attempt a speed-elegance unification"), I think a comparison with D would be
interesting. D doesn't have AST manipulation, though; the "parallel for" idiom
is instead accomplished rather mundanely, using a custom iterator
([http://dlang.org/phobos/std_parallelism.html#.TaskPool.paral...](http://dlang.org/phobos/std_parallelism.html#.TaskPool.parallel)).

Another similarity is uniform call syntax (which D calls uniform function call
syntax, UFCS for short).

~~~
barchar
Nimrod is indeed pretty similar to D, although I think it is a bit more
uniform because of the way the object model works. Also "death to mustache
braces"

------
joehillen
What is Scala doing in the same list with Rust, Julia, Nimrod, and C++? You do
realize there is a JVM preventing it from being a systems level language,
right?

Also, you should need no more reason to avoid Scala than this:
[https://www.youtube.com/watch?v=TS1lpKBMkgg](https://www.youtube.com/watch?v=TS1lpKBMkgg)

If you're interested in Scala, learn Haskell. It's faster, its design is re-
enforced with proven mathematical concepts, and it doesn't have the worst
syntax ever.

~~~
pjmlp
> You do realize there is a JVM preventing it from being a systems level
> language, right?

You do realize there are quite a few commercial JVMs that generate native code
AOT like any of the referenced languages, right?

~~~
sixbrx
I presume they still have a largish runtime attached with complicates FFI
especially if callbacks are involved. I've found Java FFI to generally be a
pain.

Also, I think a lot of organizations would never approve using these in
production, too likely that behavior will differ vs Oracle's or the OpenJDK
VM's, the company won't be around in a few years, etc., and the gcj is very
out of date from what I gather.

~~~
pjmlp
I did not mention gcj, it is a dead project since 2009.

I don't know, but I guess enterprises do trust Aicas, Aonix, IBM, Excelsior
and quite a few others.

------
jmgrosen
I think the reason I don't like Nimrod is the same as the reason I don't like
C++(11): it has too many features. Rust's (relative) simplicity and memory
safety make it much more attractive to me.

~~~
barchar
I like nimrod because it has a sane syntax. I can write a function declaration
in one line of nimrod that would be 6 lines of c++. I also like Nimrod's focus
on static dispatch and easy to use generics.

Rust makes me uneasy because the whole lifetime tracking adds a lot of
complexity and I fear it may make some programs harder to write or some
libraries harder to use. Also I think that garbage collection, if fast (which
nimrod's is very much so) is the right way to go in some situations. I don't
actually want to go and spend time freeing a bunch of strings right after I
use them.

~~~
pcwalton
> Also I think that garbage collection, if fast (which nimrod's is very much
> so) is the right way to go in some situations.

Definitely in some situations garbage collection is the right thing. But
Nimrod's garbage collector is not thread safe...

> I don't actually want to go and spend time freeing a bunch of strings right
> after I use them.

That isn't how Rust works. The compiler automatically frees things via RAII.

~~~
barchar
RAII is sorta by definition immediate. They are freed right when they exit
scope, this can be annoying for large tree structures.

Yeah the GC not being thread safe can be annoying. CSP works OK and if you
need more performance a thread safe GC may not be fast enough anyway. If rust
can pull off ownership tracking between threads in an easy-to-use way then I
would be super excited.

~~~
pcwalton
Well, you don't have to free in your destructor eagerly: you could
incrementally release if you wanted to, and still use RAII. But you're right
of course that RAII makes it simplest to eagerly deallocate.

Eager deallocation is usually what you want anyway, because of its cache
effects and because you can just release the memory back to the free list (or
the OS) and forget about it. If you repeatedly allocate and deallocate a
similarly sized block, for example, eager deallocation means that your block
will stay in L1 if it fits.

------
charlieflowers
Nimrod is pretty awesome for metaprogramming. If you can dig around on the
Nimrod website and find docs about the html-producing language (same general
goal as haml), that's a decent quick glimpse into the possibilities.

------
chrismorgan
I must confess I got rather distracted by the number of spaces between
sentences; I found everything from one space to six.

~~~
geetduggal
You have successfully spawned my OCD thread. I have attempted to fix a number
of them, but it's more difficult in Wordpress.com land than I thought it would
be.

------
progman
I have used Nimrod daily for several months now, and I fully agree. It is
actually one of the most productive languages that I have encountered so far.

Perhaps you should add two more things to your feature list:

1.) Native Perl syntax

2.) C imports for seemless use of C functions:

const txt = "x"

const x = 123

printf "%s is %d\n", txt, x // or

printf "%s is %s\n", txt, $x

------
ilaksh
I have used quite a few different languages and systems over the years, from
SQL to C/C++ to OCaml, C#, D and more recently JavaScript and then
CoffeeScript/ToffeeScript. And some others I better not mention. Last few
years I have mostly been enjoying dynamic languages and the fact that I don't
have to declare types.

I have been doing programming mainly with ToffeeScript in Node.js recently. I
was worried that I might find dealing with some types and an actual compiler
for a static language to be burdensome.

With Nimrod I have a syntax that's even cleaner than ToffeeScript and Python,
which includes types inference to make type declarations minimal, and I
actually find it easier to program with the type checking at compile time.
Also my code is being compiled to C and then to native so it is very fast.

And it has very powerful standard library.

So what I have found is that not only does my Nimrod code execute vastly
faster with much less memory than Node.js code, it builds much more quickly,
and it is easier to read and maintain the code. One aspect of this is the fact
that you don't have to use namespace qualifiers when you use module calls.
Initially I was worried about that, since it is such a significant
characteristic of Node.js code and point of pride for some. However, I think
Nimrod has proven that this is the way to go. I can easily create my own DSLs
with modules and extend the base programming system. This is something I tried
to do with CoffeeScript because DSLs are powerful, but it was impossible to do
it elegantly.

I have not yet attempted to learn the metaprogramming features, but from what
I can see, few, if any, other languages with such high performance and clean
syntax can compare with Nimrod in terms of metaprogramming.

I am quite glad that I found out about Nimrod before I got too caught up in Go
or Rust. The syntax is much cleaner than Go, and the performance is better.
The syntax is _much_ much cleaner than Rust, and overall its a much more
practical language.

What I am doing now and plan to continue doing as much as possible, is moving
my web programming into Nimrod code. Basically I am doing this because I need
less memory usage in an agent I am going to install for a service. I briefly
considered using C or something like that, quickly decided to take advantage
of a newer language, started looking at Go, briefly got excited about Rust,
saw Nimrod and fell in love. This is the language that is going to make it
most practical to achieve my goals, as well as allow me to stay engaged by
learning its more in-depth features as time goes on.

The only reason that Nimrod doesn't have instant uptake and popularity is that
people don't evaluate things logically. Most people aren't capable of it, but
even among the ones that are, peer pressure generally takes over. Humans are
herd animals. They follow the crowd. If most people are driving cars that are
four times as large as needed every day to work when they could just sign on
to the internet and save gas, time, and the planet, then most people will do
that, no matter how horrible it is. If most people choose a particular
programming language even though it is inferior, then most other people are
going to do that as well.

But you can still be like the smart guy who was driving the small, efficient,
fast electric vehicle before electric vehicles were cool.

