
Nim (formerly Nimrod) 0.10.2 released - def-
http://nim-lang.org/news.html#Z2014-12-29-version-0-10-2-released
======
themartorana
All the hype on HN seems to be towards Rust and Go (with Go having its share
of haters), but Nim sounds particularly interesting as a side-step from Python
that runs faster than both Go and Rust.

Can anyone give me some insight as to why it's not as hyped, if at all? I'm
rather unfamiliar with Nim, and it's seems to have a smaller community, but it
feels like it should be getting all sorts of love considering its speed of
execution.

Thanks in advance for the help!

~~~
klibertp
Actually it's _being hyped_ that's weird. There are literally dozens of very
interesting languages being created and developed _right now_ and I bet you
don't know of any of them. The only - and they are very few in comparison -
languages which are being hyped since very early in their life cycle are the
ones backed by corporations. Both Rust and Go are such languages and that's
basically it.

"Normal" languages live on a different time scale: it takes many years to
gather enough users to even have a chance of generating a bit of hype. For
most languages that moment never comes: they are good, solid languages with
_decades_ of development behind them and completely obscure and unknown.
Others become well-known in certain areas while still being unfamiliar for the
"general public".

Take a look at Haxe, Opa, Elixir, Cobra or Io for example. They are all very
interesting (each for its own reasons), mature and productive - and completely
unknown. Out of those only Elixir gets mentioned here sometimes.

Anyway, a choice of language should never be based on "hype" alone. Of course,
language popularity is an important factor, but most often limiting yourself
to popular languages is a case of premature optimization: it's quite likely
that in your project the language popularity won't make a difference
(especially in small/short-lived projects) and that "raw" language features
are more important than hype. (Of course that's not always the case: bigger or
long-lived projects benefit from language popularity very much, for example by
having easier time finding replacements for developers who went away and so
on)

~~~
noselasd
I'll add [http://pike.lysator.liu.se/](http://pike.lysator.liu.se/) to that
list of "unknown" languages - It's my go-to language for doing simple
prototyping.

~~~
klibertp
Right, those were just examples, there are many (many!) more interesting
languages.

Pike is a bit of a special case due to its history though. I first learned it
in the 90ties, when I joined an effort to port some MUD from LPC - Pike's
predecessor - to Pike. At the time both LPC and Pike looked very weird to me,
coming from mostly static, compiled languages like C and Pascal. A "mixed"
datatype (like void* in C) with type predicates was something new to me,
built-in mappings and other high-level datatypes were too. I don't remember
the details, but I think both Pike and LPC had an unusual object system,
closer to prototype-oriented languages like Self, JS, Io or Lua than to
"normal" class-based ones (but I may be wrong on this). Anyway, it's another
good example of solid and mature but unpopular (to the point of obscurity)
languages.

------
def-
The release is happening today, so I posted a bit early. Some parts, like the
binaries, are not online yet.

There are tutorials for newcomers: [http://nim-lang.org/tut1.html](http://nim-
lang.org/tut1.html) [https://nim-by-example.github.io/](https://nim-by-
example.github.io/)

Edit: Fixed tutorial link

~~~
commentzorro
First, congratulations on the new version. Been playing since 0.9.2 and I hope
to try this latest version too.

But, please make a zipped portable version available for Windows. You don't
have to include a binary version of Nim (although that would be nice) but do
put the required MinGW pieces off a subdirectory under Nim as was done with
earlier releases. This allows unzipping to a thumb drive, xcopy installs, and
using Nim anywhere without having to permanently install on specific systems.
Also, it makes things really easy for a quick demo when showing someone else
Nim on their machine.

(FWIW: The sad state of Windows is that almost every installer out there,
MinGW included, means crapping in your system to some extent and never knowing
what went on nor being able to removed all traces of what was installed. With
each installed application you have to make a conscious decision whether it's
worth the unpredictable OS pollution to install the application on a
particular machine ... because you know with each install that your headed to
that inevitable last one where you have to wipe the entire OS and start over.)

~~~
gfasdgsfd
It looks like mingw provides a non-installer version of the binaries, although
it is (unintentionally) well hidden in the web.
[http://sourceforge.net/projects/mingw-w64/files/Toolchains%2...](http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-
builds/4.9.2/threads-posix/seh/x86_64-4.9.2-release-posix-seh-
rt_v3-rev1.7z/download)

