[abendstolz]

Very cool!

But I prefer the wasmtime webassembly component model approach these days.

Built a plugin system with that, which has one major upside in my book:

No stringly function invocation.

Instead of run_function("my-function-with-typo") I have a instantiated_plugin.my_function call, where I can be sure that if the plugin has been instantiated, it does have that function.

[bobajeff]

This sounds like a good approach to overcoming rusts slow compile times and lack of dynamic linking. One thing I'm concerned about with this path is what about hot reloading and fast script running? Doesn't everything in the wasm component model need to be compiled first? I imagine that would remove some of the advantages to using a scripting language like JavaScript or Python.

[abendstolz]

You're right. Hot reloading isn't done by default.

I manually compile a plugin and in my system I can "refresh" a plugin and even say "activate version 1.1 of the plugin" or "activate version 1.2" of the plugin etc.

But that's something I had to build myself and is not built into wasmtime itself.

[zamalek]

Alternatively, whenever designing a scripting/plugin host make sure to support plugin-hosting-plugins. That way you could have the Roto plugin host complied to wasm.

[abendstolz]

Sounds interesting but at the same time a bit complex.

I assume you wouldn't ship the whole plugin runtime for each plugin that wants to host another plugin?!

[90s_dev]

How is that not also stringly typed?

[abendstolz]

                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.