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

Nim 1.6

nim-lang.org

Post reply on HN
Print view View original

61–70 of 179 posts

Re: Nim 1.6

#61

Post by mumblemumble »

turminal wrote: post #18

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

The probable gaps I see are embedded and certain branches of gamedev, and shell scripting. Regardless of what Nim says in its sales pitch, it is a garbage collected language, and garbage collection is not really optional. The closest options are nothing, automatic reference counting (ARC), and automatic reference counting with cycle deletion (Nim calls this one ORC).

Nothing at all might be fine for cloud lambda functions and command line utilities, but it generally isn't acceptable for long-running processes such as video games and firmware. ARC will still leak memory when there are cycles, so it can work if you are very careful about how you manage data. But it's trickier than what you get out of modern C++, and more resource-hungry than full manual memory management, so I can't really see this option being ideal for gamedev or embedded. And ORC is basically just Python's garbage collection algorithm, with all its strengths and weaknesses.

For shell scripting, at the end of the day, it is still a statically typed, compiled language. This just doesn't hit the sweet spot for a scripting language. In that context, the performance of the language itself doesn't really matter, the entire operating context is irredeemably weakly typed, and nothing you do will ever grow large enough for static types to help much with maintainability. I'd much rather have the fast edit-test cycles of an interpreted dynamic language.

That said, what I have successfully used Nim for is writing command-line tools that I interact with from shell scripts. But there, it's not replacing sh or perl or python, it's replacing C.

Re: Nim 1.6

#62

Post by PMunch »

wiremine wrote: post #55

I learned Nim last year by rewriting some of the core Arduino functionality in C, and then wrapping them in Nim. (I also wanted to better learn C and better understand how Arduino's internals work, thus the convoluted approach) A few observations: * The community was very helpful and responsive. I identified a bug in compiling Nim to bare metal C, and it was fixed in 24 hours. * The C/Nim bindings were a breeze to us…

Oh it definitely can run on those devices! I wrote my own keyboard firmware from scratch in Nim, and the firmware sizes are vanishingly small compared to even simple "hello world" level stuff in Arduino. I did a talk on it for NimConf2021: https://www.youtube.com/watch?v=dcHEhO4J29U

Re: Nim 1.6

#63

Post by chubot »

rattray wrote: post #52
sph wrote: post #41

Earlier quoted context omitted.

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

JS is also great for scripting, but really isn't popular for ML or data science (no pandas/numpy/scipy equivalents I think, other than tensorflow.js). I'm curious how Nim fares for DS/ML.

JS is also not fast enough at string manipulation to express its own dev tools, at least if you want to build in seconds and not minutes.

The latest incarnation of JS tools seem to be written in Go and Rust (esbuild and another one), not JS.

GC is an issue for compilers, or even just front ends, which create huge, fine-grained, linked data structures

Re: Nim 1.6

#64

Post by pietroppeter »

adgjlsfhk1 wrote: post #43
DeathArrow wrote: post #16

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

well, because Nim is neither in Pypl [1] nor in ieee index [2] yet... :)

[1]: https://pypl.github.io/PYPL.html

[2]: https://spectrum.ieee.org/top-programming-languages/

Re: Nim 1.6

#65

Post by mumblemumble »

wiremine wrote: post #55

