13 ms·

I have mixed feelings about this. In one side, I'm happy that some of the people affected by the Mozilla layoffs have now secured a job. On the other side, no

I have mixed feelings about this. In one side, I'm happy that some of the people affected by the Mozilla layoffs have now secured a job. On the other side, now almost all the power of the WASI standard is concentrated into the Fastly corporation (with wider penetration thanks to the WASI integration in Rust). The main and only player of the Bytecode Alliance becomes Fastly as well (as Mozilla is out of the server-side Wasm game). So... how this could be bad? The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control [1] [2] [3]. This move is conceding them now a full-control over a standard such as WASI, placing the whole standard at risk [4] [1] https://twitter.com/syrusakbary/status/1202351432050954240 https://twitter.com/syrusakbary/status/1202351432050954240 [2] https://github.com/WebAssembly/WASI/issues/3#issuecomment-710754700 https://github.com/WebAssembly/WASI/issues/3#issuecomment-71... [3] https://twitter.com/cjihrig/status/1320763509463015425 https://twitter.com/cjihrig/status/1320763509463015425 [4] https://twitter.com/cjihrig/status/1320761713365581824 https://twitter.com/cjihrig/status/1320761713365581824

fwsgonzo 6y ago
There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extension, but it's probably pretty close. We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.
- chubot 6y ago
  Hm interesting idea... but - wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem. - wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that. So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!
  - fwsgonzo 6y ago
    I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory. The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
    - chubot 6y ago
      The wasm paper covers these issues, and is short and pretty readable: https://scholar.google.com/scholar?cluster=14979605902538775118&hl=en&as_sdt=0,5&sciodt=0,5 https://scholar.google.com/scholar?cluster=14979605902538775... tl;dr security introduces a lot of design constraints that RISC V doesn't have. section 2.3 on structured control flow: WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass. Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons: section 2.2: Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory. However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits. https://old.reddit.com/r/ProgrammingLanguages/comments/icb9ve/everything_old_is_new_again_binary_security_of/ https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v... If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement. Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
- syrusakbary 6y ago
  I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc https://medium.com/@losfair/a-comparison-between-webassembly...
  - jhallenworld 6y ago
    I wonder which leads to a faster emulated machine?
    - FullyFunctional 6y ago
      Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM). ADD: a few of the reasons: - When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary. - WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.
      - jacobush 6y ago
        Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.
        FullyFunctional 6y ago
        I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.
- nullifidian 6y ago
  RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.
  - xuejie 6y ago
    IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.
    - nullifidian 6y ago
      JVM has objects as the basic building block. For WASM it's linear memory(ies), so it's lower level, and was created from the start to support languages like C/C++. .NET indeed looks quite similar, given that it supports C++ compilation, tough I'm not familiar enough with the compilation model to draw comparisons.
mbStavola 6y ago
There are at least two other organizations that contribute to the Bytecode Alliance, so I don't see how Fastly has overtaken the standard. Could you elaborate on that? As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.
singularity2001 6y ago
Wasm offers a unique opportunity to invent and define a new ABI standard, one with (at least minimal) support for the concept of classes. How to make it popular is another question.
qppo 6y ago
surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.
- deleted 6y ago
  [deleted]
- syrusakbary 6y ago
  If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you. > the whole conversation on your end seems petty and toxic, at first glance That's a first! Can you expand on that? Thanks! https://github.com/WebAssembly/WASI/issues/3 https://github.com/WebAssembly/WASI/issues/3
  - CJefferson 6y ago
    I'm replying here as a total independant, because you asked for a response :) Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not the many related problems)
    - deleted 6y ago
      [deleted]
    - syrusakbary 6y ago
      Thanks for your response! Agreed that a logo is a not thing that should be taken lightly. Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision. IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.
