

Learn X in Y minutes Where X=Nim - anacleto
http://learnxinyminutes.com/docs/nim/

======
rubiquity
Learn X in Y is pretty cool as a high level overview of a programming
language. But I really like How I Start[0] because it focuses on how a
programmer, often times the language creator or at the very least a prevalent
user of the language, goes about starting a library or project. Nim also has
an entry on How I Start[1]

[0] - [http://howistart.org](http://howistart.org)

[1] - [https://howistart.org/posts/nim/1](https://howistart.org/posts/nim/1)

~~~
rdudekul
Thanks for sharing. I found [http://hookrace.net/blog/what-is-special-about-
nim/](http://hookrace.net/blog/what-is-special-about-nim/) enlightening as
well.

------
themartorana
We've elected to use Go in a lot of our backend services - nothing striking
there - but I've also been playing with Nim for fun.

I can see clearly where I might draw a line of delineation between where I
select Go vs. say, Rust, but I'm not as clear where that line is for Go vs.
Nim.

Does anyone have any enlightening thoughts on that?

~~~
jakevn
Nim provides you more flexibility than Go or Rust.

Go is a GC'ed language and that's that. Like any other GC'ed language, the
treatment for GC woes is palliative.

Rust is designed around no GC and that's that. Of course, Rust did at one
point have a baked in GC and it can be used with a GC, but you need to fully
understand the Rust way of doing things and will always be working with the
borrow checker in mind.

Nim's GC is special in comparison to mainstream GC'ed languages as it offers
you great control. For ease of development it is a GC'ed language, yet for
performance and ABI purposes allows deterministic GC. It seems to offer the
ultimate in flexibility and expressiveness at the cost of footguns and
complexity.

~~~
pcwalton
> Nim's GC is special in comparison to mainstream GC'ed languages as it offers
> you great control. For ease of development it is a GC'ed language, yet for
> performance and ABI purposes allows deterministic GC.

Unless you need to GC pointers shared between multiple threads, in which case
your only option is the Boehm GC (which is imprecise, unlike Go's). This is a
significant disadvantage in both expressiveness and safety that Go does not
possess.

~~~
dom96
In what situations would you need to do this? I have been using Nim for a long
time now and never felt limited by this.

~~~
pcwalton
All the time. It's the bread-and-butter of high-performance concurrent
programming.

\- I have a large graph data structure allocated in one thread and I want to
transfer it to another thread without copying.

\- I have a lock-free data structure and I want the benefits of a GC so I
don't have to use less efficient hazard pointers [1].

\- I have an in-memory database that I want to be able to query efficiently
from multiple threads without copying.

\- I'm doing work stealing on a large, complex data structure and I need to be
able to access pieces of that data structure from multiple threads with
unpredictable memory access patterns.

\- I'm using a multicore job queuing system (like most AAA games do nowadays)
and almost all game assets can be accessed from any thread.

These are just a few. Sure, you can use unsafe manual memory management to
work around it, but without RAII and a library designed for manual memory
management you suffer a huge penalty in usability—not to mention the safety
problems. I can foresee people easily ending up in a situation whereby they
can't multithread their applications because they started out using the GC and
would have to rewrite all their code to switch from automatic memory
management to unsafe manual memory management.

Another way to work around the restriction is to copy the data, but that
usually ends up making your parallel algorithm slower than sequential unless
it has very high arithmetic intensity. (This is based on experience.)

[1]:
[http://en.wikipedia.org/wiki/Hazard_pointer](http://en.wikipedia.org/wiki/Hazard_pointer)

~~~
moe
_All the time._

Some people need these kind of optimisations all the time.

Most people don't need them even once in their entire life.

~~~
pcwalton
Every Cocoa app I've written has used "[NSObject
performSelectorInBackground:withObject:]", which relies on having a thread-
safe GC (atomic reference counting).

~~~
moe
And just as Cocoa abstracts this away from you any popular Nim frameworks that
need such optimisations will also abstract them away from you.

~~~
pcwalton
I don't see how. The abstraction here _is_ automatic memory management -- i.e.
the GC -- and the problem is that the abstraction doesn't work for this
popular use case. The language needs to provide a more flexible abstraction: a
thread-safe GC.

And it's not a question of optimization, it's a question of semantics.
Performing an operation in a background thread with a strong mutable reference
to an object is a _semantic_ concept. Without a thread-safe GC you simply
can't do it.

------
dallbee
And HN was doing so well, I haven't seen a nimrod post on here in days.

~~~
ORioN63
Nimrod name was changed to Nim, by the way.

