In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.
In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.
That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural.
Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.
Should you want to give that script a nice, traditional CLI then you can do so with very low effort using https://github.com/c-blake/cligen
Should you want "script like" edit-test development cycle ergonomics you can use the TinyCC/tcc backend for compiles in ~200..300 milliseconds. Once it's how you like it you can compile with gcc & -d:danger for max performance in deployment.
Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.
This is simply not true. Rust borrow checker has no notion of memory models: i.e. sequential consistency, acquire, release or relaxed semantics.
The Tokio team needs an additional model checker to ensure no data race in Tokio:
- https://github.com/tokio-rs/loom
If you want to ensure no data races you need formal verification not a borrow checker, I've compiled my research and a RFC for Nim formal verification here: