It also compiles to JS.
The grandparent's scientific/Go interests suggests a need for a large, working ecosystem and there are probably several places in ArrayMancer which need some love for "fallback cases" to work with tcc (or elsewhere in the as you note much smaller Nim eco-system).
EDIT: E.g., commenting out the `io_image` import/export in src/arraymancer/io.nim makes almost all of ArrayMancer's tests pass. That comes from a problem with its use of the Nim stb_image binding which tries to #include <emmintrin.h> with its vendored in stb_image.h. No idea if the stb_image.h maintainer has added a non-SIMD fallback case. And, of course, to optimize compile times, just generally speaking you will want to import only exactly what you really need which does take more time/thought.
I try to learn the basics of new programming language regularly and write a small lisp alike interpreter in it and give myself a maximum of 2 days working on it. It covers things like string handling, regexp, recursion, lambdas, garbage collection, ... and run them through a tiny test suite.
In Python and JS, it was easy to do it and the code was still very readable. In C++, the language I earn my money from, I had a bug I was not able to fix within the given time frame, happening just with gcc not clang, assuming some undefined behavior. In C, I was able to add my own garbage collector with muss less work than I expected ... but
Nim really impressed me, it really felt almost like I wrote it in Python, but an executable which run on its own and being quite a bit faster.
Working mostly in the embedded world, where ecosystem matters somewhat less. If any employee ever would give me a chance to choose a language myself I would definitely try to write a first prototype in Nim.
[1] https://nim-lang.org/