Could we make a golang compiler to compile the golang source code to ape format?

[viscropst]

As title, the pure go binary is compiled into a full static linked binary. The ape is need a full static linked to one binary too. So, If we can make the golang's 9p assembler compiles to ape binary format, the golang will get a os-agnostic single file binary.

[polarathene]

I don't think it's anymore feasible than it is with other languages that compile to specific targets. See this comment on Rust, and this related discussion for Zig.

Cosmopolitan provides the platform-agnostic libc, which is great for C projects but AFAIK that doesn't fair well with languages like Zig, Rust, and Go, as they've got their own libc (or sometimes layered via an FFI bridge to say glibc/musl) and more notably optimize code to a given build target. Some packages in these languages will also switch out code based on the build target and this is a compile-time decision not runtime, so the support for other OS is lacking from the artifact output.

If you instead target an actual unified target like WASM (or WASI rather for broader feature set), you'll have an easier time due to a standardized common target that is in itself platform-agnostic. The produced .wasm regardless of language then needs a separate runtime that bridges an internal wasi-libc to any host functionality.

That runtime software is a platform-specific build for that OS and arch, with it's own libc suited for the host. This is something you could probably produce with cosmopolitan libc / APE to get a runtime that can be used across platform OS and arch, so long as it's not using source from one of the incompatible languages 😓

---

Alternatively instead of using an APE that bundles that runtime with your own .wasm program, the user could have the runtime installed already. It's no different to needing NodeJS or Python for example to run those programs (which likewise have their own alternatives to bundle into a single executable and I believe are APE compatible). In this sense your program (the .wasm file) is still platform-agnostic as desired, bundling the runtime into a single executable with the .wasm as data is just a convenience, and without that requirement you'd not need to deal with APE.

WASI is limited however, it doesn't have feature parity to what you can do with a native host libc (that cosmopolitan provides). In time this will improve, but it does avoid the much less desirable burden of carrying around hacky patches to get compatibility (which still doesn't solve all compatibility issues). If your project can run successfully as WASI I'd suggest pursuing that instead for these languages that don't quite fit well with the approach cosmo relies upon.