
Show HN: “Nim in Action” is now available - dom96
http://nim-lang.org/news.html?r=1#Z2016-01-27-nim-in-action-is-now-available
======
AsyncAwait
Great to see Nim getting an official book, (Dominick is almost like a co-
author of Nim at this point :-).

My impression of Nim is that it is what Go should have been, if language
developments of the past 40 years were taken into account, so if you like the
simplicity of Go's syntax, but want modern features, seriously consider Nim.

I personally couldn't get over the significant whitespace, (relying on
invisible characters doesn't sit well with me) [1], but apart from that I like
the language a lot!

@dom96 Do you think that the focus on web development is good to have? I
realise that it is what a ton of people do these days, but since web
developers already have so many technologies to pick from, perhaps selling the
book as aimed more at system/game even native desktop developers could spring
up more interest.

Also, how exactly is the garbage collector tied to the standard library and
the language itself? For example, if I opt out of the GC completely, would I
end up in a situation similar to D, where I'm not using GC but everything
around me still is, so I have to carefully program around it, or is it handled
differently? (And can you possibly compare Nim and D as the languages seem to
be covering similar territory.)

Lastly, what major work still needs to be done before we see a 1.0 release and
how best can we help Nim to move towards that goal right now?

Thanks, back to the book now...

1 - Maybe a gofmt style tool would help somewhat.

~~~
dom96
Thank you for the kind words! I'm happy that you can see the positives in Nim
even though you dislike one of its most prominent features.

Personally I love significant whitespace and have started using Nim because of
this feature, basically back in the day I just wanted a Python alternative
that was compiled. If you really dislike it that much, you may be able to
convince Araq to bring back his old time idea of allowing different syntaxes
in Nim. As for a gofmt tool: `nim pretty` exists but may need to mature a bit.

I believe that a focus on web development is good. One of the reasons why the
book has such a strong focus on it is because I have spent most of my time
implementing stuff which is necessary for web dev in Nim, and I want to show
it off. The fact that I have a lot of experience with it helps too.

I would love to show off as many things as I can, and I might look into
including some examples of SDL, SFML, and more as well as ways to utilise
Nim's real-time GC for games. But I must be careful, the book is already
becoming rather large :)

As for systems, there is a whole chapter dedicated to Direct Hardware Control
in the book. But I will make a note of maybe including something for native
desktop developers.

In terms of the GC, I don't have as much experience using Nim with no GC as I
would like. So I can't really comment as to the current situation.

In terms of a comparison to D, I've already received feedback to add D to the
language comparison table in Chapter 1. To compare these properly I will need
to do some research first.

Nim is very close to 1.0 now. We are planning on looking at the standard
library and ensuring that it is in tip top shape before 1.0 is finally
released. There is also work currently happening to make asynchronous IO
multithreaded.

Thanks for the feedback and hope this answers your questions!

~~~
eaurouge
In your Direct Hardware Control chapter, please include a bit on targeting
embedded systems like ARM Cortex-M microcontrollers. For instance, how to get
started and problems/gotchas to watch out for. I'm going to try this out
myself over the next few months so let me know if you need me to try something
out or for a chapter review.

~~~
dom96
Will do!

Please do try it out and report the results on the Nim forums (or via blog
post). This is one of the chapters where I will need to do some research
first, as I don't have much experience with this kind of stuff. So any ideas
for this chapter are very much appreciated!

I thought it would be a nice chapter to end the book with though. Plus I am
excited to play with this sort of stuff.

My current plan for this chapter is to try replicating some of the projects in
the Arduino starter kit and to see where I can go from there.

------
dom96
Author here!

Even if you don't intend to purchase the book I would love to hear feedback
from you about the first chapter (which is free!)[1]. Really excited about
this book and am looking forward to any feedback at all from the HN community.

