Hacker News Reader

Comment by sp33der89 | Hacker News Reader

For me it's the intersection of performance like Rust, the readability like Python, the ability to generate native executables without dependencies like Go and a very cool type system. All while delivering fast compile speeds!

The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials.

Some downsides: not a big ecosystem(tho can piggyback off C libraries) and tooling isn't great.

Advent of Code would be a great way to dip your toes into a language you might not really care about!

View on HN

Tooling has been a weak point, but it's getting better. I've been having a pretty good time of late with nimlsp[1] plus Emacs and lsp-mode[2].

[1] https://github.com/PMunch/nimlsp#readme

[2] https://github.com/emacs-lsp/lsp-mode#readme

Last time I tried nimlsp was in June-ish, using neovim. It was an okay experience, but things broke down quickly when using macros and I got red squigglies everywhere because things rely on a certain setting. Compared to the VSCode experience, it's really lacking though.

It's certainly been getting better and the focus is also on tooling, so I'm hopeful!

> performance like Rust

I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang.

Fast enough for sure, but "half the speed of C" would be more honest it seems?

Maybe so, but sometimes benchmarkers forget to employ compiler options like:

   nim c -d:danger -d:lto --opt:speed

ymmv

https://nim-lang.org/faq.html

https://nim-lang.org/docs/nimc.html

Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).

Nothing says "realistic benchmark" quite like the "-d:danger" flag.

If you're going into production with Nim code and execution speed is a top concern, you're probably going to remove all the safety belts after thoroughly testing, valgrind'ing, etc., i.e. you're probably going to opt for -d:danger instead of -d:release. But maybe not, depends on the project I guess.

It's the normal compilation flag for performant code.

The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.

I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture.

What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".

I'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?

Rust should be able to elide more checks than most other languages without impacting safety.

That's the assumption, but that doesn't mean it's the case. Certainly bounds checks are impossible to prove at compile-time.

What language are you talking about?

Rust doesn’t have a compiler flag for this, instead it has separate functions that don’t do the checking. E.g. Vec has a .get_unchecked function.

Such functions can only be used in an unsafe block, and should only be used if bounds checking is handled elsewhere such that it would be impossible to cause an out of bounds error at runtime.

It’s also often possible to get rust to elide bounds checks by using iterators, which often don’t need them as they know the length up front.

"disable all brakes" is misleading. All the basic memory safety stays, static typing is still there, non-debug assertions are still checked.

Removing debugging features is reasonable for such benchmarks, especially if comparing with languages that don't have them.

Another poster claimed it disables bounds checks, you claim it still offers basic memory safety. That sounds like a contradiction to me.

leaving (e.g.)runtime overflow checks turned on in the Nim code would not be a realistic comparison against C

Do these activate -funsafe-math on the underlying C compiler? Because if so that's not a fair comparison, since this breaks a lot of code.

no, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler

Ah ok, that's fair then.

which benchmarks? I play the language benchmark game sometimes and I can always get within 10% of the fastest contender. Beating the fastest contender,though, is rarely possible without using the unsafe subset of Nim, hence `-d:danger`

I've digged some more, and indeed in numeric tests Nim is often close to C. Its hard to find good data though, with documented compiler flags and recent versions.

There are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.

Yes the benchmark against Crystal was heavy on strings (json & base64) and Crystal seems to do better there. Whats the reason, Nim using refcounting?

Reply on news.ycombinator.com