deleted 6y ago
[deleted]
reitzensteinm 6y ago
By attempting to trademark WebAssembly you've outed yourself as a hostile actor. You don't then get to go and complain that the community isn't treating you well. They're right not to trust you. You use Oracle's JS trademark as precedent, but that's woefully ignorant of how it came about. JavaScript was not a four year old open standard when Oracle came along and scooped it up. JS was a Java branding deal between Sun and Netscape. If you want to contribute to build something good, because a strong wasm community is in your best interest, drop the attitude and don't make any more moves to sabotage the project. If you want to lawyer up and try to exploit the fruits of the community, then do that. But you need to pick a lane. I don't see Larry hanging around HN complaining about how people are treating him on GitHub. I don't have a dog in this fight. Prior to this thread, I didn't know about you, your company, or anyone in all these links you've posted except I remember reading a post by Lin Clark once. I wrote another post that I deleted pretty quickly when I realized how aggressive it sounded. But it wasn't trying to be aggressive, just convey the hostility of what you did and how you should expect people to react.
- deleted 6y ago
  [deleted]
- syrusakbary 6y ago
  The Bytecode Alliance veto of Wasmer happened the same day it was announced, on November 12 2019 (via direct message by one of their well-known members -now working at Fastly- to a Wasmer investor). Back then, the trademark was not even filed by the lawyers (if you look to the USPTO filings), so I'm not sure how the hostile actor argument could apply here (if we really buy into that argument). As reflected in other comments in this thread, it's not in Wasmer intent to trademark WebAssembly. And we successfully course-corrected any actions way before it was even public. We have been continuously pushing the limits of WebAssembly since we were founded. The success of Wasmer as a company solely depends on the success of WebAssembly as a technology, and is on our best interest to continue pushing it forward. In fact, I'd argue that Wasmer has been pioneer in: 1. Open-sourcing the first working Rust WebAssembly runtime (wasmtime existed when I created Wasmer, but was not able to run anything [1]) 2. Creating a Package Manager for WebAssembly [2] 3. Creating WebAssembly embeddings for non-js languages (PHP, Ruby, Python, ...) 4. Running WASI fully in a browser, including an online shell [3] [1] https://github.com/wasmerio/wasmer/issues/142#issuecomment-461129940 https://github.com/wasmerio/wasmer/issues/142#issuecomment-4... [2] https://wapm.io https://wapm.io [3] https://webassembly.sh https://webassembly.sh
seg_lol 6y ago
It has always felt like wasmer was trying to be the NPM of the Wasm world and stake out a defacto monopoly position. I don't have much data around that, happy to be proven wrong. But we don't need more corporate control over package managers and code-reuse ecosystems.
marcinzm 6y ago
>The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control Their persona bias seems to be summarized as (from the github issue): >The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC. Which seems a lot less like personal bias and a lot more like both you personally and your company have crossed too many lines to be considered good members of the community. Given your response was to lash out everywhere rather than take it as constructive criticism to grow with I suspect your behavior beforehand wasn't much better.
deleted 6y ago
[deleted]
CyberRabbi 6y ago
Just curious, why do you have such a strong interest in the WASI logo? That seems tangential to wasmer’s concerns.
- syrusakbary 6y ago
  We use the logo in the wapm website [1]. Using a non-accessible logo that is hard to read provides a non-ideal experience for our visitors, so we can't really use it unless it becomes more polished. This forced wapm to use a different WASI logo than the "official" one, which is also a non-ideal experience (it adds fragmentation). That's why we believe is just better to push all along a bit more polished logo. Is such a simple thing to fix, that I'm surprised of the amount of flamewar that it generated. [1] https://wapm.io/interface/wasi https://wapm.io/interface/wasi
  - singemonkey 6y ago
    I don't think anyone believes you "peter"
    - CyberRabbi 6y ago
      Who is “peter”?
      - gilrain 6y ago
        The sockpuppet account this guy uses to astroturf his own projects. Documented elsewhere in this thread.
        CyberRabbi 6y ago
        Oh I just saw it. Wow that’s... strange https://news.ycombinator.com/item?id=12584886 https://news.ycombinator.com/item?id=12584886
    - syrusakbary 6y ago
      You are free to believe in what you want, of course

fwsgonzo 6y ago

There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extension, but it's probably pretty close. We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some instructions that favor cloud computation now, with these news.

