The ability to build a single static binary that works on Linux, Mac and Windows using Go would be life changing for the internal tools I develop at work.
Just curious, life changing in what way? Obviously, 1 is better than 3, but I'm wondering if there is some other interesting reason.
Though doesn’t convert the WASM to C, it runs the WASM in Wazero instead.
You're suggesting compiling Go to Wasm (presumably using the wasip1 target?), then converting that to C using wabt, then using Cosmopolitan to create an APE… is that it?
Well, that's not going to work.
First of all, Go's wasip1 target doesn't even support cgo, so if you want SQLite, you're dead right there.
Then, even if you used say TinyGo (which might support cgo, not sure), WASI just isn't a great target to compile SQLite into. WASI is a pretty limited syscall layer. You'd end up with no file locking, no shared memory. Also no threads.
Then, on top of that, you'd layer Cosmopolitan issues. Having written a portable SQLite VFS from scratch, I am not impressed with how they just paper over file locking semantics incompatibilities between OSes, and then confidently ship a forking webserver with SQLite bundled in. It takes a certain temerity, and not running many SQLite torture tests.
Wasm as an intermediate target is great for (single threaded) CPU stuff. WASI is great if you can fit it, but otherwise, it's not, not really.
Once upon at time, static linking was the only thing OSes were capable of, all of them moved away from that, and there is no turning back outside embedded bare metal deployments, just become some people are obsessed with static linking.
You're welcome to ignore it of course, it's just unofficial and a large pain.
How do you mean? Like, is it possible to run such binaries on M1? If so I'd really like to know how
Alternatively, Linux :).