document n0's recommended approach for golang integration

[cblgh]

hey all! thanks for the excellent work on making iroh accessible outside of the rust ecosystem! personally i find golang to be a great development environment and will likely use iroh from it in the not-too-distant future.

i had to dig through the git history to figure out your position regarding golang. and it's totally understandable! but i think to help future developers with an inclination like mine (and prevent repeat questions) it would be great to document your recommendations here in the ffi/sdk repo.

for future reference, here's the commit where it was removed with the stated rationale:

We found that in practice our support for go is just far too cumbersome. Go doesn't take well to CGO dependencies to begin with, and integrating such a thing at the networking layer just isn't worth it.

Go projects that want to interact with iroh should consider standing up a separate binary & communicating over a network-backed RPC protocol of their own design.

---

finally, i'd like to mention that it is possible for app devs writing go to embed the relevant binaries per platform using the embed package, dumping the executable on first run and calling it somehow for all one's networking needs :^]

for example: given an executable named iroh in the same directory as the source code:

package main

import (
        _ "embed"
        "fmt"
        "os"
)

//go:embed iroh
var program []byte

func main () {
        err := os.WriteFile("iroh", program, 0777)
        if err != nil {
                fmt.Println(err)
        }
        // etc
}

[cblgh]

as someone brought up in the n0 / iroh discord, another avenue to explore would be to use a golang wasm runtime to execute the forthcoming iroh wasm core.

• https://github.com/ncruces/go-sqlite3 -- an example of sqlite3 running in go thanks to a new golang wasm runtime
• https://wazero.io/community/users/ -- the wasm runtime

[matheus23]

Wazero uses the WASI standard to provide syscalls like network IO to the Wasm guest. Our current plan with iroh + Wasm is to make iroh-net run in the browser, which does not provide any syscalls like that by default, and it'd depend on wasm-bindgen, which means there's some host javascript required to use the iroh-net Wasm.

That said, getting iroh-net working in the browser is actually a bigger undertaking that getting it working with wasm-wasi, and we'll likely look at that in the future, too.