Nimrod by Example

http://nimrod-by-example.github.io/

by def- • 12 years ago

171 71 12 years ago

nimrod-by-example.github.io

eudox3• 12 years ago

I'm afraid the memory management scheme might cause the Nimrod ecosystem to end up with too many libraries that require GC, and since the building blocks are already using it, why not use it yourself?

Either make it fully manual, or do something like Rust (No small feat). A GC you can switch on and off sounds like a good idea, but programmers don't keep half the promises they make ("It's just an MVP, I'll refactor it to use manual memory later").

charlieflowers• 12 years ago

Still, there are times when GC is fine for a particular application. In those cases, Nimrod is pretty fantastic, especially given its metaprogramming capabilities.

def-6• 12 years ago

Also, the GC can be controlled, so you can set exactly when it is allowed to run, something like this for a game:

  gcDisable()
  while true:
    gameLogic()
    renderFrame()
    gcStep(us = leftTime)
    sleep(restTime)

http://nimrod-lang.org/gc.html

rbehrends2• 12 years ago

I'm afraid the memory management scheme might cause the Nimrod ecosystem to end up with too many libraries that require GC, and since the building blocks are already using it, why not use it yourself?

And what would be the problem with that? The number of application domains where even soft real-time GC is inappropriate is very, very small. And designing freedom from garbage collection into a language (other than the simple option of allowing manual allocation/deallocation) is not cost-free, either, and can weigh down the design, too. You can optimize your language design for having garbage collection or for not having garbage collection, but if you try to do both at once, a language design that specifically favors one or the other will likely beat out the compromise solution for the case it's optimized for.

And yes, that means that Nimrod (or any other language) won't be perfect for everything under the sun. Which is fine: there's nothing wrong with having multiple programming languages, each of which is better suited for a different task.

audunw5• 12 years ago

No, I think Nimrod's approach is absolutely correct.

What I hope will happen is that once Nimrod's effects system matures, the compiler will be able to figure out when it can statically free references when they go out of scope, rather than always using the GC.

Rusts approach, I think, is in the entirely wrong direction. You should only have one kind of reference, but if you use it correctly the compiler should figure out how to free it. You should then be able to make an assertion that a procedure (possibly "main") does not allocate any GC memory, and have the compiler tell you what part of your code violates this constraint.

eudox3• 12 years ago

I agree in that I don't entirely buy Rust's approach, mostly because of the cognitive overhead that it puts on me, but I don't think it's plausible to think future changes to the compiler (Without the introduction of new constraints on the behaviour of pointers) will give us statically-determined deallocation points. If it were possible, it would have been done five years ago and merged into clang!

pcwalton4• 12 years ago

What you describe is called escape analysis, and it's Go's approach (for example). But it falls down in many situations, especially when separate compilation is desired or when you have existential types (e.g. closures). To truly have no GC with safety, you need to replicate something like Rust's machinery.

"If you use it correctly the compiler will figure out how to free it" is extremely handwavy. If you try to formalize exactly what "use it correctly" means, you will likely arrive at something very similar to Rust's system.

rayiner• 12 years ago

Rusts approach, I think, is in the entirely wrong direction. You should only have one kind of reference, but if you use it correctly the compiler should figure out how to free it.

This has been an area of intense research for four or five decades now, and it's probably not going to get better than what we have now, in the general case. In the presence of general recursive data structures, the compiler can't know when each object is going to die. I'm pretty sure you can easily reduce this to the halting problem.

To date, you've had three sorts of solutions: 1) explicit malloc/free; 2) tracing GC or reference counting + various tricks to take advantage of special cases; and 3) putting additional information in the type system to help the compiler infer when objects might become free while preserving memory safety (this is the direction taken by Rust, Cyclone, MLKit, and to an extent C++ too).

tdees404• 12 years ago