~~~
commentzorro
I see that, thanks. It's a zipped dump of all pieces for all OSes. If you're a
Nim dev, please don't let this dissuade you from eventually releasing a
portable "ready to go" version of Nim for Windows.

I know myself and my compatriots bail at any language that forces Cygwin or
MinGW and has its own installer on top of that. I'll never get to try OCaml,
Haskell, Kitten [which looks really interesting but relies on Haskell], and a
number of other new languages just because of the install burden.

IMO, if trial and adoption are your goals then as little friction as possible
to get to "hello world" is a good route. (And an unzip to the directory of
your choice then a double click on "Test_Hello_World.bat" are about as good as
you could get.)

~~~
vosper
It's not the same thing at all, but could you use Virtualbox to run a Linux VM
on Windows, and play around with languages in that?

------
logicchains
Something I find quite interesting about Nim is write tracking: [http://nim-
lang.org/blog/writetracking.html](http://nim-
lang.org/blog/writetracking.html). It uses the language's effect system, and
allows not only specifying for instance that a function is referentially
transparent, but also specifying how an impure function accesses or modifies
global state.

An example from the above link:

    
    
        var gId = 0
    
        proc genId(): natural {.writes: [gId].} =
          gId += 1
          return gId
    

To quote the article: "Here the effect systems shows its strength: Imagine
there was a genId2 that writes to some other global variable; then genId and
genId2 can be executed in parallel even though they are not free of side
effects!"

The effect system can also be used for exception tracking, specifying what
kind of exceptions are function may throw. It can moreover be extended to work
with user-defined effects.

~~~
vanderZwan
Out of curiosity: why is it hard for compilers to keep track of this
automatically? At least, my gut feeling says that if it had been easy to do,
this would be a solved design problem in newly developed languages by now - at
least the statically compiled ones like Nim.

~~~
uhno
For simple cases (such as the example in the GP comment) a compiler _can_
easily infer those annotations. Complications are introduced in languages
which allow aliasing. Precise alias analysis has been shown to be NP-hard [1]
(as are many other compiler problems), and thus in general compilers must make
very pessimistic assumptions to avoid making incorrect optimizations, such as
allowing two functions to execute in parallel.

Other issues crop up due to the open-world assumption. This is especially true
in the presence of separate compilation when trying to reason about global
behavior. Example: does function f() in file f.c modify global variable g in
file g.c? The compiler may not be able to prove that one way or another at
compile-time (consider if file f.c was already compiled to object code f.o,
and only g.c was being recompiled), and so it must assume that f() _may_
modify g. This particular example can be solved with link-time optimization,
but you get the idea of how complicated the real world can get.

[1] Horwitz, "Precise flow-insensitive may-alias analysis is NP-hard," TOPLAS
1997.

------
audunw
Nim is very exciting to me. For a long time I've wanted to develop a viable
HDL as an internal DSL in a modern imperative compiled language. Until I found
Nim I couldn't find anything beyond C++ that would work (Julia might actually,
I haven't tried yet), but Nim is just absolutely perfect. The custom
operators, static params (a weak form of dependent typing), and the macros in
particular makes Nim a perfect match. It also helps that the compiler is
itself written in Nim and pretty easy to work with. It's exciting when a
language allows you to solve a whole new problem that was just not feasible
before.

------
fithisux
Hopefully one day the freepascal backend gets updated. There is a lot of
Pascal/Delphi code out there that can benefit (rewritten and call legacy
pascal) from Nim's improvements.

~~~
dom96
Perhaps that day will come. This project was recently started
[https://github.com/Araq/nim2pas](https://github.com/Araq/nim2pas)

------
JasonFruit
So far, Nim has passed the most basic test for me: it installs according to
instructions and compiles its own example code. I'm always baffled by the
number of language releases that don't reliably do that.

Nim looks like a worthwhile language, and I'm looking forward to learning it.

~~~
sanxiyn
Good for you! When I tried the test last week, the installation instruction
was outdated, so that became my first contribution to Nim. :) I suspect most
of your baffling cases are simply the case of outdated documentation.

~~~
JasonFruit
Right — and that's what baffles me. If you want people to adopt your language,
you certainly want to have your documentation of the very first step be
complete and up-to-date. Thank you for making sure that is the case with Nim.

------
ldlework
As a long time Python programmer who has struggled to cross the gap from
dynamic scripting languages to modern statically typed languages Nim is by far
the most frictionless language I have tried. Before I found Nim I longed for a
language like C# where the generics "just work" and overall the language just
feels like it designed at-once rather than piecemeal overtime. Everything just
seem really "nice" in C# and I am able to transfer my Python experience over
to it. But being locked up to .NET/Mono I never really used it outside of
Unity3D.

