4 ms·

I'm incredibly excited for this. The Biome team has been remarkably fast on achieving 95% compatibility with Prettier [1]. This will help to bring maximum spee

I'm incredibly excited for this. The Biome team has been remarkably fast on achieving 95% compatibility with Prettier [1]. This will help to bring maximum speed to formatting Javascript thanks to Rust, following the ruff (Python formatter) trend. Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon! Also congrats to the Algora team, as they have been doing very good work with their landing and trying to help on the challenge moving forward [4]. Keep up the great work!! [1] https://github.com/biomejs/biome/issues/720 https://github.com/biomejs/biome/issues/720 [2] https://wasmer.io/ https://wasmer.io/ [3] https://wasix.org/ https://wasix.org/ [4] https://console.algora.io/challenges/prettier https://console.algora.io/challenges/prettier

triyambakam 3y ago
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
cedws 3y ago
This is the first time I've come across WASIX. Upon reading about it, I can't help but see it as a reincarnation of the JVM. Is that accurate? What advantage is there to executing code in WASIX if it can access the system and isn't actually in a sandbox?
- shepherdjerred 3y ago
  It sounds the same to me: JVM, but with better browser support.
- n42 3y ago
  The advantage is this guy’s VC backed company gets to sink its teeth into the early stages of WASM platform adoption, helping him line his and his company’s pockets. WASIX is a hostile fork of an open standard that does care about sandboxing.
  - syrusakbary 3y ago
    I'm incredibly curious to hear more on how you think WASIX helps on the company pockets (since is open-source, and even it's governance model is open). I'd love to hear your thoughts, maybe we are missing on some nice business opportunities here!
    - n42 3y ago
      It's fine to be forthcoming about the financial interests of your projects – this is Hacker News, after all. We live on VC. The tone of your previous comment suggests there is none. I find it hard to believe that anything you would spend your company's time on would not push the mission of the company forward. This creates a financial incentive.
      - dang 3y ago
        Can you please follow the site guidelines when posting here? They include: "Have curious conversation; don't cross-examine." "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

triyambakam 3y ago

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

cedws 3y ago

This is the first time I've come across WASIX. Upon reading about it, I can't help but see it as a reincarnation of the JVM. Is that accurate? What advantage is there to executing code in WASIX if it can access the system and isn't actually in a sandbox?

shepherdjerred 3y ago
It sounds the same to me: JVM, but with better browser support.
n42 3y ago
The advantage is this guy’s VC backed company gets to sink its teeth into the early stages of WASM platform adoption, helping him line his and his company’s pockets. WASIX is a hostile fork of an open standard that does care about sandboxing.
- syrusakbary 3y ago
  I'm incredibly curious to hear more on how you think WASIX helps on the company pockets (since is open-source, and even it's governance model is open). I'd love to hear your thoughts, maybe we are missing on some nice business opportunities here!
  - n42 3y ago
    It's fine to be forthcoming about the financial interests of your projects – this is Hacker News, after all. We live on VC. The tone of your previous comment suggests there is none. I find it hard to believe that anything you would spend your company's time on would not push the mission of the company forward. This creates a financial incentive.
    - dang 3y ago
      Can you please follow the site guidelines when posting here? They include: "Have curious conversation; don't cross-examine." "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html