[phickey]

Thanks for using wasmtime! I worked on the component bindings generator you’re using and it’s really nice to see it out in the wild.

To elaborate a bit further: wasmtime ships a [bindings generator proc macro](https://docs.wasmtime.dev/api/wasmtime/component/macro.bindg...) that takes a wit and emits all the code wasmtime requires to load a component and use it through those wit interfaces. It doesn’t just check the loaded component for the string names present: it also type checks that all of the types in the component match those given by the wit. So, when you call the export functions above, you can be quite sure all of the bindings for their arguments, and any functions and types they import, all match up to Rust types. And your component can be implemented in any language!

[bschwindHN]

Thanks so much for your work on this! So far it's been a good pattern for adding hot-reloadable logic to my Rust projects.

Next up I'm hoping to integrate this stuff into a game so you can have hot-reloadable game logic, with the potential for loading and sandboxing user-created mods.

[90s_dev]

Would wasmtime be a good general purpose scripting extension layer for a C program in the style of embedded Lua but faster and more generic? Is that a reasonable use-case?

[phickey]

Wasmtimes C bindings for components are still a work in progress. In general C programming is always going to require more work than Rust programming, due to the limitations of C abstractions, but at the moment it’s also held back by how much energy has gone into the C bindings, which is much less than the Rust bindings which many of the maintainers, myself included, created and are using in production at their day jobs.

More info: https://github.com/bytecodealliance/wasmtime/issues/8036 Several folks have volunteered work on the C bindings over the last year or two, with this contributor making progress most recently: https://github.com/bytecodealliance/wasmtime/pulls?q=is%3Apr...