What makes Nim practical?

http://hookrace.net/blog/what-makes-nim-practical/

by def- • 12 years ago

154 130 12 years ago

hookrace.net

moe• 12 years ago

I love how these new languages compile into a static binary and thereby avoid the deployment nightmares of Ruby/Python.

More of that please!

andybak2• 12 years ago

py2app and py2exe are fairly solid in this regard, aren't they?

Wilya• 12 years ago

No experience with py2app, but I've used py2exe and pyinstaller in production.

They can be made to work, but you regularly stumble on some more or less obscure bugs. The short of it, is that you have no guarantee that the compilation step won't introduce bugs in your program, so you need a solid test suite for the compiled binary. It's feasible, but clunky, and you really get the feeling that the compilers aren't first-class citizens.

untitaker_2• 12 years ago

I came across [pex](https://github.com/pantsbuild/pex) a while ago. It basically compiles your package and all its dependencies into a single zipped module.

I never had the opportunity to try it out myself though.

woadwarrior01• 12 years ago

If PEP-441[1] makes it to Python 3.5, pex like functionality will be a part of the standard library.

[1] https://www.python.org/dev/peps/pep-0441/

pjmlp4• 12 years ago

If Common Lisp, Scheme or Dylan had been adopted by mainstream programmers, dynamic languages with JIT/AOT compilers would already be a common practice instead of only available to a few that care to look around.

JimmyM• 12 years ago

Great post. I thought I'd comment just to say about the relative URL ../what-is-special-about-nim not working as intended from the homepage and the link to http://nim-lang/ which should presumably be http://nim-lang.org

Seems a shame to make such a pedantic and insubstantial comment on such an interesting article about a language I'd not come across, but thought the author might like to know.

def-11• 12 years ago

Oops, I thought I checked all links. Thank you!

iopq4• 12 years ago

I just realized something: Nim is like a faster Python or a better Go lang

It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

def-11• 12 years ago

Why would you say it's not competing with D and Rust? Performance-wise Nim should be in the same ball-park, and you can do systems programming in it. For me Nim is a universal language which I can use for almost anything.

Rusky• 12 years ago

D maybe, since it has a GC, but Rust not as much. A lot of defaults are different, affecting how libraries and idiomatic code are written and what situations it can be used in without turning things off or avoiding features.

iopq4• 12 years ago

Rust is where you can write code that relies on a custom allocator. Or a program that doesn't allocate memory. It's usable for the really low level stuff. Because of this everything must be explicit. Nim is implicit. It doesn't require you to declare a main() function, for example.

pcwalton4• 12 years ago

Nim does not have the memory safety without garbage collection features of Rust. If you want memory safety in Nim, you have to use the garbage collector (which, last I looked, is not thread safe either, although I see that Boehm is now an option).

It's easy to write (a) an unsafe language that has no GC, or (b) a safe language that relies on GC for safety. It's also easy to write a language that is in category (b) but lets you drop down to category (a) in an unsafe dialect. It's a very difficult problem to write a safe language that does not rely on GC, and I know of no other industry language that has done it. Unfortunately, people often lump Rust into categories (a) or (b), without realizing that what makes it interesting is that it isn't in either. Nim may be in category (b) (if the thread safety issues in the GC have been solved, or you use Boehm, or your app is solely single-threaded) with the ability to drop down to category (a), but it is not in Rust's category.

xkarga003• 12 years ago

Care elaborating on why is it a better Golang?

S4M• 12 years ago

It has generics, for once?

kxo• 12 years ago

Without pointing out specifics: Nim has comparable ambitions to Go but Nim actually has escape hatches for people that desire "more."

iopq4• 12 years ago

Better metaprogramming, significant whitespace, generics, etc.

beeworker• 12 years ago

Just about everything is better than Go. Nim, Rust, OCaml, Haskell... Did you read the submission? And for further enlightenment, the link to the previous post on the blog about what makes Nim special? Here's a link to a rant comparing Go and Rust, which includes some links of its own highlighting further issues with Go: http://www.quora.com/How-do-Go-and-Rust-languages-compare

fiatjaf• 12 years ago

I don't know if it is, I use Golang and I never used Nim, but the source code from Nim is way prettier: http://rosetta.alhur.es/compare/nimrod/go

lmm• 12 years ago

Comparisons to D or OCaml would be interesting (it'd be good to see that "new language for 0install" post redone with nim as one of the candidates). I think people are shoehorning Rust into the "compiled, typesafe, but strict and impure general-purpose programming language" niche, just because there aren't as many nice options there as we'd like.

codexon3• 12 years ago

There's 1 thing that can't be done in Nim that you can do in Go though. And that is the goroutine system. Something like that needs to be explicitly baked into the language. You can try to emulate it with your own thread pools but you will never get the same level of preemption.

However few people will ever need this feature, and erlang/elixir probably does it better, though at a the cost of speed.

fenollp• 12 years ago

But but but Go's concurrent scheduler just isn't preemptive. It's cooperative (and that's meh).

pekk4• 12 years ago

Nim can't be a faster Python when it isn't a Python, but a much younger language which lifts a few cosmetic choices but intentionally breaks with Python in large ways. If it is trying to replace Python, many of these breaks are poorly chosen and reflect a lack of understanding of why Python and its ancestors were unique. Aside from this, many of the practical refinements of Python are dropped in favor of fancy and shiny features that are better for arguing on HN than actually using. If I really want macros, Lisp never went away, but they aren't doing Nim's readability any favors.

Go is much more mature than Nim and encapsulates a huge amount of thinking and experience in language and compiler design. Nim would like to be Go. But it isn't.

pekk4• 11 years ago

It really makes no sense that saying "Nim is better than Python" is an acceptable opinion, but "no, it isn't" is not an acceptable opinion to HN.

BoppreH2• 12 years ago

I read the Nim manual a while ago (http://nim-lang.org/manual.html), back when it was Nimrod.

As a Python user, I loved it. Every single problem I had with Python, Nim seemed to have solved elegantly. Performance, distribution, typing... Everything looked perfect, and none of the Python expressiveness seemed to have been sacrificed.

But it was transpiled to C, and the abstraction was leaky. Every once in a while the manual would mention that certain structures were not supported, and it was clear C was the culprit. I think the most glaring example were nested functions, or something similar.

I thought to myself "this will bite me in the ass sooner or later" and gave up. Maybe it's time to try again. If they plugged the abstraction holes, this will be a killer language, with applications everywhere.

def-11• 12 years ago

Nested functions like this?:

  proc a =
    proc b =
      proc c =
        proc d = echo "Hello World"
        d()
      c()
    b()
  a()

Works fine.

falcolas3• 12 years ago

If (and I haven't been interested enough in Nim to investigate) it is indeed compiled to C and then compiled down to platform specific code, unless they are implementing functions differently, nested functions are not a standard part of C; they are a compiler extension (which GCC supports).

Not necessarily a problem, but unless implemented as something other than nested functions in C, there may be some portability issues. Worth investigating.

BoppreH2• 12 years ago

Dang, sorry. I skimmed the manual again, but couldn't find the exact feature(s) that triggered my conclusion. Maybe they have been plugged already.

Anyway, I think I'm overdue on reevaluating the language. I can't wait to replace Python/Go/C/Java with this.

unwind• 12 years ago

It doesn't make sense that a language that compiles to C can't support nested functions, just because C doesn't.

All the transpiler has to do is invent a globally unique name for each function, for instance. Of course they might not have implemented it yet, but there shouldn't be any firm reason why it can't be done.

masklinn• 12 years ago

All the transpiler has to do is invent a globally unique name for each function, for instance.

I would expect nested functions to close over their context. Still implementable in C of course (or ghc -fvia-c wouldn't work), but not as trivially.

adrusi2• 12 years ago

Nim isn't compiled to C in the same way that, say, Coffeescript is compiled to Javascript.

Nim's compiler converts the AST into an intermediate representation that can be compiled to several backend. The primary backend is C source code, but it also supports outputting Javascript (experimentally) or interpreting the intermediate representation ala Python.

The difficulty of developing the IR -> C transformation certainly influences the features of the language, and certain features, like tail calls, can't be implemented because Nim expresses functions as C functions for the benefit of foreign code. I wouldn't say it's a leaky abstraction though, not any more than C is a leaky abstraction over machine code.

dogprez2• 12 years ago

Your example isn't exactly true. Clang and GCC both do tail call optimizations. Compiling language functions to C functions doesn't 100% preclude you from TCO. http://david.wragg.org/blog/2014/02/c-tail-calls-1.html

marvy3• 11 years ago

Tail calls are pretty easy to implement in a language that compiles to C, even if the C compiler doesn't cooperate. This can be done without bothering the foreign code. For instance:

int f(int a, int b){return f(b,a);}

compiles into

int f(int a, int b){start: int t=a; a=b; b=tmp; goto start;}

antman• 12 years ago

I tried it and it is easy and fast. But the ecosystem is still not very large. I think that it should support building libriaries directly accessible from python including passing numpy arrays directly to nim. That would make a lot of people to jump right in creating libraries and thus extending its own ecosystem.

curiouslearn• 12 years ago

Something like Julia's PyCall package that allows calling arbitrary Python packages from Julia would also be great.

chrisheller2• 12 years ago

NimBorg is what you're looking for, https://github.com/micklat/NimBorg

namuol2• 12 years ago

I perked up as soon as I read this:

    # Table created at compile time
    const crc32table = createCRCTable()

CyberShadow5• 12 years ago

This is not an unique feature today, you can do the same in D and Rust and even C++14, I think.

namuol2• 12 years ago

"Hey Nim, 2014 called... they want their language features back."

I jest.

But seriously, D, Rust, and C++14 are about as familiar to me as Nim.

Symmetry• 12 years ago

Rust is planning to add that eventually, but in the meantime:

    fn foo(n: i32) -> i32 {
        n * 2
    }
    const y: i32 = foo(3);

error: function calls in constants are limited to struct and enum constructors [E0015]

tokenrove• 12 years ago

Or Common Lisp, 30 years ago.

egeozcan2• 12 years ago

I keep coming back to it, and I really like it but wouldn't it be great if it had interfaces? I really want to restrict the generic type but there seems to be no way other than using templates[1].

[1] https://github.com/Araq/Nim/blob/master/lib/pure/collections...

def-11• 12 years ago

User defined type classes can be used for this, but they're still experimental: http://nim-lang.org/manual.html#user-defined-type-classes

egeozcan2• 11 years ago

I can't believe how I missed that. Maybe this is added recently? Anyway, thank you very much!

CyberShadow5• 12 years ago

Nim has some good ideas but I can't get over the syntax:

  - Significant whitespace, but tabs are forbidden
  - No block comments, save for `discard """ ... """`
  - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

def-11• 12 years ago

- Significant whitespace, but tabs are forbidden

Here's the reasoning: https://github.com/Araq/Nim/wiki/Whitespace-FAQ#tabs-vs-spac...

If you still want tabs you can add this at the top of your files and they work:

    #! replace("\t", "  ")

> - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

This changed recently, now the first letter is considered case sensitive: http://nim-lang.org/manual.html#identifier-equality

CyberShadow5• 12 years ago

Here's the reasoning: https://github.com/Araq/Nim/wiki/Whitespace-FAQ#tabs-vs-spac....

Honestly, there are less drastic solutions to these problems. Some languages (forgot which) simply forbid mixing tabs and spaces when the tab size makes the code ambiguous. And their C example will generate an "ambiguous else" warning in D, which you can disambiguate by adding braces.

dom962• 12 years ago

- No block comments, save for `discard """ ... """`

I believe a different syntax for those will be added soon: https://github.com/Araq/Nim/issues/1535

filwit3• 12 years ago

Not that it's even really needed... Just select the section of text and use your IDE's shortcuts to comment it out (which now works fine in any IDE due to comments no longer being part of the AST)

mVChr4• 12 years ago

- Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.

bpicolo2• 12 years ago

Let's be realistic. If you have somebody naming variables:

foo_bar = blah

foobar = blah

fooBar = blah

That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.

bastih• 12 years ago

The idea here -as far as I'm aware- is to allow for different coding styles without having to wrap another library. One author preferring camel case while another library uses underscore, lowercase naming?

For a new language, I feel like one could have just forced one style unto the users, but that's just me talking.

girvo2• 12 years ago

It's really nice when you're talking to a C library that use various prefixes and other stylistic choices that don't map well to the Nim code I want to write.

dscrd• 11 years ago

There are worse things than PHP out there :)

Many of the so-called 4th generation languages (i.e. business shits derived from Cobol with DB support bolted in) are totally crazy in this sense. Not only are identifiers often case insensitive, they can also be abbreviated!

Yet people make massive amounts of money with them.

quotemstr4• 12 years ago

Underscore insensitivity is unforgivable: it makes grep work poorly. I guess I'll have to strike Nim from the list of languages I might want to use.

Roboprog2• 12 years ago

Is there a "ctags / etags" utility for nim yet?

def-11• 12 years ago

That's something nim-idetools can do once it works properly: http://nim-lang.org/idetools.html

towelguy2• 12 years ago

Nim libraries are statically compiled into our binary as well.

Does that mean one can not use GPL libraries in non-GPL programs? With other languages you can get around that by linking dinamically.

pavlov• 12 years ago

Actually that only applies to LGPL libraries -- pure GPL doesn't allow dynamic linking, even. (That's the most common interpretation anyway, and the reason why LGPL exists.)

xtrumanx2• 12 years ago

That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in.

What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.

sanxiyn• 12 years ago

No, binaries do not require a C compiler. Yes, Windows and Windows CE are included.

def-11• 12 years ago

That means if programs written in C work on your OS, so do the ones in Nim.

xtrumanx2• 12 years ago

Sorry if this is a silly question but I've always thought of C as generating machine code and it had compilers available in any imaginable platform besides perhaps really niche stuff.

Were my assumptions accurate?

joelthelion2• 12 years ago

Just add autocompletion and syntax checking for the major editors and people will start adopting it.

def-11• 12 years ago

That's on its way!

codexon3• 12 years ago

Doesn't nim already have autocomplete?

towelguy2• 12 years ago

I wonder if it can generate bindings for Python like Vala does[0]? That would make it even more interesting for Python developers.

[0] https://github.com/antono/vala-object

chrisheller2• 12 years ago

I haven't looked closely at the Vala stuff that you mentioned, but it is very straightforward to generate shared libraries in Nim with exported functions that you can access via ctypes. That's not quite the same as generating a python module that you can directly import, but it gets the job done.

You might also be interested in NimBorg, https://github.com/micklat/NimBorg , which supports embedding Python or Lua in a Nim program.

jwiley• 12 years ago

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

pcwalton4• 12 years ago

It doesn't seem like an accurate claim, as Rust also has the ability to reason about uniqueness of data. Rust uses a type system to do it—which, via Curry-Howard, qualifies as "automated proof technology" :)

It looks like Nim has some ability to reason about arithmetic identities natively, which is neat. In practice Rust uses iterators to encode the same sorts of common patterns in the type system.

marvy3• 12 years ago

Well, it will be hard to find a proof for it being the "only" language to do so, since as one of the commenters mentioned there is indeed at least one other. But http://nim-lang.org/manual.html#parallel-spawn seems to discuss it a bit. Or did you want more details? If so, what kind? Actually I don't know anything about Nim anyway, so whatever your question is I can't answer it.

Araq2• 12 years ago

Well I did my homework. When you find another language that does it in a somewhat similar fashion, I'll happily change the website. ;-) I didn't think Rust counts, but since it's constantly changing, I will have a fresh look at it.

def-11• 12 years ago

This is all I found: http://nim-lang.org/manual.html#parallel-statement

Araq2• 12 years ago

Disclaimer: I'm the lead designer of Nim.

pcwalton's remark is excellent but "automated proof technology" is not a well defined term. What I mean by this is that it goes beyond what a traditional type checker can do. I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong. Note that the very same analysis also proves your index bounds are correct.

Nim's disjoint checker is so experimental that its docs are indeed very terse and we only have a couple of test cases for now. That said, the disjoint checking is restricted to the 'parallel' statement, so its complexity only affects this language construct and not the whole language. You can think of it as a macro that does additional checking.

dbaupp• 12 years ago

I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong

Reading http://nim-lang.org/manual.html#parallel-statement point by point (disclaimer, I think Nim is very cool, but safe parallelism is one of Rust's strongest points):

Every location of the form a[i] and a[i..j] and dest where dest is part of the pattern dest = spawn f(...) has to be provably disjoint. This is called the disjoint check.

The type system guarantees disjointness when necessary: a mutable reference `&mut` is guaranteed to be the only way to access the data it points to at any given point in time and iterators over mutable references preserve this guarantee, so disjointness-for-writing is automatic.

Every other complex location loc that is used in a spawned proc (spawn f(loc)) has to be immutable for the duration of the parallel section. This is called the immutability check. Currently it is not specified what exactly "complex location" means. We need to make this an optimization!

Rust generalises immutable to "safe to be used in parallel"; everything that is (truly) immutable satisfies this, but so do, for example, memory locations that can only be used with atomic CPU instructions, or values that are protected by a mutex. There's no way to get data races with such things, so they're safe to refer to in multiple threads.

This is captured by the Sync trait (types which can be used from multiple threads in a shared way implement it): http://doc.rust-lang.org/nightly/std/marker/trait.Sync.html

Every array access has to be provably within bounds. This is called the bounds check.

Rust's iterators give in-bounds automatically, but there's also no restriction about requiring bounds checks or not. (What does this rule offer Nim?)

Slices are optimized so that no copy is performed. This optimization is not yet performed for ordinary slices outside of a parallel section. Slices are also special in that they currently do not support negative indexes!

I'm not sure what this means in the context of Nim, but passing around a Rust references never does a copy (even into another thread).

(Disclaimer 2: it's not currently possible to pass a reference into another thread safely, but the standard library is designed to support it, the only missing piece is changing one piece of the type system, https://github.com/rust-lang/rfcs/pull/458 , to be able to guarantee safety.)

malkia• 12 years ago

I'm assuming "staticExec" is not sandboxed in any way...

It's one thing to make your compile stuck it's head while doing #include "aux" in windows, but completely different to treat source code as "shell"-script.

(I see the point, and it's a great feature, but with too much power).

monono• 12 years ago

Sure, just don't use it then.

honhon• 11 years ago

I played around with Nim and it has huge potential. It is early days and I would like to thank the creators of the language. A decent IDE is the only issue for me. I tried all the IDE options and it was stark. The idetools didn't work for me and the unit tests failed on Ubuntu 14.04.

At the moment small projects and libraries should be fine but the lack of IDE would be an issue for bigger projects.

What makes Nim practical?

Related Stories