[sp33der89]

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!

[michaelsbradley]

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

[sp33der89]

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!

[MrBuddyCasino]

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

[michaelsbradley]

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

[MrBuddyCasino]

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

[goodpoint]

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.

[MrBuddyCasino]

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

[goodpoint]

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

[dom96]

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

[shirleyquirk]

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

[michaelsbradley]

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.

[carlmr]

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.

[shirleyquirk]

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

[carlmr]

Ah ok, that's fair then.

[shirleyquirk]

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`

[MrBuddyCasino]

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.

[shirleyquirk]

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

[MrBuddyCasino]

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