
Nim Programming Language v0.15.0 released - dom96
http://nim-lang.org/news/2016_09_30_version_0_15_0_released.html?ref=hn
======
dom96
Nim developer here, I'm glad to see so much enthusiasm for Nim. I'm currently
writing a book about it called Nim in Action[1] and would love to know what
you guys think about it. The first chapter is free[2], so even if you don't
intend to buy it you can still take a look at it.

We also have a BountySource campaign[3], so if you would like to support us
please consider making a donation.

Finally, please feel free to AMA!

1 - [https://manning.com/books/nim-in-
action?a_aid=niminaction&a_...](https://manning.com/books/nim-in-
action?a_aid=niminaction&a_bid=78a27e81)

2 - [https://manning.com/books/nim-in-
action?a_aid=niminaction&a_...](https://manning.com/books/nim-in-
action?a_aid=niminaction&a_bid=78a27e81#downloads)

3 -
[https://salt.bountysource.com/teams/nim](https://salt.bountysource.com/teams/nim)

~~~
bjourne
I wonder how Nim's cycle detection work? It is said in the docs that Nim never
scans the whole heap, but I believe in worst cases you have to scan the whole
heap to detect cycles.

Also how does the gc trace variables on the stack? How do you determine if a
value is a pointer to an object or an integer?

~~~
Araq
Good questions. I'm afraid the documentation is seriously out of date about
the GC: It used to implement a variant of "trial deletion" so that "never
scans the whole heap" used to refer to the fact that it doesn't use
traditional mark&sweep, but only scans the subgraph(s) leading to the cycles.
Of course you can always create a "subgraph" that spans the whole heap, so
even for trial deletion it is a dubious claim.

Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC
to collect cycles. Reasons: Trial deletion in practice is much slower.

For all versions of the GC is stack is scanned conservatively as precise stack
scanning is simply too expensive when C is your main target.

~~~
bjourne
That has been my experience too. That all the extra work and logic (cause the
algorithm is complicated) you need for detecting cycles and trial deletion is
so expensive that regular mark&sweep beats it.

But to ask a pointed question, doesn't that mean Nim gets the worst of both
worlds? You have both the overhead of updating reference counts and the
(relatively long) garbage collection pauses. I guess if the programmer codes
in such a way that no cyclic garbage is created it is not a problem because
the gc will never be triggered. But how common is that in practice? Does the
language make it easy to avoid cycles?

~~~
Araq
> But to ask a pointed question, doesn't that mean Nim gets the worst of both
> worlds? You have both the overhead of updating reference counts and the
> (relatively long) garbage collection pauses.

There's a patch of the collector to make the M&S incremental, to avoid pauses
for this step too. Of course, whether a deferred RC'ing GC with incremental
cycle collector works better in practice than a more conventional generational
incremental GC (or just an incremental GC) is an open question. :-)

Nim has garbage collected pointers (ref) and raw pointers (ptr). You can use
'ptr' to break up cycles manually and disable the M&S. I suppose it's very
much comparable to Swift except that Nim's RC overhead is much lower since
it's deferred RC.

------
mastax
> The multisync macro was implemented to enable you to define both synchronous
> and asynchronous IO procedures without having to duplicate a lot of code.

This is great! There are a lot of little things like this in the nim standard
library that make life a lot easier. I should write more nim.

~~~
lmm
That shouldn't need a macro though. With higher-kinded types you can just
write generic code that operates on futures or regular values.

~~~
nnq
That shouldn't need a higher-kinded type though. With macros you can just
write generic code that operates on futures or regular values.

~~~
virtualwhys
> that operates on futures or regular values.

but what is the return type? The multisync example shows separate generated
methods that return `string` and `Future[string]` depending on the method
argument.

If that's the case then blocking and non-blocking operations need to be
treated separately since operations defined on a result of `Future[string]`
are not the same as those available on `string`.

HKTs not only allow for both method argument and return type to be
polymorphic, but also allow one to define the same operations (like map,
flatMap/bind, fold, etc.) on the wrapped type.

------
anta40
I do like Python (my work mostly done in Java, though). A few years ago, I was
looking for a language with Python-like expressiveness, with system
programming capabilities ala C.

Seems like Nim is the answer :)

~~~
borplk
Yes Nim has the reputation of being a Python-like system programming language.

~~~
progman
Not only that. Nim also has benefits like Ada's range types, a sophisticated
macro system, and Perl's native regular expression syntax. It also compiles to
C which makes porting to other platforms easy.

~~~
vram22
>Nim also has benefits like Ada's range types

Are Ada's range types similar to D's, or quite different?

[https://dlang.org/phobos/std_range.html](https://dlang.org/phobos/std_range.html)

The above page links to the one below - the one below is about the concepts,
by Andrei Alexandrescu (who joined Walter Bright in developing D).

[http://www.informit.com/articles/printerfriendly/1407357](http://www.informit.com/articles/printerfriendly/1407357)

~~~
progman
I know Ada not D. Nim's subrange are close to Ada. If you define a type t1 =
range [5..20] and you assign a value of 1 to a variable of type t1 then you
get a compilation or runtime error.

~~~
vram22
Ah, then that is similar to Pascal too, from its early versions, IIRC, not
just Turbo Pascal onwards.

------
qwertyuiop924
I looked at Nim briefly. It seemed cool, but there were some things that I
just heavily disagree with. Forcing a keyword for discard means that there's
an incentive for imperative code not to return a value, whereas I argue that
that should be encouraged. Also, I find the macro system unweildy to use,
especially coming from Lisp.

~~~
agentgt
I have the same problem with almost all new languages including Rust:
everything should be an expression and not a statement.

Even conditional logic constructs (if/else) should be an expression (i.e.
return a value).

The language doesn't even have to be pure or hard core FP to follow this
philosophy.

~~~
nathancahill
I highly agree, especially about the if/else. The more I code, the more I try
to elimante branching. If statements as expressions would be ideal.

~~~
qznc
Most mainstream languages (C, Java, etc) have this. The ternary operator ?:

~~~
35bge57dtjku
That's like farting in the bathtub and calling it a hot tub.

~~~
tigershark
Why? It is an expression, not a statement regardless of your farting nonsense.

~~~
35bge57dtjku
Because they aren't the same thing.

------
sharpercoder
With so many programming languages around looking very similar, and realising
the enourmous tough challenge to get adoption: why do programmers pursue
writing a general purpose language and trying to have it adopted?

~~~
throwaway7645
Every language has pros/cons and applicable use cases. Think of Python. It is
a beautiful language that is high level, uses white space, but requires the
python VM and is very slow. Nim has a somewhat pythonic syntax, compiles to C
and then binary executables and is very fast with good metaprogramming
facilities. That is appealing to a lot of people. I encourage you to read the
free chapter of Nim In Action as the author does a good job explaining why.

~~~
JadeNB
> I encourage you to read the free chapter of Nim In Action as the author does
> a good job explaining why.

Links: [https://www.manning.com/books/nim-in-
action](https://www.manning.com/books/nim-in-action) and (for the free
chapter) [https://manning-
content.s3.amazonaws.com/download/1/f2a2c55-...](https://manning-
content.s3.amazonaws.com/download/1/f2a2c55-0538-4405-8b5f-4ee6a104d860/Picheta_Nim_MEAP_V08_ch1.pdf)
.