chubot 6y ago
Hm interesting idea... but - wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem. - wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that. So I think this idea is glossing over a lot of details... not all ISAs are equal, especially ones meant to be transmitted over the network!
- fwsgonzo 6y ago
  I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory. The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.
  - chubot 6y ago
    The wasm paper covers these issues, and is short and pretty readable: https://scholar.google.com/scholar?cluster=14979605902538775118&hl=en&as_sdt=0,5&sciodt=0,5 https://scholar.google.com/scholar?cluster=14979605902538775... tl;dr security introduces a lot of design constraints that RISC V doesn't have. section 2.3 on structured control flow: WebAssembly represents control flow differently from most stack machines. It does not offer simple jumps but instead provides structured control flow constructs more akin to a programming language. This ensures by construction that control flow cannot form irreducible loops, contain branches to blocks with misaligned stack heights, or branch into the middle of a multi-byte instruction. These properties allow WebAssembly code to be validated in a single pass, compiled in a single pass, or even transformed to an SSA-form intermediate form in a single pass. Also, wasm is a "Harvard architecture" rather than von Neumann (separate address space for code and data), also for security reasons: section 2.2: Linear memory is disjoint from code space, the execution stack, and the engine’s data structures; therefore compiled programs cannot corrupt their execution environment, jump to arbitrary locations, or perform other undefined behavior. At worst, a buggy or exploited WebAssembly program can make a mess of the data in its own memory. However, wasm also leaves some things to be desired security wise. Buffer overflows in C are still buffer overflows once you compile to wasm, and can be chained in to JS exploits. https://old.reddit.com/r/ProgrammingLanguages/comments/icb9ve/everything_old_is_new_again_binary_security_of/ https://old.reddit.com/r/ProgrammingLanguages/comments/icb9v... If you try to use RISC V in the same contexts, you'll have the same problems. If you have an additional layer of process sandboxing, then those could be mitigated. But then RISC V is not a wasm replacement. Although maybe wasm is hopeless for C code, so you need more sandboxing anyway, so then it's on par with RISC V... interesting question.
syrusakbary 6y ago
I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly-and-risc-v-e8fb9d37e6cc https://medium.com/@losfair/a-comparison-between-webassembly...
- jhallenworld 6y ago
  I wonder which leads to a faster emulated machine?
  - FullyFunctional 6y ago
    Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM). ADD: a few of the reasons: - When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary. - WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.
    - jacobush 6y ago
      Your comment made me idly wonder if there's a way to make an ISA which lends itself both to fast (even for low-gate implementations) hardware, and to fast JIT-ing.
      - FullyFunctional 6y ago
        I suspect these are conflicting goals but an interesting question. My idle pondering are on ISAs that minimize the challenges in wide superscalar OoOE.
nullifidian 6y ago
RISC-V is from a significantly differing category. A category for WASM doesn't really exist yet, there is nothing else like this -- a relatively low level bytecode language with high-level features such as nominal types, garbage collection, modules.
- xuejie 6y ago
  IMO such a category existed for quite a long time, JVM and .NET all falls into this category. Yes WASM has its fame for becoming a browser standard, but fundamentally, there is very little difference between WASM and JVM.
  - nullifidian 6y ago
    JVM has objects as the basic building block. For WASM it's linear memory(ies), so it's lower level, and was created from the start to support languages like C/C++. .NET indeed looks quite similar, given that it supports C++ compilation, tough I'm not familiar enough with the compilation model to draw comparisons.

mbStavola 6y ago

There are at least two other organizations that contribute to the Bytecode Alliance, so I don't see how Fastly has overtaken the standard. Could you elaborate on that? As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.

singularity2001 6y ago

Wasm offers a unique opportunity to invent and define a new ABI standard, one with (at least minimal) support for the concept of classes. How to make it popular is another question.

qppo 6y ago

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

deleted 6y ago
[deleted]
syrusakbary 6y ago
If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you. > the whole conversation on your end seems petty and toxic, at first glance That's a first! Can you expand on that? Thanks! https://github.com/WebAssembly/WASI/issues/3 https://github.com/WebAssembly/WASI/issues/3
- CJefferson 6y ago
  I'm replying here as a total independant, because you asked for a response :) Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not the many related problems)
  - deleted 6y ago
    [deleted]
  - syrusakbary 6y ago
    Thanks for your response! Agreed that a logo is a not thing that should be taken lightly. Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision. IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.

deleted 6y ago

[deleted]

reitzensteinm 6y ago