1 - [https://manning-
content.s3.amazonaws.com/download/6/df42fc6-...](https://manning-
content.s3.amazonaws.com/download/6/df42fc6-bff6-453b-9482-641468038572/Picheta_Nim_MEAP_V01_ch1.pdf)

~~~
systems
well, i dont know if nim have a free book yet, but i would suggest making the
ebook free

this will encourage students and casuals to look into nim

~~~
ilaksh
There is a free manual, free tutorials, core source is free, all Nimble
packages are free, free tutorials in blog posts, free first chapter, many free
projects..

~~~
Jach
Plus the book's source code examples will be free. (And, if we're honest, the
book itself will be free too on various book-download sites...)

------
echelon
Based on my surface-level understanding of Nim, Go is much more comparable to
Nim than it is Rust. I never understood the Rust-Go comparisons, since Rust is
a serious systems programming language. I would never use Go or Nim to replace
C or C++ usage as I would Rust, but I might use Nim in place of Go or Java.

Does anyone with significant Nim experience care to lend some opinions? I
don't want to start a flame war--I'm genuinely curious.

~~~
gokr
Nim compiles to very efficient C or C++ (or js) and most benchmarks shows Nim
programs performance being almost the exact same as C/C++ - and often better
than Rust.

So... why not using it to replace C and C++? Since I have worked with Nim (and
I use it to implement my own language) I would say "hell yes"! It is such an
immensely better language and it integrates perfectly with those eco systems.
The GC is a good one (or well, there are 5 to choose from) and it is for many,
many applications not an issue.

And __before __pcwalton drops in with his endless spamming about Nim not being
safe, Nim being undefined etc etc (it 's getting quite annoying), please spare
us this time.

~~~
Ygg2

       > And before pcwalton drops in with his endless spamming
       about Nim not being safe, Nim being undefined
    

Well, it is, isn't it? Is he wrong about Nim not being safe when not using
Boehm GC? Does it not segfault when sending GC pointers between threads?

He only jumps in, when someone claims Nim is safe or the sweet spot, or
something equally wrong. Nim's pretty syntax comes with a price, just like
Rust's safety comes with a different kind of price.

~~~
gokr
About safe/undefined etc I think it has been answered before (there are
probably more places):
[https://news.ycombinator.com/item?id=9643690](https://news.ycombinator.com/item?id=9643690)

Personally I am quite sick and tired of that particular "take" on Nim - why
not for once criticize other parts of the language? :)

~~~
pcwalton
> Personally I am quite sick and tired of that particular "take" on Nim - why
> not for once criticize other parts of the language? :)

Because I'm not interested in criticizing languages as a whole—that would be
language warring for no reason. Claims of memory safety are what are important
to me, just as, for example, claims of correct crypto constructions are
important to crypto people.

Anyway, I see no reason to go further here, given that nobody has claimed
anything is memory safe.

~~~
gokr
Great! Thing is, Rust and Nim are very different. Just as I wouldn't put Rust
down for not having GC (I love languages moving the art forward) I just wish
we could look at Nim as a language with different design goals than Rust. I
know several things in Nim worth discussing, it doesn't have to be warring.

~~~
masklinn
> I just wish we could look at Nim as a language with different design goals
> than Rust.

Claims that Nim is memory-safe when it's not is not a difference of design
goal though.

~~~
gokr
See my comment
[https://news.ycombinator.com/item?id=10992077](https://news.ycombinator.com/item?id=10992077)

It seems to me that a) Nim is (or at least is meant to be, but bugs can
sidestep it) memory safe if you stay within the rules for it, and b) _Nim_ is
not throwing around vague claims of safety that are not documented in the
language manual.

~~~
masklinn
> It seems to me that a) Nim is (or at least is meant to be, but bugs can
> sidestep it) memory safe if you stay within the rules for it

That's completely worthless. C is also memory-safe if you stay within the
rules for memory safety.

> Nim is not throwing around vague claims of safety that are not documented in
> the language manual.

