Live data from Hacker News

What makes Nim practical?

hookrace.net

121–130 of 132 posts

Re: What makes Nim practical?

#121
post #57

Earlier quoted context omitted.

What about variables nested within these functions then? Is scope enforced? i.e. you can reach back to variable aa in function a() from nested d() but can't reach variable dd in d() from a()?

I have no idea how it actually works, but it would be easy enough to implement by having nested functions take a parameter that's a pointer to a structure containing the variables that are in scope in the outer function. In your example, it could be something like this: struct variables_in_a_that_are_visible_in_d { int aa; }; void d_nested_in_a(struct variables_in_a_that_are_visible_in_d *ascope) { // Variable dd, no…

If you know the stack layout, you don't need to do the pack/unpack. You can define the struct to match the stack layout and pass a pointer into the stack instead.

The struct may have holes that contain variables that aren't used by the nested function, but that doesn't matter. Also, you would have to make sure to flush values from registers onto the stack, and, depending on the ABI, would have to explicitly push arguments passed in registers onto the stack (that would have the struct contain a return address, but that's not a problem, either), if you need them to pass arguments to the nested function.

Re: What makes Nim practical?

#122
post #93

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

Sure, just don't use it then.

Re: What makes Nim practical?

#123

Earlier quoted context omitted.

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.

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/

It's not quite the same I think. The format is very similar, yes, and I think it'd be nice if the PEX program could be made to work with this PEP. However, the PEX program bundles dependencies, which this PEP doesn't seem to be explicitly about.

Re: What makes Nim practical?

#124
post #104
post #39

Earlier quoted context omitted.

> - No block comments, save for `discard """ ... """` I believe a different syntax for those will be added soon: https://github.com/Araq/Nim/issues/1535

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)

You know, we used to mock the Java people for requiring fancy IDEs to work around deficiencies in their language. Now, in Nim, we're designing these warts into the language from the start?

Re: What makes Nim practical?

#125
post #109
post #106

Earlier quoted context omitted.

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.

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.

I did not do my homework. I know neither Rust nor Nim. So I'm inclined to take your word for it :)

Re: What makes Nim practical?

#126
post #21
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…

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;}

Re: What makes Nim practical?

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

Re: What makes Nim practical?

#128

Earlier quoted context omitted.

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

I've read both the submission and the articles that exist inside that Quora link you posted and I am still not convinced. IMO what makes a language better is end products and not features. When Rust becomes stable, its community will produce great software but I don't think all of the rest languages you mentioned have produced (or will do) better software than Docker, Kubernetes, OpenShift, etcd, btcd, and a ton of o…

> IMO what makes a language better is end products and not features.

It's useful to distinguish between "the language" and "the tool". Some programming languages are terrible from a language design perspective (PHP, JavaScript, MATLAB), but they still have great tools (IDEs, build tools, package managers) and libraries to help programmers create good and interesting software.

Re: What makes Nim practical?

#129
post #58

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)

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

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.

Re: What makes Nim practical?

#130
post #35

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

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

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