By attempting to trademark WebAssembly you've outed yourself as a hostile actor. You don't then get to go and complain that the community isn't treating you well. They're right not to trust you. You use Oracle's JS trademark as precedent, but that's woefully ignorant of how it came about. JavaScript was not a four year old open standard when Oracle came along and scooped it up. JS was a Java branding deal between Sun and Netscape. If you want to contribute to build something good, because a strong wasm community is in your best interest, drop the attitude and don't make any more moves to sabotage the project. If you want to lawyer up and try to exploit the fruits of the community, then do that. But you need to pick a lane. I don't see Larry hanging around HN complaining about how people are treating him on GitHub. I don't have a dog in this fight. Prior to this thread, I didn't know about you, your company, or anyone in all these links you've posted except I remember reading a post by Lin Clark once. I wrote another post that I deleted pretty quickly when I realized how aggressive it sounded. But it wasn't trying to be aggressive, just convey the hostility of what you did and how you should expect people to react.

deleted 6y ago
[deleted]
syrusakbary 6y ago
The Bytecode Alliance veto of Wasmer happened the same day it was announced, on November 12 2019 (via direct message by one of their well-known members -now working at Fastly- to a Wasmer investor). Back then, the trademark was not even filed by the lawyers (if you look to the USPTO filings), so I'm not sure how the hostile actor argument could apply here (if we really buy into that argument). As reflected in other comments in this thread, it's not in Wasmer intent to trademark WebAssembly. And we successfully course-corrected any actions way before it was even public. We have been continuously pushing the limits of WebAssembly since we were founded. The success of Wasmer as a company solely depends on the success of WebAssembly as a technology, and is on our best interest to continue pushing it forward. In fact, I'd argue that Wasmer has been pioneer in: 1. Open-sourcing the first working Rust WebAssembly runtime (wasmtime existed when I created Wasmer, but was not able to run anything [1]) 2. Creating a Package Manager for WebAssembly [2] 3. Creating WebAssembly embeddings for non-js languages (PHP, Ruby, Python, ...) 4. Running WASI fully in a browser, including an online shell [3] [1] https://github.com/wasmerio/wasmer/issues/142#issuecomment-461129940 https://github.com/wasmerio/wasmer/issues/142#issuecomment-4... [2] https://wapm.io https://wapm.io [3] https://webassembly.sh https://webassembly.sh

seg_lol 6y ago

It has always felt like wasmer was trying to be the NPM of the Wasm world and stake out a defacto monopoly position. I don't have much data around that, happy to be proven wrong. But we don't need more corporate control over package managers and code-reuse ecosystems.

marcinzm 6y ago

>The Bytecode Alliance has been biased since their inception, blocking any attempt of collaboration from Wasmer based on personal bias (I work at Wasmer) and other external entities out of their control Their persona bias seems to be summarized as (from the github issue): >The rejection from the Bytecode Alliance was based on a history of behavior that isn’t compatible with the BA codes of conduct—both the individual CoC and the organizational CoC. Which seems a lot less like personal bias and a lot more like both you personally and your company have crossed too many lines to be considered good members of the community. Given your response was to lash out everywhere rather than take it as constructive criticism to grow with I suspect your behavior beforehand wasn't much better.

deleted 6y ago

[deleted]

CyberRabbi 6y ago

Just curious, why do you have such a strong interest in the WASI logo? That seems tangential to wasmer’s concerns.

syrusakbary 6y ago
We use the logo in the wapm website [1]. Using a non-accessible logo that is hard to read provides a non-ideal experience for our visitors, so we can't really use it unless it becomes more polished. This forced wapm to use a different WASI logo than the "official" one, which is also a non-ideal experience (it adds fragmentation). That's why we believe is just better to push all along a bit more polished logo. Is such a simple thing to fix, that I'm surprised of the amount of flamewar that it generated. [1] https://wapm.io/interface/wasi https://wapm.io/interface/wasi
- singemonkey 6y ago
  I don't think anyone believes you "peter"
  - CyberRabbi 6y ago
    Who is “peter”?
    - gilrain 6y ago
      The sockpuppet account this guy uses to astroturf his own projects. Documented elsewhere in this thread.
      - CyberRabbi 6y ago
        Oh I just saw it. Wow that’s... strange https://news.ycombinator.com/item?id=12584886 https://news.ycombinator.com/item?id=12584886
  - syrusakbary 6y ago
    You are free to believe in what you want, of course