As others have mentioned, it's too slow for what the author was trying to achieve. He had a section where he ruled out cgo for performance reasons, so if that's

As others have mentioned, it's too slow for what the author was trying to achieve. He had a section where he ruled out cgo for performance reasons, so if that's too slow, spawning a child process will be much slower. That may not matter for your use case, but the author is clearly aiming for almost no overhead considering how easy it is to use cgo to call into Rust. The thing that should probably be said is that the difficulty is all on the Go side. Rust doesn't have any of the clumsiness that Go has when interacting with other languages. It's fully fluent in the lingua-franca of FFI (C ABI). If you were integrating your Ruby, Node or Python code with Rust instead of Go, there are nice libraries [1][2][3] that make it simple, easy and very low overhead. For users of these scripting languages, Rust is a nice tool to keep in your back pocket to pull out in the rare cases that you're not getting the performance you need. It means being able to choose your tools based solely on developer ergonomics and existing team knowledge knowing that in the rare cases that you do need do something computationally intensive, you can drop to Rust, push everything through a Rayon parallel iterator, write the performance-sensitive logic and push the result back. It's also really useful to use Rust in environments like Lambda/Cloud Functions that only support those scripting languages since those environments tend to charge based on memory and CPU time and Rust makes it easy to get by with a minimum of both. [1] https://github.com/tildeio/helix https://github.com/tildeio/helix (Ruby) [2] https://github.com/neon-bindings/neon https://github.com/neon-bindings/neon (Node) [3] https://github.com/pyo3/pyo3 https://github.com/pyo3/pyo3 (Python)