You might be able to even compile Go as a static library and embed it in your binary instead of carrying a .so file around. Regardless, Go's FFI story (especially in that direction) is hobbled and you can't do things like share structs easily (for obvious reasons, but still annoying). But yes, as soon as you get to C-level, you can mix and match anything and write about it. Running Go in Rust, or Rust in Go, or Go in JS, or whatever.
What would really be neat is to leverage Graal's polyglot iface a bit higher. I am not sure the status of llgo these days, but compile Go to LLVM bitcode and then leverage that from Java and compile to a single binary. Or even expose Go's awesome stdlib to JVM developers that way. But the practicality of doing some of these things becomes a bit lost beyond toy use.
Yeah, Making use of Graal’s polyglot interface would be better, but I did not have much luck to compile Go to LLVM, as I am not so familiar, but would try that soon more intensely.
Word. Another fun transpiling project I have been mulling over is a Go-to-Kotlin transpiler. With Kotlin coroutines (and accompanying kotlinx lib) I think it has the entire feature set covered though duck typing requires a creative solution but it's not too bad.
Keeping on the non-practical, fun note, I wrote a transpiler in the other direction[0]. It compiles Java bytecode to Go code. It works decently actually but I stopped work on it because my approach strains the Go compiler too much[1]. I even started emulating some of the base Java calls as Go calls, but that became tedious too.
What would really be neat is to leverage Graal's polyglot iface a bit higher. I am not sure the status of llgo these days, but compile Go to LLVM bitcode and then leverage that from Java and compile to a single binary. Or even expose Go's awesome stdlib to JVM developers that way. But the practicality of doing some of these things becomes a bit lost beyond toy use.