I wrote this in a text file more/less to capture my state of mind while moving forward from a pretty rough year, professionally speaking. I hope it might be helpful for anyone who's bewildered with the choices of languages on the market right now, and is in a process of soul searching while considering Nim to pin their personal or company's success upon.
After being jailed up in Ruby, Typescript, and the odd Golang project here and there over the last several years, I've come to the conclusion that I need to settle on a language that's closer to the metal and get rid of the cruft. I started out coding in the mid-90s and refocused my career on Bitcoin and crypto in 2016 after leaving a very large software company in Seattle. C was my first love, but it didn't last long before I was consumed by Java, Oracle, and Solaris.
After the crypto market's meltdown, it's time for me to go back to the drawing board. To get restarted I decided that I need a safe, fast, and statically typed language that can be compiled and targeted to both mobile and desktop environments, as well as being made available to scripting languages via FFI. After struggling with this decision for many years and being on the fence, I feel foolish for not having gone all-in on Nim when I first discovered it, and for having wasted a lot of time pushing higher level application code into the cloud and HSMs when what my industry needs most is to focus on self-custody and self-hosted solutions.
I purchased the excellent Nim in Action book when it first came out and wrote some toy programs. Being a Ruby guy, I stuck with Crystal for my side-projects, and Golang when I needed it, and Ruby for most everything else. I use a lot of C based gems and a lot of proprietary back-end code based on zmq and messagpack. Ruby is a great glue-ware, and I have scaled and studied MRI performance carefully since 2004 but it's a very old crutch, and the promises of a typed and compiled Ruby 3 seem to have been over-promised and under-delivered. A lot of big fintech still uses Ruby, including Coinbase and Stripe. I expect both of them to capitulate to Rust and other statically compiled languages, not that they really need to, but because of the industry optics and need to retain talent.
From the perspective of Nim, here are some broad comparisons to my short-list of candidate languages: Go, Crystal, Swift, and even mruby (whose intermediate .mrb binary is embeddable and callable from C). My runners up: Rust, Zig, and Dart. This isn't a highly scientific post full of esoteric details and language feature matrices. It's about making the best choice for what I can be the most productive in for my target market and product requirements.
Some specific nits to get out of the way:
Some definitive Nim wins for my use case are:
Runners up: Dart, Rust, & Zig.
Brief note on WASM compatibility.
I'm not keen on WASM, because I'm not that keen on web browsers / webview remaining the dominant UX for another 20 years. All of these languages have fine compatibility with WASM, but despite my wishes, Nim goes a step further and compiles directly to Javascript. This means that performant C intermediate code could be targeted to WASM, and shim code can be exported to Javascript - all without leaving the ergonomics of Nim. Potentially that means no RPC middleware required in web uses for me, which is very, very attractive.
Considered, didn't make the cut:
Final thoughts.
Coming back to Nim makes me kick myself a bit now in hindsight for being too timid to adopt it earlier. Sticking with Nim long term has no visible downsides. Two bonus points: 2) As of today, Status is one its primary corporate backers, having ported an Ethereum node fully to Nim, and open-sourcing the whole thing with good utilities also for EVM based tools. Those are solid wins for my use-cases. 2) Nim's v2 roadmap appears to be focused on embedded applications. For a tiny company that's working with cryptography and wants to safely target as many devices and environments as possible, this is a great thing. Mature tooling like valgrind and an array of fuzzers and other security based utilities work well on Nim binaries.
Hopefully this is useful to someone. Look forward to posting a bit more on the forum here in the months to come. cheers
I think in time with v2 we'll see great things from ORC.
This is the crux of it. With ORC, Nim is in a different category of languages now, and got there with almost no breaking changes in the process. Pretty remarkable to think about it. The plane's engine has been swapped mid-flight. If you want high level ergonomics in a language with C/C++/Rust perf, it is pretty much the only game in town.
JNI and the JVM's largesse isn't aging particularly well. It will die with my generation's retirement.
Not going to happen. The JVM is an easy target but it is a brilliant feat of engineering and solves very different problems than what Nim solves. It will be around for a very long time.
A few years back, I've spent a while coding some libraries with Nim, for a personal project. Eventually I stopped, bc I gave up on that project. The biggest issue I had with Nim then was "undecipherable" error messages/traces, both at compile time and at run-time. I wanted "amateur/junior coders" to be able to use my stuff, and "error messages you can't (easily) understand" greatly limit who can use that code.
How are things today? Have error messages/traces readability improved, or do you still need to look at the generated C code, and mentally map it back to the original Nim code, to understand what the compiler is trying to tell you?
Have error messages/traces readability improved, or do you still need to look at the generated C code, and mentally map it back to the original Nim code, to understand what the compiler is trying to tell you?
they improved, but you're overdramatising.
The only knock that static languages like nim/rust/go is in data science, I think - a fat, long-running runtime is actually an asset not a liability there - but don't forget about interactive use with https://github.com/inim-repl/INim!
Nimble's integration with inim is still much ahead of where other projects are, and though it's no secret that I've moved over to crab-driven-development day-to-day, I am delighted to see nim go from strength to strength, ORC, as @sekao says, is incredible, with no changes to the language from my point of view. Bravo.
The JVM is an easy target but it is a brilliant feat of engineering and solves very different problems than what Nim solves. It will be around for a very long time.
Computer history codger here. JVM stood on the shoulders of Forth and UCSD Pascal (among others) The Forth world explored different VM models although they didn't call them that. see: https://en.wikipedia.org/wiki/Threaded_code. https://en.wikipedia.org/wiki/Forth_(programming_language).
The token threaded code model influenced p-code for the UCSD Pascal environment which influenced JVM and then others. if history is any guide, JVM will mutate into something almost almost unrecognizable like forth and UCSD Pascal have.
Nim looks really nice but it too will mutate and adapt to technological and social trends. Someday some fanperson will say "it is a brilliant feat of engineering and solves very different problems than what XXX solves. It will be around for a very long time." I remember saying something like that myself a few times over the years. :-) I was always proved wrong.
it's not a productive way to have a discussion
True, but who argues online for the sake of productivity? 😂
Okay this post does it.
I agree that choosing a programming language to 'Get Sh!t done' is a perfectly reasonable goal, In my case any time I save with programming I can put it on managing my health issues.
I like that Nim has showcased that performance and cognitive hog needn't be mutually inclusive for a systems programming language. Looking for to build a project with it soon and for wider community participation.
Thank you for posting.