11 ms·

Do you know the reason for enabling compilation to WASIX?

syrusakbary 3y ago
WASIX will enable to run biome fully sandboxed at close to native speeds. 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 :)
slimsag 3y ago
The parent poster (syrusakbary) is the CEO of Wasmer and trying to push WASIX, a quasi-proprietary 'open standard' while it seems the rest of the WASM ecosystem is in fact moving to WASI preview 2 [0] [0] https://news.ycombinator.com/item?id=37545670 https://news.ycombinator.com/item?id=37545670
- intelVISA 3y ago
  Extend, Embezzle, Escape
- syrusakbary 3y ago
  I think you may be a bit confused on what's the purpose behind WASIX, Stephen. And you are mistakenly polarizing between two very valid options for different use cases. 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.
  - slimsag 3y ago
    According to their roadmap, WASI preview 2 will have threads and sockets. So, in light of that, what is the reason for diverging from WASI and creating WASIX?
    - syrusakbary 3y ago
      I'm not sure what roadmap you are talking about. Threads are actually removed from WASI Preview 2. 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.
      - slimsag 3y ago
        The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt. 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#issuecomment-1799182341 https://github.com/bytecodealliance/jco/issues/247#issuecomm... [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift-in-2023 https://bytecodealliance.org/articles/wasmtime-and-cranelift... [2] https://bytecodealliance.org/articles/webassembly-the-updated-roadmap-for-developers https://bytecodealliance.org/articles/webassembly-the-update... [3] https://github.com/bytecodealliance/wasmtime/pull/7285 https://github.com/bytecodealliance/wasmtime/pull/7285 [4] https://github.com/WebAssembly/shared-everything-threads https://github.com/WebAssembly/shared-everything-threads

WASIX will enable to run biome fully sandboxed at close to native speeds. 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 :)

slimsag 3y ago

The parent poster (syrusakbary) is the CEO of Wasmer and trying to push WASIX, a quasi-proprietary 'open standard' while it seems the rest of the WASM ecosystem is in fact moving to WASI preview 2 [0] [0] https://news.ycombinator.com/item?id=37545670 https://news.ycombinator.com/item?id=37545670

intelVISA 3y ago
Extend, Embezzle, Escape
syrusakbary 3y ago
I think you may be a bit confused on what's the purpose behind WASIX, Stephen. And you are mistakenly polarizing between two very valid options for different use cases. 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.
- slimsag 3y ago
  According to their roadmap, WASI preview 2 will have threads and sockets. So, in light of that, what is the reason for diverging from WASI and creating WASIX?
  - syrusakbary 3y ago
    I'm not sure what roadmap you are talking about. Threads are actually removed from WASI Preview 2. 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.
    - slimsag 3y ago
      The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt. 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#issuecomment-1799182341 https://github.com/bytecodealliance/jco/issues/247#issuecomm... [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift-in-2023 https://bytecodealliance.org/articles/wasmtime-and-cranelift... [2] https://bytecodealliance.org/articles/webassembly-the-updated-roadmap-for-developers https://bytecodealliance.org/articles/webassembly-the-update... [3] https://github.com/bytecodealliance/wasmtime/pull/7285 https://github.com/bytecodealliance/wasmtime/pull/7285 [4] https://github.com/WebAssembly/shared-everything-threads https://github.com/WebAssembly/shared-everything-threads