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)
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.
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.
* 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.
Thanks again for the effort of the elaboration.
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.
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.