Component model critique · general

As someone who was around with COM, DCOM, SOAP, WSDL, etc (I think) I understand the concern here.

Dan Gohman (May 22 2024 at 22:29):

I think when someone rolls in with hot takes like "in Rust, async is a failure", it's clear what kind of post they're going for.

Dan Gohman (May 22 2024 at 22:36):

The async features being worked on for Preview 3 are quite different from Rust's async. I encourage anyone interested in learning more to watch Luke's talk, including how it avoids the function coloring problem.

Pat Hickey (May 22 2024 at 23:27):

Pat Hickey (May 22 2024 at 23:33):

The post is a rant and not worth anyone’s time to address, if you or the author find there to be any substantial critique in there i encourage you to write it in a way that’s not deliberately inflammatory

IFcoltransG (May 22 2024 at 23:41):

I think there are enough justifications for why high-level abstractions are worth extra complexity compared to a plain ABI. (See e.g. Luke's other talks on components.) We can certainly do our best to make it ergonomic for library users as the tooling develops.

Kevin Moore (May 23 2024 at 02:25):

At a minimum, it might be good for folks here (with more context) to add to the discussion on HN. Might...

Ralph (May 23 2024 at 10:20):

As someone on the original OLE32 team, then COM, then DCOM, then WS*/SOAP -- he pulls out his OLDZ IDENTITY CARD -- the component model is completely different than the problem he describes as _the one he thinks is worth paying attention to_. Each and every one of those technologies had successes and failures and learning from them both puts us here.

Ralph (May 23 2024 at 10:21):

PERSONALLY, as a megacorp old, I could not care less what dialogue takes place on the Orange Cheeto site. I am NOT a fan. What posts there that are helpful are also available outside that framework.

Ralph (May 23 2024 at 10:23):

Now, others might think about the Cheeto site, so @Kevin Moore I do not begrudge you the point!!! :-) I'd prefer to extract one point from that screed, to "wit": he takes WIT to be for developers, like everyone else who does not yet grok that no one should ever need WIT unless they were building some sort of platform.

Ralph (May 23 2024 at 10:23):

So there's clearly still a messaging problem: The solid critique of components is that they have not yet arrived.

Ralph (May 23 2024 at 10:25):

almost all of the incoming people do not learn quickly -- QUICKLY -- that what we have now are the underpinnings of a language-toolchain based way of using wasm modules. That we have only two runtimes (really) yet implementing it. And that the work between now and the end of the calendar year will really be when it can be taken seriously IFF you're looking for an "scale out, approachable developer platform".

Ralph (May 23 2024 at 10:27):

Ralph (May 23 2024 at 10:28):

this screed makes the same mistake, then adds as much pointless hubris as it can. Beyond this, I don't gain too much from it.

Christof Petig (May 23 2024 at 12:10):

Ralph (May 23 2024 at 13:58):

code red art (May 24 2024 at 05:36):

If nothing else, what this post highlights is the lack of accessible information about component model.
At this moment, information about component model is all over the place on Zulip, Github issues/prs/readmes of related projects, random talks, RFCs etc... Most people can't keep up with this.

So, any random blogpost can say whatever it wants, as there's very few people who can actually counter them (and even fewer who do) as most people don't know enough to refute any lies/hyperbole arguments.

it would be nice if more people involved in CM work wrote some articles now and then describing one feature of CM for mainstream audience.

The only thing this article gets right is the amount of rust people involved in this project.

Ryan Levick (rylev) (May 24 2024 at 10:07):

Ralph (May 24 2024 at 10:19):

@Ryan Levick (rylev) one thing is an explanation at the top that says "this is what exists at the moment; for information about the future intended evolution of the component model (v0.3, RC, 1.0, etc.) please see......"

Ralph (May 24 2024 at 10:19):

people read that thinking that this IS the component model (present tense) as if there is no future tense -- because we don't make that clear

