nimjl VS Stan.jl

While indeed we are less people developing stuff in Nim compared to even the Julia community (which itself is of course much smaller than say Python), we do have cover a large amount of the typical needs in the scientific computing domain. And where we miss stuff it's a) easy to wrap C/C++ or b) simply call Julia, R or Python (As a personal reference I'm doing data analysis & numerical physics stuff in context of my PhD in physics and I literally do everything in Nim. The only significant C dependency {and only as a shared lib} I depend on is libhdf5 via nimhdf5).

use nimjl to access the Julia bindings

To add to that, there's also a Nim <-> Julia bridge: https://github.com/clonkk/nimjl

c2nim is a tool to translate ANSI C code to Nim. The output is human-readable Nim code that is meant to be tweaked by hand after the translation process. If you are tired of wrapping C library, you can try futhark which supports "simply import C header files directly into Nim". Similar to futhark, cinterop allows one to interop with C/C++ code without having to create wrappers. nimLUA is a glue code generator to bind Nim and Lua together using Nim's powerful macro. nimpy and nimporter is a bridge between Nim and Python. rnim is a bridge between R and Nim. nimjl is a bridge between Nim and Julia! Last but not least, genny generates a shared library and bindings for many languages such as Python, Node.js, C.

However, from a quick look at the Julia bindings it seems like those are just wrapping cmdstan, i.e. accessing it via the official shell interface as an external process. That would be easy enough from Nim as well.