4 ms·

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

phickey 4y ago
I work on Wasi at Fastly, as part of the Bytecode Alliance. WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself. I can’t really say that adding more people would have sped up the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it. A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow. So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.
- Existenceblinks 4y ago
  Thanks for the inside. I watched the Component Model repo, it's very active (had to turn off noti). Still confused why the need for wit file instead of wat directly which is already human-friendly. Now wasm has two versions of text mode? Appreciated, specification is a hard work.
  - phickey 4y ago
    there’s a good write up on this somewhere that you’ll have to forgive me not being able to find tonight on mobile. In general, we want the wat syntax to mirror the binary format very closely, but that’s often at odds with a surface syntax that promotes good software engineering or good developer ux. Two cases for that off the top of my head: * the component model wat can represent interfaces, but it can’t represent the composition of interfaces, e.g. if we were writing a new interface which opened something file-like and wanted to reuse the oflags type from wasi-filesystem, there would be no way to express that indirectly because we insist wasm binaries are self contained (don’t require you to load other resources), so the oflags type definition would need to be copied in literally. * when we add resource types back to wit syntax (you can rewind history in wit-bindgen 2 months to find examples, we got rid of them because they were a strawman and now something quite similar is getting speced) it’s nice to have wit syntax appear just like constructors and methods, even if we all know a method desugars to a functions that take a resource as it’s first parameter in the canonical abi. It’s nice to have a distinction in wit that can be used by code generators for creating idiomatic C++, Rust, JS etc methods. Even if we give methods a faithful wat/binary repr (like, e.g. flag types, which are a shorthand for a struct full of bools), the wat/binary form will necessarily have much worse syntax than the wit will, and we think having a syntax that doesn’t send you rubbing your temples reading the component model spec will help adoption. Speaking as someone who has had to read and write a nontrivial amount of wat over the last 5 years, it’s lovely for small examples and it’s pretty challenging for large, “real world” programs.
    - Existenceblinks 4y ago
      Got it. My concern is just fragmentation of compiler/parser tooling in order to also support wit and may introduce compatibility burden to maintain (I know wasm<->wat is 1:1, not sure about wit). However, I'm looking forward to compiling my toy lang to WASI once its MVP is solid. Thanks again for the effort of the elaboration.
- mike_hearn 4y ago
  "the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM" It's great that you're developing WASI but I don't see how it's any more open than the JVM or .NET CLR. Obviously from a licensing perspective it's not any different, anyone can go implement the JVM or CLR specs. In the past the JVM and Java even had a rather complicated community process designed to disempower Sun, some aspects of which remain today. It sounds like WASM/WASI is something similar but with Fastly being the dominant company instead of Oracle/MS. I went to the bytecodealliance github repo and picked a random repository with "wasi" in the name and looked at the last commit. It was by someone who works at Fastly. Technical specs always have some firm or another pushing more than others at any given point, that's not what determines if they're open or not. Also, both the JVM and CLR have had support for mutually distrusting components from the start, so that's not really new either. That support didn't get widespread use because sandboxing even at the process level for individual apps is still rather rare, and sandboxing at the sub-component level proved too hard to get right with the CLR/JVM approach. It's probably better to argue that what you're doing with WASI is better in some concrete technical sense rather than arguing it's new.
jeffparsons 4y ago
My outsider's interpretation is that a lot of the details are being held up while the Component Model spec is finalised, so even if lots of ideas are being bounced around and people are experimenting, we won't see a "Snapshot 2" or many new modules (etc.) until that settles. After that is done, I'd expect to see a lot of focus shift to fleshing out various WASI APIs, which can then also IINM start to be released individually at their own pace.
- phickey 4y ago
  Yep that’s exactly the plan (I work on wasi and the component model and etc)
  - jeffparsons 4y ago
    Ah, I see, you posted your comment a minute before mine. I got my impression from obsessively reading Zulip threads, pull requests, and meeting minutes. It's nice to hear it from the horse's mouth and not just the tea leaves!

