
Nim Programming Language 0.11.0 released - def-
http://nim-lang.org/news.html#Z2015-04-30-version-0-11-0-released
======
wiremine
It's a little thing, and not uncontroversial, but I'm excited to see another
language besides Python adopt whitespace. In general I wish more languages
provided a way to enforce code layout.

After using Python professional (and managing a team of developers) for a few
years, whitespace is a great way to keep things readable as more people touch
code.

Whitespace isn't the only way to do it, of course. Go's "gofmt" is a good
example of a different way to enforce code layout. [1]

[1] [https://blog.golang.org/go-fmt-your-code](https://blog.golang.org/go-fmt-
your-code)

~~~
progman
I always was strictly against whitespace in Python because it can lead to all
kinds of weird errors. But Nim (and also Haskell) has static types so most
wrong indentations are caught by the compiler. That's really nice to have.

~~~
nickbauman
I've been a Python dev since 2008 and I can count on one finger where this has
actually been an issue. I'd love have you enumerate the "all kinds of weird
errors" for me. Not saying you're wrong, mind you, just want to understand.

~~~
muaddirac
I have to agree - the only whitespace-related errors I've ever come across are
"IndentationErrors" \- which are pretty easy to resolve.

~~~
mercurial
I remember a bug caused by that, due to a merge, where an instruction went out
of an if block.

~~~
nickbauman
Ok this sounds legit. Thank you. But if you think about this carefully it
means that two people wrote the exact same expression in different scopes,
which seems really, really odd, no? I'm trying to contrive this in my mind and
I'm having difficulty (my fault, obvs).

If this happens again it deserves its own blog post describing the situation
carefully!

------
keypusher
I notice they have now included the Aporia IDE and Nimble package manager in
the Windows installer. This seems like a good step toward getting newcomers up
and running quickly, and getting more feedback from the community about the
core tools. It seems like many new languages are going with this route of
tools supported by core-dev, such as package management. For instance Go ships
its code formatting tool, which seems like a good idea. Supporting an IDE
seems more questionable, for instance Python never seemed to have much success
with IDLE, and IDE preference is very personal. Anyway, as someone who
primarily writes Python at work I find Nim to be very usable because the
syntax and style is so familiar, and I really like most of the decisions they
have made. I prefer Nim's static typing and compiled executables for
redistribution, and they have introduced nice new concepts around concurrency
and more advanced language features. Definitely looking forward to using this
language more and more as it moves toward 1.0

------
blt
It's very exciting that Nim has generator syntax in a compiled, statically
typed language. To me, recursive generators with "yield" and "yield from"
expressions are the most natural way to express iterative algorithms.

The Ranges proposal for C++17 is great for _consuming_ generic algorithms, but
it's far behind generators for _creating_ generic algorithms. Simple example:
try to write an iterator for a tree that doesn't have parent pointers. With
ranges or iterators, you must maintain a stack as a data member. With
recursive generators, the variables on the stack are captured implicitly in
the language. I only know a little about compilers, but it seems like a
compiler with syntax tree knowledge of the entire program should be able to
optimize generators into machine code that's just as good as iterators - i.e.
not copying all the caller-save registers onto the stack every time a
generator recurses.

I think generator syntax is truly a killer feature for any kind of serious
algorithmic work. C++11 made it a lot easier to write and use generic
algorithms, but writing iterators is still a big task that reluctant C++
programmers avoid. IMO, fear (and actual difficulty) of writing iterators is
the main reason most people don't enjoy C++. If C++ had shipped with
generators from the beginning, I think the programming language landscape
would be very different today.

Nim seems to have a small community and limited promotion, so I do not feel
especially hopeful that it will compete with C++ at the same level as Rust. (I
am not sure if Rust will upset C++ in any significant way either!) Perhaps a
well curated set of Nim/Rust/C++ comparisons could convince the C++ standards
committee or the Rust team to add generator syntax.

