Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What makes Nim practical?

hookrace.net

Post reply on HN
Print view View original

21–30 of 132 posts

Re: What makes Nim practical?

#21

Post by adrusi »

BoppreH wrote: post #7

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 th…

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.

Re: What makes Nim practical?

#22

Post by falcolas »

def- wrote: post #18
falcolas wrote: post #16

Earlier quoted context omitted.

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 i…

As unwind suggested, they just get transformed down to global functions with unique names. Here's the actual C code generated: https://gist.github.com/def-/0fe87bf1d35102c62d3b#file-nest-...

Nice. Not the most compact code I've seen, but it makes sense considering it's the output of a compiler, and can thus take advantage of optimizations from clang/gcc/what_have_you.

EDIT: Actually this raises the question of how it handles closures, since the generated code does not seem to provide for preserving the surrounding environment data. Though I may just need to dive in now that it's catching my interest.

Re: What makes Nim practical?

#23

Post by adrusi »

masklinn wrote: post #20
unwind wrote: post #17

Earlier quoted context omitted.

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.

> 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.

Procedures can appear at the top level in a module as well as inside other scopes, in which case they are called nested procs. A nested proc can access local variables from its enclosing scope and if it does so it becomes a closure.

From the manual: http://nim-lang.org/manual.html#closures

Re: What makes Nim practical?

#25

Post by BoppreH »

def- wrote: post #13
BoppreH wrote: post #7

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 th…

Nested functions like this?: proc a = proc b = proc c = proc d = echo "Hello World" d() c() b() a() Works fine.

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.

Re: What makes Nim practical?

#28

Post by msandford »

wtf_is_up wrote: post #24
iopq wrote: post #14

Earlier quoted context omitted.

Better metaprogramming, significant whitespace, generics, etc.

> significant whitespace That's not an advantage

So says you. The entire python community disagrees, and that's not an inconsiderable number of folks.

Re: What makes Nim practical?

#29

Post by CyberShadow »

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)

Re: What makes Nim practical?

#30

Post by andybak »

moe wrote: post #2

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

py2app and py2exe are fairly solid in this regard, aren't they?
Post reply on HN