phickey 4y ago

I work on Wasi at Fastly, as part of the Bytecode Alliance. WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself. I can’t really say that adding more people would have sped up the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it. A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow. So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.

Existenceblinks 4y ago
Thanks for the inside. I watched the Component Model repo, it's very active (had to turn off noti). Still confused why the need for wit file instead of wat directly which is already human-friendly. Now wasm has two versions of text mode? Appreciated, specification is a hard work.
- phickey 4y ago
  there’s a good write up on this somewhere that you’ll have to forgive me not being able to find tonight on mobile. In general, we want the wat syntax to mirror the binary format very closely, but that’s often at odds with a surface syntax that promotes good software engineering or good developer ux. Two cases for that off the top of my head: * the component model wat can represent interfaces, but it can’t represent the composition of interfaces, e.g. if we were writing a new interface which opened something file-like and wanted to reuse the oflags type from wasi-filesystem, there would be no way to express that indirectly because we insist wasm binaries are self contained (don’t require you to load other resources), so the oflags type definition would need to be copied in literally. * when we add resource types back to wit syntax (you can rewind history in wit-bindgen 2 months to find examples, we got rid of them because they were a strawman and now something quite similar is getting speced) it’s nice to have wit syntax appear just like constructors and methods, even if we all know a method desugars to a functions that take a resource as it’s first parameter in the canonical abi. It’s nice to have a distinction in wit that can be used by code generators for creating idiomatic C++, Rust, JS etc methods. Even if we give methods a faithful wat/binary repr (like, e.g. flag types, which are a shorthand for a struct full of bools), the wat/binary form will necessarily have much worse syntax than the wit will, and we think having a syntax that doesn’t send you rubbing your temples reading the component model spec will help adoption. Speaking as someone who has had to read and write a nontrivial amount of wat over the last 5 years, it’s lovely for small examples and it’s pretty challenging for large, “real world” programs.
  - Existenceblinks 4y ago
    Got it. My concern is just fragmentation of compiler/parser tooling in order to also support wit and may introduce compatibility burden to maintain (I know wasm<->wat is 1:1, not sure about wit). However, I'm looking forward to compiling my toy lang to WASI once its MVP is solid. Thanks again for the effort of the elaboration.
mike_hearn 4y ago
"the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM" It's great that you're developing WASI but I don't see how it's any more open than the JVM or .NET CLR. Obviously from a licensing perspective it's not any different, anyone can go implement the JVM or CLR specs. In the past the JVM and Java even had a rather complicated community process designed to disempower Sun, some aspects of which remain today. It sounds like WASM/WASI is something similar but with Fastly being the dominant company instead of Oracle/MS. I went to the bytecodealliance github repo and picked a random repository with "wasi" in the name and looked at the last commit. It was by someone who works at Fastly. Technical specs always have some firm or another pushing more than others at any given point, that's not what determines if they're open or not. Also, both the JVM and CLR have had support for mutually distrusting components from the start, so that's not really new either. That support didn't get widespread use because sandboxing even at the process level for individual apps is still rather rare, and sandboxing at the sub-component level proved too hard to get right with the CLR/JVM approach. It's probably better to argue that what you're doing with WASI is better in some concrete technical sense rather than arguing it's new.

jeffparsons 4y ago

My outsider's interpretation is that a lot of the details are being held up while the Component Model spec is finalised, so even if lots of ideas are being bounced around and people are experimenting, we won't see a "Snapshot 2" or many new modules (etc.) until that settles. After that is done, I'd expect to see a lot of focus shift to fleshing out various WASI APIs, which can then also IINM start to be released individually at their own pace.

phickey 4y ago
Yep that’s exactly the plan (I work on wasi and the component model and etc)
- jeffparsons 4y ago
  Ah, I see, you posted your comment a minute before mine. I got my impression from obsessively reading Zulip threads, pull requests, and meeting minutes. It's nice to hear it from the horse's mouth and not just the tea leaves!