~~~
kibwen
Indeed, ever since making the switch to external iteration, Rust has had a
far-future desire for a `yield` construct to simplify the creation of
iterators (inspired by C#). See [https://github.com/rust-
lang/rfcs/issues/388](https://github.com/rust-lang/rfcs/issues/388)

------
Cyph0n
Congratulations to the Nim team!

I did a quick comparison between the up and coming compiled languages (D,
Rust, Nim, Go) and C++ a week or so back. My main aim was to assess the final
statically linked binary size for a simple hello world program.

Here are the results on x64 Mint:

1\. C++: 1.6 MB

2\. Go: 1.9 MB

3\. Rust: 550 KB with dependencies (I was not able to figure out how to pass a
static option to rustc)

4\. D: 710 KB, same as Rust

5\. Nim: 970 KB, statically linked

Nim wins, by a large margin. I did not remove any of the runtime checks by the
way. Removing them actually saves 100 KB+, depending on the program.
Furthermore, the Nim program was actually a naive Fibonacci number calculator,
not a simple hello world, meaning that Nim should have been at a disadvantage!
Amazing stuff.

~~~
gtaylor
That's cool, but with disk space and memory being as cheap as they are, is
this still a big deal in anything but the smallest of embedded environments?

~~~
Cyph0n
I think this kind of thing demonstrates portability at a lower cost and better
compile-time optimizations. You would think the other languages, especially
C++ and Rust, would do better in the latter.

~~~
pcwalton
The real problem is that glibc has a hard time being statically linked. We
just use the native system C library in Rust, which on Linux is usually glibc.

We could focus on musl support in order to get true static linking, but there
are much higher priority things like 1.0 stability, optimizations, and
compiler performance (though we'd take a patch of course). The fact is that
pure static linking is rarely done anymore, at least on mainstream
desktop/mobile/server systems, so it's not on anybody's critical path.

Dynamically linking to glibc does not really provide "better compile-time
optimizations". LLVM already understands the libc functions that really
benefit from inlining, like memcpy.

------
ziotom78
Congratulations to the developers for the impressive list of improvements and
fixes! Nim is becoming my first choice of programming language in a large
number of situations.

I hope to see version 1.0 soon. Keep up the good work!

------
mwcampbell
Good to see the Nim project moving closer to a solid 1.0.

Now all we need is a cross-platform GUI library that uses native widgets on
each platform, such as a set of bindings for wxWidgets or (better yet) a
translation of SWT from Java to Nim, and we'd have an excellent foundation for
self-contained, cross-platform desktop apps. Yes, I know desktop apps aren't
trendy (at least on platforms other than Mac), but they're still important.

------
zimbatm
Does Nim still allow indifferent `fooBar()` and `foo_bar()` to access the same
function call ? It makes grep-powered refactoring unnecessarily hard.

~~~
krupan
Looks like it's still there in the manual:

[http://nim-lang.org/0.11.0/manual.html#lexical-analysis-iden...](http://nim-
lang.org/0.11.0/manual.html#lexical-analysis-identifier-equality)

This just killed my excitement for this language. That's really surprising to
me that they would choose to enforce indentation Python-style, but would then
allow this kind ambiguity in naming.

grep and emacs isearch-forward are such great tools for quick code searching
and this will break them. I guess text search (and replace) tools could grow
nim-mode options, maybe. I don't know, can someone convince me this is a good
idea?

~~~
bryanlarsen
Suppose you have MyVariable and my_variable in your code. Which is worse: them
being the same variable or different variables? It's a pretty bad code smell
either way.

In my opinion it should be an error or at least a warning.

I'm not a big fan of nim's behaviour, but I don't think it's any worse than
what other languages do.

~~~
krupan
"Which is worse: them being the same variable or different variables?"

Them being the same is worse. I agree that both are pretty darn bad, but it's
also pretty clear to me which is worse.

------
zyxley
I hadn't seen this language before, but it looks neat. Coming from a Ruby
background, it's very interesting to see Nim's pragmas and templates, as they
look rather like type-checked and compiled cousins of metaprogramming methods.

~~~
hliyan
I concur. This is the first time I'm seeing it too. I come from a C++
background, with recent experience in Python and JavaScript. I'm rarely
impressed by new languages, but for some reason, Nim feels like what I wish
Python was.

~~~
progman
Indeed. But Nim is much more expressive than Python. A very nice feature of
Nim is clean macros. They support regular string matching in native Perl
syntax. For instance.

    
    
      if line =~ rx"http[s]://(.+)":
        var url = matches[0]
        ...
    

where rx is defined as:

    
    
      # partial regular expressions as in Perl
      template rx * (arg: expr): expr =
        re(r".*?" & arg & ".*")
    

Another macro instance:

    
    
      template repeat * (body: stmt): stmt {.immediate.} =
        block:
          while (true):
            body
    
      template until * (cond: expr): stmt {.immediate.} =
        block:
          if cond:
            break
    
      # Sample:
      #
      #  var i=0
      #  repeat:
      #    echo i
      #    i += 1
      #    until i==7
    

Nice, isn't it?

------
copx
> starting with version 1.0, we will not be introducing any more breaking
> changes to Nim.

I wonder whether they will stay committed to that. Pretty much all developers
of other "living" languages I know who do not have strong industry support and
thus pressure not to break working code introduce breaking changes all the
time e.g. see D.

Nim could distinguish itself from the crowd with such a commitment to
stability. However I expect overwhelming pressure from the enthusiast crowd
which currently utterly dominates among Nim users to introduce breaking
changes even post-1.0. And with little pressure from the other direction..

~~~
fragsworth
There will be plenty of pressure in the other direction, because of the fact
that they announced it.

It's a selling point for the language - a green light for companies to use the
language in production environments, and when they update things they don't
want their existing software to break.

------
bernardt32z
Maybe off-topic, but why exactly do we have hard and soft real-time? I think
this is terrible, either you have deadlines or you don't. E.g. in games which
lag you are missing deadlines and the result is terrible.

Currently it seems that we distinguish between hard-real-time, soft-real-time
and no-real-time, but probably we should just have hard realtime everywhere
and if we do not care, we just give big numbers. I mean even if you are not
hard realtime you're are probably expecting results before the heat death of
the universe, so maybe it would be a nice idea to NOT abstract time in
programming languages but give the possibility to the programmer to annotate
timing constraints in e.g. function's definitions? E.g. such information could
be crucial to the GC.

Maybe we could build such a mechanism into a fancy type theory?

~~~
xiaq
Network service is a good example for soft real-time systems. Under high load,
it is preferable to delay the responses a bit instead of starting to drop
requests.

~~~
bernardt32z
Yeah, but isn't that just hard real-time with bigger deadlines?

~~~
xiaq
No. Say we choose 100ms as the (soft) deadline, since some study showed users
consider a response time anywhere within 100ms to be "instant". Under light
load, all requests are served within 100ms. Under heavy load, response time of
some requests can exceed 100ms, but the scheduling algorithm will (likely) try
to minimize the quality loss.

If we increase the deadline to be 200ms, then even under light load, the
response time of some requests can exceed 100ms. That's not what you want.

~~~
bernardt32z
But in a hypothetical real-time programming environment you could switch
strategy at runtime (which of course limits your heuristics as it also has to
be hard real-time; that is probably the hardest part). E.g. you could have
different code path depending on "load" (which is probably a vague term) and
switch to different GC's implementations on the fly.

What I mean is, that you always have hard real-time in the end. E.g. you could
make your network service with a hard real-time limit of 100ms. On light load
you serve all requests as you mentioned with ease, if load gets heavier you
hit an uncommon situation (by definition, otherwise you would not be satisfied
with soft-realtime) and everything changes, as you hit a rare situation. You
could do different things, e.g. in case of a news page just serve plain text
and get rid of images and while you are doing that you also change to a
different GC that only guarantees 500ms.

------
phantom_oracle
I really wish I had a use-case for this powerful static language, but alas I
am no ninja, guru, zen-master, sensei or rocket-scientist who is working on a
problem that really needs this level of power/performance.

Python will always be "good enough".

~~~
rakoo
Maybe you don't need performance, but you like laziness; by being compiled and
statically checked, nim can catch many bugs automatically with default tools.

------
jlebrech
I want to build something like meteor that leverages nim's compile to JS and
C.

------
stefantalpalaru
> Negative indexing for slicing does not work anymore! Instead of a[0.. -1]
> you can use a[0.. ^1].

What's the justification for this change?

~~~
dom96
The following discussion on Github may answer your question
[https://github.com/Araq/Nim/issues/1979](https://github.com/Araq/Nim/issues/1979)