I tried Golang, because it was sold to me as something I would love since I am
a long time Python developer. I strongly dislike Golang. It doesn't have much
in the way of letting me model my programs like I am used to. I am told
"that's wrong, do it the Go way". This is too much friction. Once I am done
thinking how to solve my problem algorithmically, I do not want to then figure
out how to rethink my algorithm just for the sake of the maintainer's of
Golang.

I tried Rust. I think Rust is beautiful (mostly). However, Rust has a far too
fundamentalist view on memory safety. And that's not to downplay the
importance of memory safety. But there's just too much friction. I want to sit
down an implement my algorithm. I don't want to stop and spend just as much
time thinking about the particulars that Rust demands.

When I found Nim I almost couldn't believe it. The core language was simple,
clean and immediately absorbable. I was able to start writing basic Nim
programs after just perusing the language docs for a few minutes while the
compiler compiled. I read that Nim had powerful meta-programming facilities
and this started to turn me off. I had heard that macros were generally a
negative force in the world but only knew them from Lisp. Then I learned that
Nim's macros are just functions that take and AST tree, perform modifications
to that AST and return an AST tree. Wow that's pretty simple. Oh hey the
generics "just work" like in C#. Woah, Nim even supports inheritance!

Nim is definitely the next language for me. In thinking about it, I find that
I agree with one of Jonathon Blow's sentiments that we have been seeing a
number of new up and coming languages but they are all Big Idea languages. Big
Idea languages who's ideas have yet to be vetted and proved out over the
course of a decade or two. They all incur too much _friction_.

Nim seems like a competent, low-level systems language with a helpful
repertoire of well-implemented modern tunings to features that are all mostly
established in the field. It doesn't try to revolutionize systems languages.
It tries to bring us a modern refinement by bringing us a highly performant
yet relentlessly productive take on what has already been shown to work.

Please don't be offended if you see me around evangelizing its existence.

~~~
codygman
As I've said before: for me Nim seems to be everything I had wished Go was.

------
Koziolek
LOL... net-filters in my job mark this site as porn...

~~~
irishcoffee
I don't know why you got downvoted, same thing happened to me.

~~~
dom96
Perhaps if he didn't start his comment with "LOL" it wouldn't have been
downvoted. That said, somebody on IRC mentioned that the website is blocked on
Norwegian train's wifi so perhaps this problem is widespread. Any ideas where
these blocking services get their black lists?

~~~
irishcoffee
At my location, it looks like this is the service:

[http://sitereview.bluecoat.com/sitereview.jsp?url=http://nim...](http://sitereview.bluecoat.com/sitereview.jsp?url=http://nim-
lang.org/news.html)

~~~
dom96
Thank you. I submitted a request to review it again. Might help if you do the
same.

Edit: They reclassified it, should be unblocked now.

------
emmanueloga_
Is the JavaScript back-end receiving any updates? Last time I looked at it it
_looked like_ it was lagging behind (emphasis in "looked like", I did not
spend too much time with it).

------
copx
>The unpopular "T" and "P" prefixes on types have been deprecated

I really like that change. Those always looked so archaic to me.

------
bsaul
Anyone knows what kind of project would nim be a good choice for at the moment
? I mean both the language feature as well as available libs. I think i've
read somewhere that web server coding isn't a target yet (at least regarding
websockets use, which was my primary concern at the time i looked).

~~~
Symmetry
Well, I'm going to be starting on a project involving Arduino and pretty LEDs
soon. Being able to do do stuff like

    
    
      when version == A
        const numLeds = 10
        type LedArray = array[LedState, numLeds]
    

And then have the number of Leds and the size of the array being passed around
typechecked and having all of this done _at compile time_ seems really
interesting and useful. And it seems easy to just allocate everything
statically or on the stack and then turn off the garbage collector.

~~~
dom96
Please announce it on the forum once you get it working. I am considering
buying an Arduino and seeing this in Nim would certainly push me to buy it!

------
waterlesscloud
Why did they change the name?

~~~
bane
Nimrod is a terrible name for a language. In North America it's synonymous
with "idiot".

~~~
kachnuv_ocasek
Git (albeit not a language) has a similar meaning in the UK.