Sighs. I wish Nimrod were more popular. It seems like a better version of D. But there can only be so many languages with a fully functioning ecosystem, and I just doubt Nimrod will ever get there. It seems to be a one-man shop at this point (as this demonstrates):

https://github.com/Araq/Nimrod/graphs/contributors

rsaarelm• 12 years ago

This. I'm on the lookout for expressive, statically typed, native code compiling languages for game development. Currently poking around with Rust, since Go seems to pretty much be settled on not doing the custom expressibility thing. Nimrod looks like something I'd really want to like, the game stuff I do doesn't really need Rust's hardcore garbage collection avoidance, but the ecosystem sparsity just scares me off. Meanwhile, Rust has both reasonably heavy institutional support and an impressive swarm of adventurous game developers with a C++ background working on stuff for it. I'm banking on Rust mostly for the potential ecosystem strength in being the only alternative to C++ for a high level of abstraction don't pay for what you don't use language.

def-6• 12 years ago

The standard library is pretty nice though: http://nimrod-lang.org/lib.html

I spent a few days solving Rosetta Code tasks and was surprised how easy most were using the existing libraries: http://rosettacode.org/wiki/Category:Nimrod

tdees404• 12 years ago

There really are only three ways to create a usable language, honestly:

1) Huge institutional support. See: C#, Java, Go.

2) Give it 20 years. See: Python, Haskell.

3) Weird, idiosyncratic factors. See: Javascript, mostly.

So it's hard for me to get excited about these sorts of things.

Edit: fair point, Javascript is really a case of #1, with Netscape as the institution.

stewbrew• 12 years ago

It you're in game development, you might want to take a look at haxe. It seems many users use it successfully for games.

runT1ME• 12 years ago

OCaml?

progman• 12 years ago

I am always amazed how quickly I get things done with Nimrod. It's like writing Python, having the full power of C (see below), and some of the power of Lisp (macros!), and getting the performance of C++. Nimrod actually is what I wanted Python to be.

For instance, I just need to add two lines to import C's printf and fprintf:

proc printf(frmt: CString) {.importc: "printf", nodecl, varargs, tags: [FWriteIO].}

proc fprintf(f: TFile, frmt: CString) {.importc: "fprintf", nodecl, varargs, tags: [FWriteIO].}

Now I can use these C functions seamlessly (even without parentheses):

printf "Hello %s!\n", "world"

fprintf stderr, "Error in line %d\n", $nr

Hello71• 12 years ago

    from ctypes import *
    libc = CDLL("libc.so.6")
    libc.printf("Hello %s!\n", "world")
    from sys import stderr
    libc.fprintf(stderr.fileno(), "Error in line %d\n", nr)

although I don't know why in the world you would want to use printf instead of native string formatting

fuzzythinker• 12 years ago

It is getting there, as can be seen by the Contributions graph in that link. Aside from the fact it's mostly from Araq, the graph looks very healthy and encouraging. I actually just started using it for my next biggest project, after a week or so of looking into haskell, Ocaml, and Lua.

audunw5• 12 years ago

I do think Nimrod will catch on in a little while. It has amazing potential. But things like type classes aren't done yet.

Personally I believe Nimrod will be perfect as a Hardware Description Language. There's a couple of features missing, but they're currently being worked on. This is an area where Nimrod could really shine, and where it could start to gain massive commercial support.

def-6• 12 years ago

At least in the devel branch type classes seem to be working:

  type Comparable = generic x, y
    (x < y) is bool

This creates a Comparable typeclass, which can then be instantiated:

  type Foo = tuple[a, b: int]

  proc `<`(x, y: Foo): bool =
    if    x.a < y.a: true
    elif  x.a > y.a: false
    else: x.b < y.b

  var c: Foo = (12, 13)
  var d: Foo = (14, 15)
  echo c < d # true

And used elsewhere in generic code:

  proc min[T: Comparable](xs: openarray[T]): T =
    assert xs.len > 0
    result = xs[0]
    for x in xs:
      if x < result:
        result = x

  echo min([c,d]) # (a: 12, b: 13)

