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

    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

I presume the printf was just to show Nimrod's easy C interop.

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.

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

We also already have a pretty functional package manager (https://github.com/nimrod-code/babel) and many packages already make use of it: http://nimrod-lang.org/lib.html#babel

I see the Babel doco has now been changed (10 hrs ago - any relation to this HN post?) to say I can run Babel against Nimrod 0.9.4 stable instead of needing to build Nimrod from source. This is great news, I was put off by the language's package manager not working against the stable release version. I look forward to giving this a try.

It's great news indeed. It seems I underestimated how many people will be having trouble building babel due to this. Next time I will do my best to make sure that it works with the latest Nimrod release.

I will say building Nimrod from source is quite literally the easiest language that I've compiled before, aside from Node.js! Super easy :)

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.

You're missing 4) piggybacking on existing ecosystems. E.g. Scala, Clojure, F#.

In Nimrod it's easy to piggyback on C, which has the most extensive ecosystem of all languages.

But C's ecosystem is so extensive that everybody can piggyback on it (with varying levels of ceremony).

See CPython, Haskell, C++....

This might already exist, but if Nimrod could piggy back on Javascript (Node), Python and Ruby for libraries this would be huge. Native glue.

This is what Perl6 with Parrot VM aim for.

http://en.wikipedia.org/wiki/Parrot_virtual_machine

I don't think that we can really consider Perl 6 and Parrot to be anything but abysmal failures at this point. The people developing and advocating for them have had many years now to product something that's even minimally usable, and we just haven't seen that happen.

Writing traditional compilers and interpreters, or emitting C, or targeting LLVM have all proven to be good ways of getting production-grade programming language implementations created and usable quickly. Messing around with Parrot has never resulted in anything useful.

That was the goal, but Parrot failed to meet that goal and P6 is years away from being usable.

How about Perl, Ruby and C?

pg said that for a language to become popular, it has to be the scripting language of something popular. That's the category where the three languages I mentioned are falling.

So the answer is simple: one has to build something really nice in Nimrod and use Nimrod as the extension language of that thing. Maybe the embedded world would be a nice field from Nimrod due to having nice interop with C? (I haven't used Nimrod in my life yet, although I am tempted because it looks very easy).

Perl is a (3) as it was the scripting language on *Nix, and CGI was pretty crucial in the early web.

Ruby I guess is a (3): Rails is a killer app.

C, well, it's the a major accomplishment of human civilization and has held up for half a century. I'd call that idiosyncratic.

I feel like Lua is used pretty broadly for UI scripting in the games ecosystem (addons, plugins, etc) but I don't see it used really anywhere else aside from maybe IRC chatbots. Being the scripting language for something popular is maybe a necessary but probably not sufficient condition.

C had AT&T and was UNIX system programming language.

As UNIX spread into the industry, so did C.

All languages required by OS vendors as the official ones to target their OS, succeed in the market if the OS succeeds.

True, Objective-C comes into mind.

I think it's only the first two. Javascript happened because of Netscape (1).

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

OCaml?

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.

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.

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.

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)

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

Three reasons: dependent typing (limited support, but enough to represent statically sized vectors), powerful macro system (functions doesn't work to well as an abstraction in HDL.. this allows us to create new kinds of abstractions, like state-machines and pipelines), and generics/type classes.

The only other language I know that has similar amount of power is Idris(but in a very different way). But Nimrod has another advantage: friendly syntax and semantics. HDL programmers are not generally good at programming, so I don't think Haskell or Idri based languages will catch on.

I worked on a HDL based in Haskell as an undergraduate project[1], and I'm about to start a PhD exploring the design of HDLs.

>dependent typing

I definitely agree with this. When you're writing a program to generate code, the distinction between compile time and runtime is essentially meaningless, so the boundary between types and values in Haskell ends up being a huge hassle for no good reason. It's also hard to explain the difference between numeric values and numeric types, when there doesn't need to be one in the first place.

I didn't realise Nimrod had this feature, so I might need to take another look at it.

>functions doesn't work to well as an abstraction in HDL

I'm not sure why you'd say that? Functions work great for abstracting chunks of combinational logic. Arguably one would prefer a more constrained abstraction though.

> friendly syntax and semantics ... I don't think Haskell or Idri based languages will catch on.

Bluespec took the approach of modifying Haskell syntax to look like Verilog. It's mostly quite effective, but I think they went slightly too far in throwing out some useful syntax features. Most notably, there are no lambda expressions in Bluespec, even though it could support them trivially.

>HDL programmers are not generally good at programming

I think this is a chicken and egg problem. HDLs suck, so there's not really any good practice to learn. Also competent programmers who can see the deficiencies tend to avoid the field.

I'm working with Bluespec in a team of mixed EE and CS backgrounds, and the EEs are learning much better programming practices as a result.

[1] https://github.com/aninhumer/mantle

> I didn't realise Nimrod had this feature, so I might need to take another look at it.

Yeah, it has it to a certain extent. But it's a minefield at the moment, and will never be as good as Idris for instance. But I'm sure it will good enough for bit vectors.

> I'm not sure why you'd say that? ...

You're right, I was thinking procedures, but wrote functions. A pure function is of course an excellent abstraction of combinatorial logic. A procedure could potential abstract sequential logic as well, with some restrictions/modifications.. but you really want other abstractions.

> Bluespec took the approach of modifying Haskell syntax to look like Verilog.

I'm very suspicious of this approach. If you expect Verilog but get something quite different, it could cause frustration. But I haven't tried Bluespec, so I shouldn't criticize too much. I suppose it's the only way they had a hope of getting more adoption.

Why does it seems better than D for you?