Plug WASM into Rust with wit-bindgen

WASM only provides four types. Wasm-bindgen solves the problem of marshaling and unmarshaling of complex types for Rust to WASM to Javascript for Running WASM in a browser. But wasm-bindgen doesn't work for plugging WASM into Rust
Wit-bindgen to the rescue!
Wit-bindgen can be found here:
github.com/bytecodealliance/w...
My Example Code can be found here:
github.com/masmullin2000/wit-...
Image by: Clint Patterson
unsplash.com/@cbpsc1

[@nicolassturm8853]

nice video man, good to see zed editor implementing this for their plugins system right now 🔥

[@thajafsal]

Thanks Michael

[@dynamite-bud]

you inspired me Michael. Thank you

[@aussieexpat]

thanks for the presentation man. This area of x -> wasm ->x capability is very hard to follow right now. Was not even aware of fp-bindgen.

[@uquantum]

Thanks Michael: great overview, example code (unavoidably clunky🙂at this pre-alpha stage) and appreciate the concrete use cases. So while fp-bindgen is optimized for rust->wasm->rust, and wasm-bindgen does rust->wasm->JS, wit-bindgen has the greater ambition to provide any->wasm->any! Exciting update: there's now a wit-bindgen crate (v 0.0.0), very actively worked on.

[@GlobalYoung7]

Thank you 😊

[@masmullin]

You're welcome 😊

[@jeffg4686]

This is cool. I was thinking of "plugin" model for wasm not long back. Like, allowing a programming like Blender / Bevy to have their plugins coded in any language (that can be compiled to wasm). Can you speak at all to the speed of marshalling as compared with something like the python embedded in blender. Crossing that barrier between the scripting and native always seems to be a lot of overhead (when crossing frequently - fine grained api), and I wonder if the same is true with WA or if it's not really any overhead at all (haven't finished video yet, so maybe discussed further - just something that popped to mind and thought I'd get down). One thing I can imagine is that authors of the application serving as the "plugin environment" might want to publish a portion of their API in WA ( a client API). Especially thinking in terms of minimizing the crossing of the barrier between host and hosted. So, the client api might be "building" data that all gets sent once built, but the building of it is all WA, and doesn't cross the host/hosted boundary. I just wanted to bring this up because the relationship between that client API and the "infrastructure" might be relevant in some way. I don't know all the possibilities, but thinking, for one, in terms of pre-loading client-api into the environment (not sure if that's really relevant or not). But, just think that side - client apis mostly in terms of making more coarse grained at the boundary level

[@uoweme5grand]

I understand that the instantiate is part of the boilerplate code but is it possible to go over it somewhat. More specifically: - Why is it that we need to pass in closure to instantiate the modules? - Why does the context need to have a shape of { wasi, imports, exports }?

[@aussieexpat]

man... this soooo much less nice than running node -> rust using wasm-bindgen But I guess it's close to the best we've got for doing rust to rust or hopefully X to X eventually.

[@TekExplorer]

this video is very quiet :(