Of course not since nim is not posting on HN (as it's not a sentient being
prone to procrastination) it's obviously nim supporters making claims about
nim's safety.

~~~
ben0x539
> That's completely worthless. C is also memory-safe if you stay within the
> rules for memory safety.

It's really not any weaker of a guarantee than Rust makes, being memory-safe
if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem
for writing, anyway.

I'd also feel a lot better about Rust's moral highground of memory safety if
its undefined behavior was actually spelled out a bit more rather than just
punting the hard parts to llvm docs. I don't think every Rust user knows how
to avoid aliasing problems between `&mut` and `*mut` either.

~~~
pcwalton
Well, I think there's a very big practical difference between being unsafe in
general and unsafe only within clearly delimited boundaries (that you can
forbid with a lint). The latter is pretty much necessary for any language
other than strictly sandboxed ones like JavaScript, while the former is
something I think _all_ languages in 2016 should take as sacrosanct from the
get-go. (We've been trying and failing for about 45 years to prove that
programmers will avoid making the same basic memory management mistakes if
they're just trained better; I think it's well past time to give up and
delegate these checks to the machine.)

That said, I don't agree with the claim that Nim is less safe than Rust
because Nim uses "ptr" types and Rust uses "unsafe" blocks to mark unsafe
regions. I prefer Rust's approach, but it's pretty much just a question of UI,
not anything substantive.

------
incepted
The main problem with languages that generate C or some other language is
debugging.

Does Nim have a good answer to this?

~~~
audunw
Nim works quite well with GDB. I've tried it. It can generate metadata that
GDB can use.

It's not perfect, but for my uses it has been alright (but then I'm ususally
the kind of person who prefers to use debug printing and just studying the
code)

Nim also shows very nice stack traces on uncaught exceptions so that also
reduces the need to fire up GDB.

------
Lovenim
I should like to know if Nim can be used for machine learning or for deep
learning. How could be located Nim in comparison to Julia, numpy, Torch7 and
the tools for deep learning and AI that many big companies are open sourcing.