I learned Nim last year by rewriting some of the core Arduino functionality in C, and then wrapping them in Nim. (I also wanted to better learn C and better understand how Arduino's internals work, thus the convoluted approach) A few observations: * The community was very helpful and responsive. I identified a bug in compiling Nim to bare metal C, and it was fixed in 24 hours. * The C/Nim bindings were a breeze to us…

I have decided that meaningful whitespace is an anachronism.

20 years ago, I liked it a lot.

Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. And, since the whitespace is significant, it ends up being one more potential source of bugs.

I also don't love love love that (at least with the keys I know well) significant whitespace is more awkward to edit with vanilla vim than curly braces and parens are.

Re: Nim 1.6

#66

Post by PMunch »

mumblemumble wrote: post #61
turminal wrote: post #18

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

The probable gaps I see are embedded and certain branches of gamedev, and shell scripting. Regardless of what Nim says in its sales pitch, it is a garbage collected language, and garbage collection is not really optional. The closest options are nothing, automatic reference counting (ARC), and automatic reference counting with cycle deletion (Nim calls this one ORC). Nothing at all might be fine for cloud lambda func…

Nim works super well for embedded. The thing is that you can turn off the garbage collector and do manual memory allocation if you want to. Or simply use ARC which works a treat on embedded. I wrote my own keyboard firmware in Nim (and did a presentation of it during NimConf 2021: https://www.youtube.com/watch?v=dcHEhO4J29U). It runs super fast and the code size is smaller than some simple "Hello world" level programs using the Arduino system.

As for gamedev the ability to tune the GC by turning off automatic collection and then running it with a time-limit is perfect for preventing lag-spikes when a lot of stuff is going on (looking at you Java..). Nim actually performs very well, and the garbage collector does a great job of just getting out of the way and letting your programs fly.

Your point about shell-scripting is kind of valid, it is indeed a weakly typed world. But with how fast Nim compiles the edit-test cycle feels as fast as Python, and you save a lot of time from having a silly typo that you only encounter after having run your script for a little while.

The reason why Nim is good for pretty much anything is that the speed of the compiler and the garbage collection will rarely if ever stand in your way, and the flexibility of the syntax that stems from meta-programming allows it to be molded perfectly to the use-case.

Re: Nim 1.6

#67

Post by mixedCase »

dunefox wrote: post #25
clusterfish wrote: post #17

Earlier quoted context omitted.

Could have just used a "JSON" keyword instead. Symbolic names are needlessly obscure and unfriendly. Hard to infer meaning, hard to pronounce, hard to search online, etc.

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 there's no point in saving three characters (although I'd rather have it be "literal_json" or "inline_json") just to have people memorize what yet another symbol means in a highly specialized context when you could just read the word and be perfectly certain what the code means without looking it up the first time.

Even after the first time symbols have a non-trivial cognitive cost for a lot of people, if not most, all while providing near zero benefit unless your app is pretty much nothing but a bunch of inline json expansions.

Re: Nim 1.6

#68

Post by pchanda »

sph wrote: post #41
turminal wrote: post #18

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

Also this talk by Gary Bernhard: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Nim 1.6

#69

Post by rattray »

chubot wrote: post #63
rattray wrote: post #52

Earlier quoted context omitted.

JS is also great for scripting, but really isn't popular for ML or data science (no pandas/numpy/scipy equivalents I think, other than tensorflow.js). I'm curious how Nim fares for DS/ML.

JS is also not fast enough at string manipulation to express its own dev tools, at least if you want to build in seconds and not minutes. The latest incarnation of JS tools seem to be written in Go and Rust (esbuild and another one), not JS. GC is an issue for compilers, or even just front ends, which create huge, fine-grained, linked data structures

Sure, JS isn't ideal for compilers, but it is quite good - typescript is a better and more performant compiler than many languages have, as just one example.

You wouldn't be crazy for choosing JS for a new compiler project, even for work that had nothing to do with JavaScript.

(You would be pretty crazy to choose js to build a rich data science backend, in comparison).

I do agree the GC rules out some use-cases like many gaming applications.

Re: Nim 1.6

#70

Post by boardwaalk »

mumblemumble wrote: post #65
wiremine wrote: post #55

I learned Nim last year by rewriting some of the core Arduino functionality in C, and then wrapping them in Nim. (I also wanted to better learn C and better understand how Arduino's internals work, thus the convoluted approach) A few observations: * The community was very helpful and responsive. I identified a bug in compiling Nim to bare metal C, and it was fixed in 24 hours. * The C/Nim bindings were a breeze to us…

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot . Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. An…

Some counterpoints:

Your auto formatter can’t figure out where you missed braces either.

Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs.

Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

Post reply on HN