Just pushed a project that might be of interest to people - https://github.com/arnetheduck/nbindgen - makes it easy to generate a nim "header" file for rust libraries meaning you can call rust code easily from your nim code.
It's a nice combo - there are many really good rust libraries out there that are written with safety, efficiency and stability in mind - specially in the crypto / low-level library space - https://github.com/scipr-lab/zexe is a pretty cool example.
Long story short, rust has features to define a C-compatible exported API/ABI which you can consume from any language you can consume C from. Just like C, when compiled, rust outputs a static or shared library. To access the library from C, you usually use a header file that describes the ABI to the C compiler and this header can be generated from the rust code using a tool called cbindgen. nbindgen is a port of cbindgen, and instead of writing a C .h file, it writes a .nim that describes the library to the nim compiler.
Both rust and nlvm use llvm as a backend - a natural next step would be to enable LTO so that the two languages are optimized together - this is pretty cool because the pieces are all there to get cross-language inlining, constant propagation and other neat optimizations :) Neat little weekend project if you have too much time on your hands..
Have fun!
Great project didn't had time to look for this yet.
Is there some recommended way to use rust in a nim library, maybe in some nimble package? I was thinking about wrapping a rust library (wry) to nim. I guess you would need to install rust first, maybe add it as package dependency in the .nimble file, then build your .lib / .so / .dll file from rust code with the rust compiler as external cmd call and then link it with some nim code.
Would this be too complicated?
rust is generally very easy to use from Nim, just like C - there's no GC or or other weird things involved and the language has tools to support the C ABI - sometimes you might need to write a "export module" that exports functions in a C-friendly way (no name mangling, C ABI layout for structs etc) - just like C++, it's often easier to export a C ABI than to try to use it directly.
For those that are curious, RLN are rate-limiting nullifiers - a zero-knoledge based rate limiter (aka spam protection) in a way that doesn't reveal the sender of the message until they break the rate limit - at that point they also lose an economic stake they've earlier put up - it's a pretty cool system.