raskyld (Dec 16 2024 at 12:51): raskyld (Dec 16 2024 at 12:51):Hey everyone!
I've been reading A LOT of spec / explainers this week-end (yes. I have fun week-ends :joy:): core wasm, canonical ABI, started the Async explainer, a lot of memory-control proposals since I am trying to deepen my knowledge of the eco-system.
It seems really fair to say that the community went way further with WebAssembly than what it has been made for initially (i.e. the "Web"). So I tried to establish a cognitive model of how is the broader eco-system governed. IIUC:
W3C > WebAssembly WG > WebAssembly Community Groups.
Then, the Bytecode Alliance position itself like:
The Bytecode Alliance is focused on creating a shared implementation of standards produced by the WebAssembly CG and other standardization bodies.
(1) So the BA is independent from the aforementioned structure right?
Then, another question came up to my mind while reading the WebAssembly WG Charter, namely:
The mission of the WebAssembly Working Group is to standardize a size-efficient, load-time-efficient format and execution environment — allowing compilation to the web with consistent behavior across a variety of implementations.
This definition seems to exclude out-of-the-web use-cases, so It would be legitimate for the WG to consider some proposal out-of-scope and refuse changes to the instruction set or other "feature" of Core WebAssembly, right? So, while it seems unlikely, and clearly not something any of us want, (2) is it theoretically possible that one day out-of-the-browser users like us end-up diverging from Core WebAssembly, because they need something out of the scope of the WebAssembly WG "mandate"?
(That's just dumb questions trying to understand how to picture the ecosystem today)
Alex Crichton (Dec 16 2024 at 15:58):The BA is indeed independent of W3C and is not responsible for the governance of wasm. Many of us participate in the governance bodies but do so in a capacity no different from other CG members at other organizations/companies.
As for out-of-browser usage, I can't speak for others but in my experience the CG well understands that the web isn't the only use case for wasm. I don't know the origins of that language in the charter and I naturally can't predict if it'll be weaponized in the future.
fitzgen (he/him) (Dec 16 2024 at 16:49):The W3C is a venue for standardization and Wasm is spec'd and standardized under its umbrella.
The BA is a venue for collaborating on implementation among like-minded folks in order to further a common mission.
The BA is indeed independent from the W3C, although many of us in the BA participate in the W3C standardization process, as Alex mentioned.
is it theoretically possible that one day out-of-the-browser users like us end-up diverging from Core WebAssembly, because they need something out of the scope of the WebAssembly WG "mandate"?
It is theoretically possible, but unlikely because no one is incentivized to do so long-term. First, as Alex mentioned, there Wasm standards group understands that Wasm is not just the Web at this point and they see the investment that non-Web folks make in things like shared tooling and language toolchains. Second, the outside-the-Web folks also generally realize that the reason that Wasm enjoys its current popularity is largely because of the Web, and that without the Web and Web folks' contributions to shared tooling, it wouldn't succeed. For example, adding and maintaining an LLVM backend is a lot of work in the first place, but it is also not clear that LLVM would even want to have an official backend for some random bytecode (which is what a non-Web fork of core Wasm would be) and the LLVM backend is really what props up the whole ecosystem.
Finally, and we are getting further into my own personal speculation here, I think core Wasm's evolution is going to start largely slowing down. With stack switching, we are getting the last bits of control flow that was missing and impossible to implement efficiently without language support. With Wasm GC we are getting runtime-managed types. There are always going to be some new instructions to get more efficient code generation here and there, as well as extensions and generalizations of things that it already has (like richer GC stuff), but there really isn't much more stuff that core Wasm is fundamentally missing. Most of the evolution will be at the levels that are layered on top of core Wasm, like the component model, WASI, and Web/JS integration APIs.
raskyld (Dec 16 2024 at 18:38):Thanks a lot for clarifications!
It's funny you mention the "end of wasm core evolution" I was exactly wondering, while reading all those proposals and specs, where should Core Wasm stop and upper layers begin?
The way I picture it in my head for now is that Core Wasm only covers feature you reasonably can expect of an ISA for a modern platform, and then the CM comes as a layer on top of that just as a kernel would. (yeah it's probably a really dumb way to see things but that somehow help me to picture if something should be Core Wasm or CM :sweat_smile: )
Chris Fallin (Dec 16 2024 at 18:54):One distinction that might help clarify the line is between ISAs and ABIs. You can think of the Component Model, very roughly, as a set of standardized conventions to take higher-level types, interfaces, etc. down to Wasm primitives, and allow interop at a semantic level closer to source languages. Just as the SysV ABI (for example) allows separately-compiled C++ compilation units/shared libraries/... to talk in terms of classes, virtual methods, and the like. One wouldn't want to bake the ABI into the hardware necessarily -- it wouldn't fit some low-level use-cases, and it unnecessarily comingles two logically separate concerns. Likewise here: core Wasm is concerned with providing a programmable machine, and the Component Model describes how to interface together separate units of code on that machine
raskyld (Dec 16 2024 at 19:12):Thanks a lot Chris, that makes a lot of sense :pray:
Last updated: Dec 23 2024 at 12:05 UTC