Maybe I’m missing something, but this seems to miss the actual hard part: binding the host and the plugin. The current state of wasm specs already allows passing memory – what’s needed is a way to pass memory such that there’s not a pack/unpack step on every call. The “wasm interfaces” was supposed to be this, but it’s largely stalled out last I checked.
As with most things, there is a relevant xkcd.
n.b. I work in this space at a direct competitor to Extism.
Even worse, with their example just being a string… it’s kinda useless. Any RPC cross-language is nearly trivial for scalars and sometimes it completely goes from “nice” to “abyssal horror” if you use an array or object. I don’t even know if their WASM code would accept a json-style array of numbers or not.
One of the most annoying things is strings. Not every language uses the same underlying storage for strings. It requires shimming the Wasm blob with normalization code. You’re right that data interchange is a non-trivial problem.
So it looks like all the plugins can do is expose functions that take and return data. I don’t see any facility for the host app to expose functions that can be called by plugins, let alone a way to share object references.
Without that, this seems very limited. Most of the cool things real plugins do involve interacting with the host’s data model, like an IDE plugin that can see the file hierarchy and view or modify source code ASTs, or an email plugin that can search and refile messages.
A real example of this difference just came to mind: the Xcode IDE used to have an unofficial plugin ecosystem that took advantage of code injection and Objective-C’s dynamic runtime. It was fragile but there were some really useful plugins. Then Apple blocked the code injection and added an official Xcode plugin API … which just lets a plugin read and modify the current text selection. That’s not very powerful and there are only a handful of available plugins.