What makes Nim practical? • Hacker News Board

Re: What makes Nim practical?

#41

Post by CyberShadow » Fri, Jan 23, 2015, 4:03 PM UTC

def- wrote: post #38

CyberShadow wrote: post #29

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)

> - 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/m…

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

Re: What makes Nim practical?

#42

Post by Roboprog » Fri, Jan 23, 2015, 4:09 PM UTC

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

Well, not for the offshore and other coderz around that can't / won't cleanly indent if their lives depended on it.

Re: What makes Nim practical?

#43

Post by Roboprog » Fri, Jan 23, 2015, 4:10 PM UTC

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

Re: What makes Nim practical?

#44

Post by def- » Fri, Jan 23, 2015, 4:12 PM UTC

Roboprog wrote: post #43

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

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

Re: What makes Nim practical?

#45

Post by Symmetry » Fri, Jan 23, 2015, 4:15 PM UTC

CyberShadow wrote: post #32

namuol wrote: post #26

I perked up as soon as I read this: # Table created at compile time const crc32table = createCRCTable()

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

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]

Re: What makes Nim practical?

#46

Post by Wilya » Fri, Jan 23, 2015, 4:19 PM UTC

andybak wrote: post #30

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?

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.

Re: What makes Nim practical?

#47

Post by untitaker_ » Fri, Jan 23, 2015, 4:28 PM UTC

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!

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.

Re: What makes Nim practical?

#48

Post by dogprez » Fri, Jan 23, 2015, 4:35 PM UTC

adrusi wrote: post #21

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

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

Re: What makes Nim practical?

#49

Post by towelguy » Fri, Jan 23, 2015, 4:55 PM UTC

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

Re: What makes Nim practical?

#50

Post by pavlov » Fri, Jan 23, 2015, 5:13 PM UTC

towelguy wrote: post #49

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

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