~~~
andreaferretti
I think Nim would be ideal for that kind of applications, in particular neural
networks stuff. But definitely we are not there yet. I try to explain my
reasons in this blog post: [http://rnduja.github.io/2015/10/21/scientific-
nim/](http://rnduja.github.io/2015/10/21/scientific-nim/)

To get to a point where we have something good to use, though, there are a few
libraries to develop. I started working out a basic layer for linear algebra,
that is needed in many applications - see [http://unicredit.github.io/linear-
algebra/](http://unicredit.github.io/linear-algebra/)

I hoped I would be able to start working on some neural network stuff based on
that, but I did not find the time yet...

~~~
Lovenim
Interesting post. I also enjoyed the posts about Torch but when installing in
ubuntu 15.10 there were some problems. Libraries are necessary to avoid
reinventing the wheel.

------
dang
We added "Show HN" to the title (the convention for sharing your own work on
HN) because the post is by the author and, when the project is a book, a free
chapter is a nice way to let people try it out.

~~~
dom96
Thank you! I was wondering whether this was eligible for "Show HN".

~~~
dang
Considering how much work a book is, it would be cruel to say anything else.

------
hellofunk
My questions! I have never written a line of Nim but am enticed:

>Nim allows you to use snake_case even if the identifier has been defined
using camelCase, and vice versa.

Can you also just write it all lowercase, and same synonym effect? i.e.
snakecase

> The default garbage collector is real-time so it allows you to specify the
> amount of time it should spend on collecting memory.

Since Nim compiles to C, which is not garbage collected, does Nim just
automatically add its own C-based GC library behind the scenes (no small
task), or is it actually just adding calls to free for you?

> This applies to languages such as C++, Pascal and Ada. But these languages
> still require platform specific code when dealing with more specialised
> features of the operating system, such as creating new threads ...

Not true any more for C++, since the new C++ standard 5 years ago, which
contains cross-platform standard library tools for multithreading.

>The speed of a programming language is one characteristic that is often used
to compare multiple programming languages

Since this statement is in the book, it would be nice to see Nim programs
participating in the online benchmarks game.

>Table 1.2 Common programming language features

A little misleading or perhaps just incorrect to place a No in C++'s box for
metaprogramming. Entire books have been written on C++ metaprogramming.

~~~
dom96
Hello, thank you for the questions and feedback!

> Can you also just write it all lowercase, and same synonym effect? i.e.
> snakecase

Yes, the first character is case sensitive, but the rest is not. foobar ==
fooBar == foo_bar == foo_Bar but FooBar != fooBar.

> Since Nim compiles to C, which is not garbage collected, does Nim just
> automatically add its own C-based GC library behind the scenes (no small
> task), or is it actually just adding calls to free for you?

Nim adds its own Nim-based GC library behind the scenes. In fact, it supports
multiple GCs (which can be changed via the --gc flag).

> Not true any more for C++, since the new C++ standard 5 years ago, which
> contains cross-platform standard library tools for multithreading.

Is this standard well supported by now? I'll change it to 'C' in any case.

> Since this statement is in the book, it would be nice to see Nim programs
> participating in the online benchmarks game.

I agree, maybe you can convince them to include it:
[http://benchmarksgame.alioth.debian.org/play.html#languagex](http://benchmarksgame.alioth.debian.org/play.html#languagex)
:)

> A little misleading or perhaps just incorrect to place a No in C++'s box for
> metaprogramming. Entire books have been written on C++ metaprogramming.

Somebody else raised this point. Will correct.

Hope this helps!

~~~
hellofunk
>> Not true any more for C++, since the new C++ standard 5 years ago, which
contains cross-platform standard library tools for multithreading.

>Is this standard well supported by now? I'll change it to 'C' in any case.

The standard is 5 years old this year and nearly every major compiler has
supported it for years, and the big ones supported it before the standard was
officially in place. So changing it to C would be much more accurate.

That's not to say that each platform's unique tools, i.e. Apple's own GCD for
multithreading, are not still available and widely-used. But C++ lets you not
worry about platform-specific multithreading any more, and it's quite nice! In
addition to multithreading primitives in the standard, there are also higher-
level task-based tools like futures and promises that are cross-platform also.

~~~
dom96
Nice! C++'s standards committee did a good job of making sure C++ stayed
current :)

~~~
hellofunk
And it continues, major enhancements are abounding. C++17 introduces cross-
platform network and socket interactions as part of the standard, among other
goodies.

------
AsyncAwait
Suggestion: It may be a good idea to show line numbers in the code samples,
since the compiler error messages, discussed in the text, refer to them quite
extensibly.

~~~
dom96
Agreed. Will make a note to add that, thank you!

------
incepted
Note: the title is misleading.

The book is _not_ available yet, only the first three chapters.

~~~
overcast
Yes, and the first is free. I was considering a purchase, but there's not
really much to read at this point. FYI, "mlpichetatw" code will give you 50%
off this book on checkout.

------
BuckRogers
I test drove Nim when it was "Nimrod" quite some time ago, sounds like 1.0 is
coming soon. Looking forward to it! It's really good to see Pythonesque
languages pop up.

------
doboo
Could be of interest if the creator didn't self-promote the language through
an aggressive tone "after a few beers"
[https://hero.handmadedev.org/forum/code-
discussion/937-i-wou...](https://hero.handmadedev.org/forum/code-
discussion/937-i-would-like-to-recommend-the-language-nim)

~~~
gokr
The creator? I may be daft but that is someone saying he/she has been using
Nim for one year?

~~~
veidr
You are right, that is just some random drunk person on an internet forum
recommending Nim (who has apparently picked it up recently, and says they are
going to write their next project in it). It's not creator Andreas Rumpf or
anybody central to the Nim project.