~~~
Amezarak
Even in the US, "git" means "idiot." It was my understanding Linus called Git
for the same reason Mercurial is called Mercurial: as an unflattering
reference to Larry McVoy, who was involved in the Linux/Bitkeeper mess. While
typing this though, I discovered that Linux apparently denies this and says
it's self-reference. ("I'm an egotistical bastard, and I name all my projects
after myself. First 'Linux', now 'Git'".)

Nimrod is actually a little interesting. Until the 1980s, Nimrod was just a
Biblical figure, a powerful king/great hunter figure. Possibly because it was
used in an ironic sense for bad hunters (perhaps beginning with Elmer Fudd),
it came to mean the opposite of its original sense and generalized to "idiot."

[http://www.etymonline.com/index.php?term=Nimrod](http://www.etymonline.com/index.php?term=Nimrod)

EDIT: Sorry about that...I accidentally said Perforce instead of BitKeeper.
Perforce on the brain. :) Thanks nocman.

~~~
nocman
I'm assuming you meant to say the "Linux/BitKeeper" mess. McVoy is the
BitKeeper guy.

------
infinite8s
Can someone give a succinct description of the difference between Nim and
Rust?

~~~
wbhart
Nim has the feel of a compiled Python (with many additional features that
Python is lacking). It is garbage collected, is designed to look as
pseudocode'ish as possible.

Rust is designed for systems projects where GC is not a good idea, such as web
browsers, or kernels, etc. One of its core design philosophies is to manage
memory safely and efficiently.

~~~
dom96
To add to that:

While Nim is garbage collected primarily it can also be used without a GC.
However, the many scenarios where going GC-less may be beneficial such as
games, web browsers, or kernels where the application cannot afford any pauses
during runtime is alleviated by the real-time aspect of Nim's GC which allows
you to specify exactly when and for how long you would like it to run
([http://nim-lang.org/gc.html](http://nim-lang.org/gc.html)).

In this sense Nim is betting on you using the GC for those applications
whereas Rust is betting on not using a GC and providing you with tools to
manage your memory manually more safely.

------
ebbv
Maybe it's just me but I find this language pretty ugly. And regardless of any
technical advantages it may offer, that's enough reason to not use it. There's
too many languages out there to come out with a new one where the code isn't
clean and nice.

~~~
vbit
Care to give an example of a language you find beautiful?

~~~
ebbv
First, I have never and probably would never use the word "beautiful" to
describe any code. I purposefully chose "clean and nice" in my last comment.

As far as the new crop of languages go, I think Rust and Go both offer better
refinements of older languages than Nim does. If you're going to come out with
a new language, the syntax of it should be cleaner and easier to read than
what you are replacing (in this case, seemingly C/C++/Java) or there's not
much point.

But ultimately this is personal preference, which is why I worded my comment
that way. Instead of people simply disagreeing they have so far down voted me
to -3 and counting. HN is overrun with a groupthink mob lately. I have tested
this on a number of occasions posting comments that I knew were pandering to
the mob, and today posting one I thought probably would go against the grain
and the results are totally predictable. It's very sad.

~~~
klibertp
I downvoted you because what you say is both wrong and harmful.

This:

> I find this language pretty ugly. And [...] that's enough reason to not use
> it.

is the worst possible way of choosing a language to use. It's simply stupid to
dismiss languages which may suit your current problem on the grounds of
aesthetics. I can't imagine a single situation where "disregarding technical
advantages" of a language would be even remotely related to the right thing to
do.

And this:

> syntax of it should be cleaner and easier to read than what you are
> replacing

is another pile of misconceptions: no, designing your syntax by comparison to
other languages instead of designing it to fit your semantics is NOT a good
idea; there of course IS a point in creating languages even if syntax is not
"better" in any way (because semantics matter too) and no, you should NOT try
to make your syntax "easy to read" but rather simple and consistent, which
will _make_ it easy to read without you even trying. At least "easy to read"
to those programmers who are able to work with more than one syntax flavour;
the rest will have a hard time reading anything anyway, so there's not much
you can do about them.

I made learning all the languages I can a hobby of mine quite a few years ago
and I since learned many very, very different syntaxes: look at Prolog, Forth,
Scheme and J for the most basic examples. And what I learned is that they all
work and work well, despite not being "clean and easy to read" for people who
don't know them. It's normal; what's wrong however is trying to make your
ignorance into some kind of generally applicable law and judging languages
based on it instead of first learning a bit about them.

Now, I'm sorry for being rude, and a little ranty, but I found your suggestion
that I'm a part of "groupthink mob" rather offensive.

