Hi and thank you for your kind words!
I think @mlugg gave a great reply, so I’ll just add an even more simplified (albeit a bit hand-wavy) version for your convenience: it could be totally possible to move around the comptime logic in the Zig standard library to make it work with a special “multiplatform-c” target, it would just require a lot of work. By targeting wasm32-wasi we create a simple executable that just so happens to push all that platform-specific logic to the edge of the system (ie the interpreter, as the wasm blob expects to be provided with functions that can open files, print to stdout, etc).
So by targeting wasm32-wasi we get “for free” something comparable to the manual work I mentioned in the beginning.
The fact that the WASI is precompiled to C vs being run in a VM is just an implementation detail that has to do with performance. From a functional perspective, when running the WASM in an interpreter, the interpreter needs to provide the aforementioned I/O functions, while in the case of C precompilation, it’s up to us to provide it with the same I/O functions, just with the caveat that those functions need to work on the target machine.
So how do we achieve this last part? By writing those functions by hand as good old fashioned portable C code, as you can see here:
The reason why this works in practice, is because the wasm Zig binary is very simple and doesn’t even need all the APIs that WASI specifies, just the ones that the compiler needs to compile itself. Maintaining this file is pretty easy once you’ve written it once (at the moment of writing this file hasn’t been touched in 7 months), which is immensely easier than a solution that messes around with the Zig standard library.
Hopefully that helps you get an intuition for what’s going on.