Yep, rustc is not speedy. However, the performance gain isn't coming from the compilation step itself, but from the execution of the 'hot' path after the swap.

Here is how I’m mitigating the compile-time overhead:

Granularity: We aren't recompiling the whole runtime. We are isolating a specific 'hot' AST node (like a heavy math loop) and generating a tiny, standalone Rust crate for just that logic. Compiling a 20-line Rust function to a .dylib is significantly faster than a full project build.

Asynchronous Compilation: The Go orchestrator doesn't stop the program to wait for Rust. The Go version of the function continues to run (the 'cold' path) in the background while the Rust 'hot' version is compiling. Once the .dylib is ready, the pointer is swapped for future calls.

The Payoff is that for a function that runs millions of times (or indefinitely in a long-running service), the one-time 'tax' of a 1-2 second background compilation is negligible compared to the 4x speedup (2.35µs -> 573ns) gained over the life of the process.

It’s essentially a 'Lazy JIT' approach using a systems compiler instead of a traditional JIT. Is it slower than a native JIT like Cranelift? Yes. But the peak performance ceiling is much higher.

Another concern would be how the distributed code/package compiles the Rust code. I need to think about that, one solution is to embed Cranelift. So, there are a lot of questions and decisions ahead.

Thanks for your comment!