← Back to context

Comment by 90s_dev

3 months ago

How is that not also stringly typed?

                match Plugin::instantiate_async(&mut store, &component, &linker).await {
                    Ok(plugin) => {
                        match plugin
                            .plugin_guest_oncallback()
                            .call_ontimedcallback(&mut store, &callback_name)
                            .await
                        {
                            Ok(()) => debug!("Successfully called oncallback for {plugin_path:?}"),
                            Err(e) => warn!("Failed to call oncallback for {plugin_path:?}: {e}"),
                        }
                    }
                    Err(e) => {
                        error!("Failed to call oncallback for {plugin_path:?}!: {e}");
                    }
                }

See the "call_ontimedcallback"? It's not a string. The compiler ensures it exists on the Plugin type generated from the .wit file.

If of course I put a wasm file in the plugin folder that doesn't adhere to that definition, that wasm file isn't considered a plugin.

  • 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!

    • 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.

    • 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?

      1 reply →

  • Ah, fair enough. So it is still stringly typed, it's just verified at compile time. Which I guess is true about all compiled functions ever.