Live data from Hacker News

Nim 1.6

nim-lang.org

41–50 of 179 posts

Re: Nim 1.6

#41

> Why use Nim? > One language to rule them all: from shell scripting to web frontend and backend, scientific computing, deep learning, blockchain client, gamedev, embedded, see also some companies using Nim. Does that work in practice? I can't really imagine a single language that would be a good choice for "everything".

> I can't really imagine a single language that would be a good choice for "everything".

Full stack Javascript enthusiasts are nowhere to be seen in this thread, but are writing their backend, frontend, desktop and mobile JS, WASM, Ethereum backend and the next ARM instruction set to speed up JS code natively, silently working towards total world domination. The nanomachines that will bring forth the end of the world will be running Node.js.

But I agree with you.

Re: Nim 1.6

#42
post #38

Earlier quoted context omitted.

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For so…

> who needs interpretation when compile times are that fast! Well, interpretation is pretty useful for a REPL. And a REPL is not just useful to avoid compilation, but also as a way to explore a new API. And, most importantly, to preserve the results of long computations when you do not know yet what to do with it. If computing a value takes half an hour, you certainly don't want to recompute it each time you change s…

This is exactly right. What is the REPL story with NIM? Having used a REPL, I cannot even imagine doing research & analytics without one.

FWIW, this comparison between R, Pandas and Nim dataframes is quite encouraging: https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d20...

This is one of the aspects that self professed R/Python datascience contenders often get wrong. The very bare minimum is a well supported and thought out dataframe library. Without that, the language is basically dead in the water. Nim seems to have a very well thought out API that also avoids many of the annoying aspects of Pandas (e.g. the huge waste coming from eagerly computing each vectorized operation into separate arrays).

Re: Nim 1.6

#43

>Nim made its first entry in TIOBE index in 2017 at position 129, last year it entered the top-100, and for 2 months the top-50 (link). We hope this release will reinforce this trend, building on Nim’s core strengths: I wonder if it has chances to ever enter top 20.

why use tiobe when it is so clearly a bad metric? Pypl or the ieee index are much more reliable.

Re: Nim 1.6

#44
post #38

Earlier quoted context omitted.

> who needs interpretation when compile times are that fast! Well, interpretation is pretty useful for a REPL. And a REPL is not just useful to avoid compilation, but also as a way to explore a new API. And, most importantly, to preserve the results of long computations when you do not know yet what to do with it. If computing a value takes half an hour, you certainly don't want to recompute it each time you change s…

This is exactly right. What is the REPL story with NIM? Having used a REPL, I cannot even imagine doing research & analytics without one. FWIW, this comparison between R, Pandas and Nim dataframes is quite encouraging: https://gist.github.com/Vindaar/6908c038707c7d8293049edb3d20... This is one of the aspects that self professed R/Python datascience contenders often get wrong. The very bare minimum is a well supported…

My statement was mostly an exaggeration, than an absolute truth. REPLs are really nice, but it's story with Nim is less nice.

There is: https://github.com/inim-repl/INim and the builtin `nim secret`.

There is also a Jupyter kernel: https://github.com/stisa/jupyternim

Re: Nim 1.6

#45
post #7

Earlier quoted context omitted.

Thanks I’ll check it out.

Once you're done with that one you can go on with more advanced subjects here: https://www.youtube.com/watch?v=cISmv0IGoQQ From around 1:00 pointers are being discussed.

Cute but disappointing.

Re: Nim 1.6

#46
post #38

Earlier quoted context omitted.

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!): * Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell * Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library. * Backend: For so…

> who needs interpretation when compile times are that fast! Well, interpretation is pretty useful for a REPL. And a REPL is not just useful to avoid compilation, but also as a way to explore a new API. And, most importantly, to preserve the results of long computations when you do not know yet what to do with it. If computing a value takes half an hour, you certainly don't want to recompute it each time you change s…

See my comment from the other reply on this question for potential solutions, but as an fyi for those curious, Nim does come with a VIM that comes in very handy for such purposes: https://nim-lang.org/docs/nims.html

Re: Nim 1.6

#47
post #25

Earlier quoted context omitted.

As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?

Of course it is. It's descriptive and searchable. Because * / - + is the common ground that essentially everyone is familiar with. And that's about as much math notation as makes sense in general purpose programming languages. There is only one math but many programming languages. Multiplication is universal and fundamental. Creating JSON objects in nim is the opposite of that.

> Of course it is. It's descriptive and searchable.

If I entered "nim json" into google I'd get thousands of results for the language and json in general, and no way to narrow it down to meaning the operator "JON". That's not really what searchable means.

Re: Nim 1.6

#48

> Why use Nim? > One language to rule them all: from shell scripting to web frontend and backend, scientific computing, deep learning, blockchain client, gamedev, embedded, see also some companies using Nim. Does that work in practice? I can't really imagine a single language that would be a good choice for "everything".

I think Nim is in the sweet spot for it. You start with basically OCaml, which is already a great start, add some knobs for tweaking memory management, some for high performance, and you're in a great places. Compiling to native and to JS allows you to do web, cli tooling, applications, high level gamedev. Fast compilation is important for scripting, high level gamedev, exploratory programming, scripting. High performance allows you to do low level gamedev, deep learning, stuff like that. Being bootstapable from C and compiling to it with the memory management tweaks opens you the world of embedded.

There's also the fact that not all language are perfect. If they all are, the general language would always lose to the specific in every niche, so you need to do different things for the general to be worth. But languages aren't perfect, and you could prefer the general language even in niches.

Re: Nim 1.6

#49
post #2

I don’t know much about Nim, does it have a mandatory gc, like go? How good is Nim’s gc? Those who have written some Go and Nim, home does the code look like vs go?

Nim can be mark/sweep collected but also has a collector called ORC that's reference counting plus a version of the Recyler algorithm for cycle collection.

ORC turns out to be rather nice to use: https://nim-lang.org/blog/2020/12/08/introducing-orc.html

Re: Nim 1.6

#50
post #25

Earlier quoted context omitted.

As if "json" is any more searchable. Operators have a meaning that you learn quickly when learning the language. You wouldn't do math with "multiply" instead of "*", so why would you want that in a programming language?

Because with a keyword the meaning is much more explicit, and I consider that to be more valuable. And I think "*" is a bad example because pretty much everyone who programs already knows it's multiplication.

It might not be the best example, but the point stands. Succinct notation is important. "JSON" instead of "%*" might not be the greatest of examples but still.
Post reply on HN