peaton• 12 years ago

Could you elaborate on why you think it would be a good HDL?

spyder• 12 years ago

Why does it seems better than D for you?

fineline2• 12 years ago

I use NodeJS quite a bit, which has massive ecosystem, but recently (and especially After TJ Hollowaychuk's announcement about moving to Go) I've been taking a fresh look at these new-fangled systems languages, including Go, Rust and Nimrod, plus Apple Swift. If I'm going to tool and skill up in a new systems language, I want not just performance and nice syntax but also reach. Of the three, Nimrod is the only one with a convincing story for running on the main consumer platforms (iOS, Android, Windows), server platforms (Linux, *NIX) and embedded systems - because it compiles to C or Objective C (or JS for that matter!). That strikes me as a neat approach. Whilst there are attempts to get Rust and Go compiling for iOS, they don't seem very advanced.

The small ecosystem is definitely a concern, but could also be an opportunity for a mid-sized IT corp to step into the ring with the big hitters and all their shiny new systems languages by backing this project.

perturbation2• 12 years ago

Anyone know the recommended way to do interop with C and Nimrod? I've been doing Project Euler problems in Nimrod, and wanted to use some library functions from GSL for bignum support, but I couldn't really get c2nim to work with the header files.

I think that I could use the 'importc'/'dynlib' with the compiled library, but there's not a whole lot of documentation on that in the Nimrod manual, and I ended up just doing that problem in C because it was easier (read: I was lazier) to get working.

def-6• 12 years ago

For general C/Nimrod interop see these Rosetta Code tasks:

http://rosettacode.org/wiki/Call_a_foreign-language_function...

http://rosettacode.org/wiki/Call_a_function_in_a_shared_libr...

http://rosettacode.org/wiki/Use_another_language_to_call_a_f...

Making c2nim work with header files can be a bit difficult. The main information is here: http://nimrod-lang.org/c2nim.html

When something throws an error I comment it out and try to see if I can fix it up by hand.

ilaksh• 12 years ago

I never tried the c2nim thing but just used a few compiler directives I think to call C code. It was incredibly easy.

perturbation2• 12 years ago

To the curious - I got this working (thank you def- for the rosetta code examples!). Point of correction - the library I was actually using for bignum support was GMP, not GSL. (I was getting confused because I used functions from GSL for a different problem).

Importing a standard procedure from a C library like GMP actually is pretty easy (use the importc/header pragmas).

Here's what tripped me up:

* Calling variadic functions from Nimrod (just wrote a wrapper)

* Getting to link against gmp (used the passL: "-lgmp" pragma)

* Remembering to free what was allocated by C library functions (can't GC what you didn't allocate) - caught with valgrind

I'll probably push to my github repo, but can post to a pastebin or something if there's interest in a less cookie-cutter example

WaxProlix2• 12 years ago

Is there a list of "X By Example"-style tutorials around? I learn best from these sorts of things and would love a compendium of sorts.

ludwigvan• 12 years ago

Not exactly what you're looking for, but http://learnxinyminutes.com/ is nice.

reirob• 12 years ago

The HN user def- posted a link to the Nimrod section of rosettacode.org: https://news.ycombinator.com/item?id=8048939

gomesnayagam• 12 years ago

I always wanted to go back to C kind of language, let me wait for few more years to pick one Go,Rust,Nimrod...

aikah• 12 years ago

How does Nimrod compares to Go regarding concurreny,does it have some libs or some language onstructs ? thanks, I like how the language looks.

dom963• 12 years ago

Nimrod's concurrency support is still evolving but it already implements a builtin thread pool: http://build.nimrod-lang.org/docs/manual.html#spawn

You may also be interested in the C#-like async await as shown in the following news article: http://nimrod-lang.org/news.html#Z2014-04-21-version-0-9-4-r...

Nimrod by Example

Related Stories