That was a great read. All that linker wrangling is sure to break on the next version of go/rust/linker isn't it?<p>I wonder if it would have been easier to disassemble the rust binary and turn it into Go assembly and use that.<p>That would need a fairly complicated program to process the binary back into assembler. Maybe getting the rust compiler to output assembly and processing into Go assembly would be the way.<p>Using Go assembly would save fighting with the linker, be more likely to survive upgrades and it would be cross platform (well at least on platforms with the same CPU arch).
lol I remember looking at this when doing our major port from Go to Rust. I noped out once I saw the raw assembly portion. Great for a side project but probably not the move for a cross platform binary run by thousands of people. Still a very cool post and the literature for Go/Rust interop is def lacking
<a href="https://github.com/petermattis/fastcgo">https://github.com/petermattis/fastcgo</a>, which is now 7 years old seems to do something similar without the need to about obscure CGO FFI configuration. It also seems to be more generally applicable for any language with C interop.<p>There had been an issue for having something similar in the language itself - <a href="https://github.com/golang/go/issues/42469">https://github.com/golang/go/issues/42469</a>, but the Golang compiler team rejected it. If you have followed similar discussions around this with the Golang compiler team, you will notice a pattern of interaction that strongly indicates that they are very much opposed to ever accepting this into the compiler.
it makes me think about <a href="https://news.ycombinator.com/item?id=41117749">https://news.ycombinator.com/item?id=41117749</a> it is the mirror of this project: effient wal to call Go from Rust
What is the benefit of this?<p>I was under the impression that go isn't that far off from rust on most speed metrics being both compiled. So this adds complexity for what gain?