- We are a blockchain company and close partner with the Ethereum Foundation. Ethereum research is done in Python, using Nim allows to quickly transcribe research to fast code.
- We focus on resource-restricted devices; for now mobile phone but running a blockchain node on a router might make sense in the future as well, so we need tight control over memory allocation.
- We can reuse C and C++ tooling (Valgrind, LLVM Sanitizers, gdb, lldb)
- The biggest bottleneck we have (and all Ethereum clients have) is cryptography, using Nim means being able to reuse cryptographic libraries written in C or C++ or even using C++ templates with one of the easiest FFI or rolling our own implementation.
- WASM is going to be very important for blockchain development and the most important thing is generated codesize (because it lives forever in the blockchain), Go and Rust struggles with WASM codesize at the moment. Nim is very good at that: https://www.youtube.com/watch?v=QtsCwRjtbrQ
- Being the main sponsor of a language means also being able to shape it suitable for our needs from scratch.
So this was why we started using Nim in the first place.
The Nim team was started 2 years ago and the experiment is successful. For example, our Ethereum client was kickstarted by translating python to Nim with an automated tool: https://github.com/metacraft-labs/py2nim.
Our main go codebase is supporting our own fork of the major Etehreum client go-ethereum. But this is costly for us as upstream and our teams have different goals. Now that the Nim Ethereum client is more mature, moving completely to Nim with a homegrown clients will allow us to have better API, better logging, controlled release cycles and avoid the cost of syncing with upstream.
The smallest wasm binary produced by rustc is ~110 bytes, Rust struggles with this far, far less than Go, or any language that has a significant runtime.
This doesn’t mean that the rest of your reasons are invalid, of course.
to be honest: the py2nim original tool was used for some initial transpiling experiments, but i am not sure how much of it ended in the actual codebase, the tech surely has more potential if developed
