Comment by phickey | Hacker News Reader

Comment by phickey | Hacker News Reader

Parent Full thread

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.

"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.

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.

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.

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.

Reply on news.ycombinator.com