Do you know the reason for enabling compilation to WASIX?
We are not trying to push WASIX, we are trying to move forward sockets, threads, subprocesses so they can run fully in Wasm environments. And WASIX is the solution to that problem.
WASI Preview 2 on the other hand seems to be focused on other set of problems and doesn't solve any of the needs that got WASIX started in the first place.
So, in light of that, what is the reason for diverging from WASI and creating WASIX?
WASI Preview 2 still doesn't support threads, fork, subprocesses or longjmp/setjmp (among others). Not even that, when WASIX was created not even sockets were supported in WASI.
I'd recommend trying to compile bash or curl to WASI Preview 2 and WASIX and see how far you get in each before trying to polarize the readers between WASI Preview 2 and WASIX.
Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.
If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to follow standards.. not WASIX. I don't think anyone believes exposing POSIX fork() to WASM is a good idea, even if it lets you build existing apps 'without modification'.
Please stop accusing me of being polarizing. I just don't want to live in a world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall. I want good tech to win, not shitty power plays.
[0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...
[1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...
[2] https://bytecodealliance.org/articles/webassembly-the-update...
[3] https://github.com/bytecodealliance/wasmtime/pull/7285
[4] https://github.com/WebAssembly/shared-everything-threads
WASI Preview 2 doesn't officially support threads. There are some ways to get it running as you mentioned, but threads are NOT part of WASI Preview 2. Which is what you initially stated and I corrected.
We don't want to have competing standards either, and we'd love to merge things upstream. However, based on my interactions with the WASI subgroup it seems clear they want to keep some of this things that WASIX needs out of the spec (and that's ok!). If you would not like to have that, then you shall probably direct your requests towards them, not us.
> I want good tech to win
Me too! I now understand this over-idealistic belief is the root of the issue. Good tech doesn't win, a good product does.
I wrote more about this, if you are curious, here: https://wasmer.io/posts/is-not-about-wasm-is-about-what-you-...
Imagine you can safely assume that the formatter program will only have access to the directory you provide, and not anything outside of it (not even the network!).
In summary, Wasmer + WASIX is like Docker, but much more lightweight :)