Ralph (May 24 2024 at 10:20):

in ADDITION, we should be clear where the benefits accrue; and that it's not required to use it -- it sits on top of core wasm.

Ralph (May 24 2024 at 10:20):

Frank Rehwinkel (May 24 2024 at 13:00):

I think the game changers are sandboxing (and now better sandboxing), plugins, composition and async.

The experience people here bring to the table speaks loudly to the significance of what is being accomplished. I hope no-one is taking to heart the easy shots someone can make if they resort to slight misrepresentations or leaving out a fuller picture.

And to me, being new here, but not new to async or wasm or to siloed platforms, it seems perfectly natural that the documentation doesn't represent everything yet and doesn't make things easy yet. It couldn't possibly do justification to the technology that is rising here.

I agree with the comment above that non-constructive critiques and requests for comment on critiques don't need amplification here (yet I'm commenting). One of the double-edge swords of having such an open and welcoming environment around this project means there are the occasional cuts when something as innocuous sounding as would you care to comment on this critique is thrown in.

The people already here don't need encouragement to continue what they are doing. I guess I wanted to add my voice for anyone else new, to be quick to try the examples and watch the issues and PRs and be slow to critique.

Brooks Townsend (May 24 2024 at 13:14):

@Ryan Levick (rylev) I personally did not know that https://component-model.bytecodealliance.org/ existed, and it looks like a wonderful resource. My only thought of where it's falling short is discoverability :smile: Where could I find that link if I were looking through the BCA / WebAssembly repos?

Ryan Levick (rylev) (May 24 2024 at 13:50):

Advertise existence of this resource in more places · Issue #138 · bytecodealliance/component-docs

I've received some feedback that the component docs are not discoverable enough. Perhaps we could do a concerted effort of going to other component related BA repos and making sure the link to thes...

Ralph (May 24 2024 at 14:53):

code red art (May 24 2024 at 17:19):

First, there needs to be a minimal (but realistic) use-case used as a reference throughout the doc. For example, safer_ffi crate's README uses a tiny example of a Point { x: f32, y: f32 } struct and a fn midpoint(&self, other: &Point) -> Point fn. Then, it refers to these items as concrete examples whenever it explains a concept. The cargo reference's build script chapter also takes zlib (libz-sys crate) as an example to explain the various concepts.

Second, there needs to be a brief explanation of wasm concepts before we even start with component model. Most people interact with wasm via wasm_bindgen or emscripten, which don't really tell you about concepts like linear memories. Without knowing about that, one cannot understand the concept of each component having separating memories or "exporting" a memory. wasm -> component model -> wasi feels like natural progress. While explaining the concepts, we should also tell why we even need it. Personally, I had trouble understanding interfaces, worlds and packages. interfaces/worlds just feel like rust modules with almost no difference, while package feels like a crate (which itself is also a root module). I kind of get that package is for distribution (like crates), worlds are for actual instantiation (like a dll/so) based on parameterized imports and interfaces are the actual rust modules where we group some items. But, the guide could have definitely helped by explaining their intended use-cases explicitly.

