6 ms·
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
by sp33der89 5y ago
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 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!
- MrBuddyCasino 5y ago> 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 5y agoMaybe 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/faq.html https://nim-lang.org/docs/nimc.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).
- carlmr 5y agoDo 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 5y agono, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler
- carlmr 5y agoAh ok, that's fair then.
- MrBuddyCasino 5y agoNothing says "realistic benchmark" quite like the "-d:danger" flag.
- michaelsbradley 5y agoIf 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.
- goodpoint 5y agoIt'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 5y agoI 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".
- dom96 5y agoI'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?
- formerly_proven 5y agoRust should be able to elide more checks than most other languages without impacting safety.
- shirleyquirk 5y agowhich 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 5y agoI'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 5y agoThere are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.
- MrBuddyCasino 5y agoYes the benchmark against Crystal was heavy on strings (json & base64) and Crystal seems to do better there. Whats the reason, Nim using refcounting?
- michaelsbradley 5y agoTooling 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 https://github.com/PMunch/nimlsp#readme [2] https://github.com/emacs-lsp/lsp-mode#readme https://github.com/emacs-lsp/lsp-mode#readme
- sp33der89 5y agoLast 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!