Nim Programming Language v0.16.0 released

Nim is such an odd combination of "amazing" and "huh, that's just weird".

There's a powerful theme — C-like performance with an expressive syntax and automatic memory management — that's undercut by a range of somewhat scatterbrained, idiosynchratic features.

Nim's feature set is ambitious, and it really feels like Nim's authors decided to go "breadth first" rather than "depth first", implementing everything but the kitchen without considering that some more complicated ideas could be deferred until the core language was mature; Nim would have benefited from a more conservative, agile, minimalist approach. At least it would have allowed it to reach 1.0 and more widespread adoption earlier.

Nim also makes some design choices (first-class iterators, the case insensitivity madness, the massive amount of pragmas, OO inheritance, out arguments, etc.) that I wish would have been left on the drawing board to mature.

A casual skim through the top of the commit history indicates that Araq (Andreas Rumpf) is still doing almost all of the development. That's a red flag — being responsible for a complex language, compiler, standard library and documentation is a lot of work. (And it's of course a dangerous bus factor.)

I also think it's a mistake to charge for a book at such an early stage when the quality of the official documentation is less than stellar. dom96 is Nim's most active evangelist on HN; if he wants Nim's adoption to take off, making the book available for free should, strategically, be a no-brainer.

That said, it's not all negative. If evaluated purely on technical merits, Nim is one of the most promising languages currently in development, and it's one of the languages I intend to use this year for various smaller, experimental projects.

Nim is really cool. I tried it out for a few weeks last year.

It's biggest problem is the lack of engaged contributers (really only 2 or 3), leading to many bugs ( you can never really trust the compiler), little documentation, and a very messy standard library.

Creating a language is really hard work. Nim is impressive considering how many people work in it.

But in it's current state you can really only use it for "just for fun" projects.

>>> Sometimes this stems from the quality of the documentation.. >>> I do appreciate Nim, and bought Dom's book...

I've said similar elsewhere.

The existing documentation isn't welcoming to those new to Nim. I've read the freebie first chapter of Dom's book and it seemed very promising and I wanted to read more. However $40 for an ebook is ridiculous. I can't afford to make that kind of outlay just to see whether or not an obscure language with very little traction is worth pursuing.

I think the best solution would be for the Nim foundation to use some of that bug bounty money to buy the rights to make Dom's book freely available on The official site.

Nim is not backed by a large company and does not have a marketing campaign promoting it.

It shouldn't surprise that the community is small. Please join and contribute and the language will grow.

This is my impression as well. I'd happily replace Python with it for everything if not for the library issue.

It's hard to really trust it, though, when you've got a few semi maintained and used libraries for any given domain. It's not just the lack of libraries that's frustrating (wrapping C isn't hard), but like you said, there's a point where there's too few uers to find obscure things on Google.

When you say C speeds do you mean absolutely C-like or just a lot faster than Perl/Python/Ruby? Would e.g. OCaml work?

Sorry about that. Have the changes which break your code been documented in the changelog? If not please report them[0], if this is a regression then it should be fixed quickly.

0 - https://github.com/nim-lang/Nim/issues/new

Sorry people for the missing punctuation marks and paragraphs. It looks like there is a bug in Hackers News that does not allow me to edit my post. Tried different browsers even. Update: It seems I am able to edit this one

It took me a moment to parse, but that snippet is actually pretty straight-forward when you know that Nim compiles down to C (or C++).

  type Vector* {.importcpp: "std::vector", header: "<vector>".}[T] = object

This obviously creates a type "Vector" whose underlying implementation is C++'s "std::vector". (I don't know how writeable it is, but it is* readable.)

  template `[]=`*[T](v: var Vector[T], key: int, val: T)

Function declaration syntax for operator overloads is hard to make readable (as in: familiar). In fact, this is about as readable as it can get (although I'm confused by the "*[T]").

  = {.emit: [v, "[", key, "] = ", val, ";"].}

As I said, when you know that the compiler generates C code, this makes a lot of sense. It's a compiler instruction to compose a string of C code.

Well, the example you are looking at is very complex, but also you are very unlikely to run into it early! For better examples, look at the homepage: you will see something much more approachable.

The reason this snippet is complex is that:

1. It deals with the Foreign Function Interface

2. It deals with the FFI with respect to C++, which is much more complex than the one towards C, essentially because C++ itself is complex

3. It uses a particular construct (emit) that is only needed when the standard FFI is not enough

So the example is really a showcase of a particularly complex case that you will likely not encounter, unless you start wrapping C++ libraries (which is not an easy task, unlike the C ones)

To be fair, this is library FFI code so this is actually for interfacing with C++ rather than 'native' Nim. Probably not something you'd encounter unless you're making a library wrapper.

And if you are doing that, worth mentioning too that Nim has a utility c2nim that automatically translates headers for FFI access.

The first line imports the C++ std::vector type and allows you to use it in Nim. To me that seems pretty good as a one liner to import a complex type from another language.

The second line is using a template to wrap the FFI call so you can use indexing operations and generic variables with the vector.

The `[]=` is describing how to write to std::vector in nim using indexing, eg; "myVec[5]=123"

That example is complicated because it interfaces with C++ and defines a macro. Most Nim code looks nothing like that.

> I don't think Nim and many other ML-inspired languages

I don't think Nim is particularly ML-inspired. Nim's main point of influence is Turbo Pascal/Delphi and their deratives, which used to be obvious from all the "T" prefixes (TObject and so on, now largely or entirely gone from the language). Nim has things like ranges and enums, both of which come directly from Pascal.

Macros implemented with ... string interpolation? This looks like a suboptimal idea.

Edit: I spoke too soon. This looks like code generation, and I guess that you ultimately have to do stringy things at some point. But couldn't there be some kind of type-safe mechanism for this?

Nim is ML-inspired? How so?

Anyways, it looks like this is a code emitting example? I'm guessing the average user would never use that feature. I don't now nim but this is just an assumption. So I think we can let this one pass.