Third, We need a cheatsheet or something which shows the parallels of CM concepts to some real world implementations. package seems similar to java/go packages. components seems similar to shared libraries (dll/so objects). wasi seems like a "std library" (libc is just c's std library, and wasi is libc of CM). Option<T> is nullable or something. The blogpost we are discussing makes these words seem like some scary foreign concept and that the complexity of CM has exploded, but most of these are simple basic concepts that almost every programmer knows and has direct parallels for any mainstream programming language ecosystem. A simple graphic cheatsheet would do wonders compared to a textual guide (especially to share on twitter or to use it in medium articles).

Slightly off-topic, but I think there should be some beginner articles on the bytecode alliance website in addition to the book. something similar to Introduction to Vulkan Video extensions from Khronos blog. Blogposts are easier to share on twitter/reddit to reach mainstream audience, compared to an mdbook.

GitHub - getditto/safer_ffi: Write safer FFI code in Rust without polluting it with unsafe code

Write safer FFI code in Rust without polluting it with unsafe code - getditto/safer_ffi

An Introduction to Vulkan Video

Deploying and developing royalty-free open standards for 3D graphics, Virtual and Augmented Reality, Parallel Computing, Neural Networks, and Vision Processing

The Khronos Group

Deploying and developing royalty-free open standards for 3D graphics, Virtual and Augmented Reality, Parallel Computing, Neural Networks, and Vision Processing

Karel Hrkal (kajacx) (May 27 2024 at 09:30):

It shoes how to make to make the guest and how to run in from the command line, but not how to run a component from Rust. It's definitely a step forward to have an actual tutorial, but unfortunately it's still not complete.

Karel Hrkal (kajacx) (May 27 2024 at 09:39):

The post went from kind of making sense to being completely unhinged to sort of making sense again. Their "expected example" of interface definition looks (really) no different from a wit file, except for different formatting and wording, so I don't understand what is their problem there.

I would agree that async is done sub-optimally (forcing WASI users to use async even if they don't want to), but that is not what the article said. There are genuine problems in the current implementation of the component models, for example guest resources being completely untyped on the host, no recursive structures or unable to use guest resources in host imported function, but the article doesn't mention any of them.

The biggest problem (IMO) currently with the component model is that very few languages support it, but again, it's not mentioned in the article.

Ralph (May 27 2024 at 10:19):

It's entirely fair to not like the current version we have for almost any reason, and that's because it's not done yet. It is also fair if from some position "not done yet" isn't what you want. For example, there's a reason that few language chains directly support it, as it's very new. That much I get! Totes fair.....

Andrew Chin (May 31 2024 at 03:07):

IFcoltransG (May 31 2024 at 03:15):

Issues · bytecodealliance/component-docs

Documentation around creating and using WebAssembly Components - Issues · bytecodealliance/component-docs

Andrew Chin (May 31 2024 at 04:19):

Piotr Sarnacki (Oct 07 2024 at 14:36):

I know it's an old post, but I wanted to leave a comment here from a perspective of a developer working on a hobby project, who is not in any way associated with ByteCode Alliance nor has particularly deep knowledge on WASM and most of the proposals.

I work on a stress testing tool that runs scenarios compiled to WASM. I started it a long time ago, but I tend to work in small batches here and there when I find motivation, so I implemented most of the WASM support in the beginning of this year. I decided to go with manual communication between the modules and the host by sharing the linear memory. It's not ideal, cause there is quite a lot of plumbing to do, but it worked well and WASI components were even younger than they are now. Recently I've been looking into WASI components more and more and it seemed like it becomes a viable technology. I know it may change in the future previews, but it sure seems usable already. So I bit the bullet and rewrote the WASM/WASI part of my library to WASI components. Here is a PR if anyone is interested. Look at all the code and hairy memory management that I could remove! So far I'm very happy with the changes, especially that I know I'm not only removing Rust bindings for guest modules, but essentially removing the need to implement most of the plumbing for other languages too.

What's even better, it's not even the final state of the rewrite. I purposefully started with custom types for http implementation, but in the near future I would like to implement the wasi:http package. And as far as I understand it will make my life so much easier. For context - I need to gather detailed timing information on each HTTP request and response, like: time to establish a connection, time to do the TLS handshake, time to first byte etc. Typically what stress testing libraries do is to create their own version of HTTP request functions in order to be able to gather metrics. After I implement wasi:http package I will be able to plug any component that uses the package and have all of the custom metrics pretty much for free. Like, for example if I use a JS runtime that implements fetch() with the wasi:http interfaces, a user could write a scenario in JS using fetch (or use any library that uses fetch() under the hood) and it would go through my implementation of the HTTP stack. That's wicked! Not only I can have support for multiple languages almost for free, but also I can potentially hook their standard APIs!

Needless to say, I really enjoy the WASI component model. I agree that all of the rules regarding imports and includes are a bit hard to grasp in the beginning, but honestly I don't see where is the problem in that - if you don't want to use them and just want to define a simple interface with just basic types, nothing can stop you! But in the real world there is often a need for a bit more complex stuff. For example the streaming that the author complains about - sure, not everyone needs it and it increases complexity. But if there was no streaming support in the http package, I couldn't use it anyway, so what would be the point of that? The same is true to anyone that works on a high performance tooling.

I will not even waste time to comment on the weird notion of async/await being a failure. I think only people that have never used it for anything serious can say that. Without async/await I wouldn't be able to use Rust for some applications I've worked on in the past (or at least it would be much harder as I would have to handle epoll or io_uring manually). Not even sure what does it mean that it's still in beta :upside_down:

Implement WASI component model instead of custom module communication by drogus · Pull Request #4 · drogus/crows

We read every piece of feedback, and take your input very seriously.

Ralph (Oct 07 2024 at 14:57):

Till Schneidereit (Oct 08 2024 at 14:46):

thank you for sharing this! It's really appreciated, and fantastic to hear that you're having a good experience already, while looking forward to improving on it even further :smile: As someone who did an implementation of the JS fetch API in terms of wasi:http, and leads a team maintaining a runtime (Spin) that, among others, has similar requirements regarding telemetry collection, I can confirm that everything you're saying works out in full.

Regarding future previews: WASIp3 will be purely additive, so all content running in p2 compatible environments will continue running. And for an eventual WASI 1.0, we'll provide the kind of adapter we created for going from p1 to p2, so it should be possible to keep content working without interruption indefinitely

Introducing Spin

A checklist app that persists data in a key value store

CryZe (Oct 08 2024 at 19:30):

One thing I personally, as someone who's deeply familiar with WebAssembly, but not so much with WASI 0.2, do not understand, is how is that even possible? The Component Model is a Phase 1 proposal that is not implemented by V8, Spidermonkey or JavaScriptCore... so really only wasmtime implements it. How can you claim that it will forever be forwards compatible when it's so extremely experimental in nature?

IFcoltransG (Oct 08 2024 at 20:16):

For context: the component model is going through a versioning process with the Bytecode Alliance, separate from core wasm/W3C's standardisation process. 1.0 will be the version proposed to W3C. Wasmtime and JCO both have implementations of the component model.

CryZe (Oct 08 2024 at 20:25):

That doesn't really change much. The forwards compatibility claim is still extremely questionable then.

Alex Crichton (Oct 08 2024 at 20:28):

In the end the claim here is only as strong as amount of effort people are willing to put into the design itself and keep older things working. There's quite a lot of effort and implementation work behind keeping components working as-is. It's impossible to say we'll have 100% forward-compat in every way shape and form because we don't even know what the future looks like. That being said no one involved in any part of the design has any intention on breaking anything at this time and it's understood everywhere that if anything must be changed it must have a smooth path going forwards.

What that exactly means for wasip3, wasip4, wasi 1.0, is unclear. I think it's unclear not because the intent-to-not-break is illegitimate, unfounded, or unreasonable. It's unclear in that we have no idea what those stories are going to be. The design of wasip3 and beyond are going to be extremely heavily influenced by ensuring the entire ecosystem doesn't break all at once.

CryZe (Oct 08 2024 at 20:44):

Alright so the problem I'm somewhat seeing merging it upstream without breaking things: With WebAssembly itself gaining struct, array, and similar types (possibly even async?), wouldn't or rather shouldn't that somewhat affect the component model, so it builds on top of those types instead of defining its own stuff? Though I may just be uninformed and it already is designed to support those.

Alex Crichton (Oct 08 2024 at 20:46):

Perhaps! Rust, for example, is unlikely to use the new struct/array types. Other languages though, for sure! We've already planned a "hole" in the component model to support that by means of the 'canonical abi' which is the bridge between core wasm types and component model types. There's extension locations in place to create a branch between wasm gc values and component model types when gc support is added.

The existence of struct/array in core wasm doesn't mean that types should be removed in the component model though. There's different goals such as shared-nothing linking and being able to operate without a gc which the component model still has

Till Schneidereit (Oct 09 2024 at 20:47):

One clarification might perhaps help here: I deliberately talked about future previews retaining backwards-compatibility, not the component model across all versions in perpetuity. The idea is indeed to make whatever breaking changes we've identified as necessary for a (very) long-term stable standard at that point, instead of breaking things for each preview

Till Schneidereit (Oct 09 2024 at 20:50):

Till Schneidereit (Oct 09 2024 at 20:53):

That is indeed something already considered in the design: all of these features are explicitly meant to stay as implementation details of individual components, which don't affect what other components need to do. To take the GC types you mention as an example, here's a draft of a specification for how those can be integrated into the component model. This won't affect existing content at all, and will allow composing existing components using linear memory with new components using WasmGC

working with gc types by oovm · Pull Request #317 · WebAssembly/component-model

Add Canonical ABI options to support passing parameters by reference type Close Working with GC types without copy #305

Stream: general

Topic: Component model critique

Kevin Moore (May 22 2024 at 22:14):

Dan Gohman (May 22 2024 at 22:29):

Dan Gohman (May 22 2024 at 22:36):

Pat Hickey (May 22 2024 at 23:27):

Pat Hickey (May 22 2024 at 23:33):

IFcoltransG (May 22 2024 at 23:41):

Kevin Moore (May 23 2024 at 02:25):

Ralph (May 23 2024 at 10:20):

Ralph (May 23 2024 at 10:21):

Ralph (May 23 2024 at 10:23):

Ralph (May 23 2024 at 10:23):

Ralph (May 23 2024 at 10:25):

Ralph (May 23 2024 at 10:27):

Ralph (May 23 2024 at 10:28):

Christof Petig (May 23 2024 at 12:10):

Ralph (May 23 2024 at 13:58):

code red art (May 24 2024 at 05:36):

Ryan Levick (rylev) (May 24 2024 at 10:07):

Ralph (May 24 2024 at 10:19):

Ralph (May 24 2024 at 10:19):

Ralph (May 24 2024 at 10:20):

Ralph (May 24 2024 at 10:20):

Ralph (May 24 2024 at 10:20):

Frank Rehwinkel (May 24 2024 at 13:00):

Brooks Townsend (May 24 2024 at 13:14):

Ryan Levick (rylev) (May 24 2024 at 13:50):

Ralph (May 24 2024 at 14:53):

code red art (May 24 2024 at 17:19):

Karel Hrkal (kajacx) (May 27 2024 at 09:30):

Karel Hrkal (kajacx) (May 27 2024 at 09:39):

Ralph (May 27 2024 at 10:19):

Andrew Chin (May 31 2024 at 03:07):

IFcoltransG (May 31 2024 at 03:15):

Andrew Chin (May 31 2024 at 04:19):

Piotr Sarnacki (Oct 07 2024 at 14:36):

Ralph (Oct 07 2024 at 14:57):

Till Schneidereit (Oct 08 2024 at 14:46):

CryZe (Oct 08 2024 at 19:30):

IFcoltransG (Oct 08 2024 at 20:16):

CryZe (Oct 08 2024 at 20:25):

Alex Crichton (Oct 08 2024 at 20:28):

CryZe (Oct 08 2024 at 20:44):

Alex Crichton (Oct 08 2024 at 20:46):

Till Schneidereit (Oct 09 2024 at 20:47):

Till Schneidereit (Oct 09 2024 at 20:50):

Till Schneidereit (Oct 09 2024 at 20:53):