3 ms·

I've been developing on top of wasm (wasmtime, specifically) for several years now. I personally have my doubts about how broadly the components specification

I've been developing on top of wasm (wasmtime, specifically) for several years now. I personally have my doubts about how broadly the components specification (which this cloud platform seems to depend on) will be adopted. Maybe I'm just not very smart, but it feels like one of the things I loved the most about WebAssembly, its simplicity, is being lost. To get even basic things done with WASI, you now have to figure out which flavor to pull in (preview 1, preview 2, ... need any async [0], that's coming preview 3?), learn a new IDL language [1] that defines the component's spec, figure out its codegen toolchain [2]. It's all very reminiscent of COM, CORBA and all the other times this has been tried in the past. In any case, wasmtime is an amazing project and I'm grateful for it. They've already had to bifurcate the library to support WASI and components. I just hope non-WASI/component code retains its status as a first class citizen in the project. [0] https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i-Yoy0N2QPU2C--LzVuoGSlE/edit?pli=1#slide=id.g1270ef7d5b6_0_662 https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i... [1] https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md https://github.com/WebAssembly/component-model/blob/main/des... [2] https://github.com/bytecodealliance/wit-bindgen https://github.com/bytecodealliance/wit-bindgen

jcmfernandes 2y ago
Thanks for your feedback. Components and WIT seem powerful to me, though. I'm building an execution environment on top of a niche programming language, and components allow me to easily extend it with libraries written in other programming languages without having to link my application against anything and use FFI.
brooksmtownsend 2y ago
To start with a bit of project history, we love Wasmtime and that’s our core runtime of choice! Before wasmCloud 1.0, e.g. from 2019-2023, we only used Wasm modules with our own custom ABI. Literally everyone was doing this at the time, to run Wasm you either needed to adopt a platform with a custom ABI or invent it yourself and re-solve all the same problems. The component model and its canonical ABI was a huge opportunity for us to stop maintaining our own and integrate into the ecosystem; now you see examples in projects like Moonbit which just work with wasmCloud out of the box, huge win for us https://www.moonbitlang.com/blog/component-model https://www.moonbitlang.com/blog/component-model. On the WASI side itself, I understand that moving WASI from p1 to p2 was a big but necessary leap. Everyone wanted sockets and HTTP and there was no easy way to rev the monolithic ABI of preview1 to add what was needed in small increments. That’s why you see adapters to move from p1 to p2, which wrap a Wasm module with component metadata, but a component actually just straight up contains the module (you can see it if you look at the textual representation.) We’ll have the same thing from p2 to p3. Not to mention, some systems that don’t support the component model like in Node.js actually “unbundle” the inner module from the component and that works just fine. So from what I understand, module support will never be dropped.
brooksmtownsend 2y ago
Oh, and though WIT can be in-your-face in these tutorials (as we try to leave a good offramp for folks to customize beyond the quickstart) WIT shouldn’t be necessary for most common use-cases. There are standardized interfaces that language toolchains may support out-of-the-box, e.g. TinyGo supporting wasi-cli by default with the wasip2 target. If you use the SDKs in wasmCloud or Rust crates like wstd, then the interfaces are selected automatically since they’re being used behind the functions in the SDK itself. It’s meant to be lower level and handled by toolchains and library developers.

jcmfernandes 2y ago

Thanks for your feedback. Components and WIT seem powerful to me, though. I'm building an execution environment on top of a niche programming language, and components allow me to easily extend it with libraries written in other programming languages without having to link my application against anything and use FFI.

brooksmtownsend 2y ago

To start with a bit of project history, we love Wasmtime and that’s our core runtime of choice! Before wasmCloud 1.0, e.g. from 2019-2023, we only used Wasm modules with our own custom ABI. Literally everyone was doing this at the time, to run Wasm you either needed to adopt a platform with a custom ABI or invent it yourself and re-solve all the same problems. The component model and its canonical ABI was a huge opportunity for us to stop maintaining our own and integrate into the ecosystem; now you see examples in projects like Moonbit which just work with wasmCloud out of the box, huge win for us https://www.moonbitlang.com/blog/component-model https://www.moonbitlang.com/blog/component-model. On the WASI side itself, I understand that moving WASI from p1 to p2 was a big but necessary leap. Everyone wanted sockets and HTTP and there was no easy way to rev the monolithic ABI of preview1 to add what was needed in small increments. That’s why you see adapters to move from p1 to p2, which wrap a Wasm module with component metadata, but a component actually just straight up contains the module (you can see it if you look at the textual representation.) We’ll have the same thing from p2 to p3. Not to mention, some systems that don’t support the component model like in Node.js actually “unbundle” the inner module from the component and that works just fine. So from what I understand, module support will never be dropped.

brooksmtownsend 2y ago

Oh, and though WIT can be in-your-face in these tutorials (as we try to leave a good offramp for folks to customize beyond the quickstart) WIT shouldn’t be necessary for most common use-cases. There are standardized interfaces that language toolchains may support out-of-the-box, e.g. TinyGo supporting wasi-cli by default with the wasip2 target. If you use the SDKs in wasmCloud or Rust crates like wstd, then the interfaces are selected automatically since they’re being used behind the functions in the SDK itself. It’s meant to be lower level and handled by toolchains and library developers.