Re:Extensible WASM Applications with Go
by coder543 on Friday February 14, 2025 @09:58AM
(#43048969)
Yes… I’m aware of the history. I’m also aware that WASM solves problems that those previous ones didn’t. Otherwise you would have provided an option that actually met the requirements, if there are so many to choose from.
> If you want a plugin-in system, maybe don't pick a language with static linking
Or… a plugin system could “just work”, without placing unnecessary restrictions on what I do.
It starts by choosing the right language for the job.
The right language for a plugin system is the one that attracts the most plugin writers. Supporting many languages is a huge boon for wasm in this department. It's one of the things that makes the JVM and .NET so appealing in the first place, but WASM is better than both combined when it comes to language selection.
That surely isn't any WebAssembly then, if we are counting adoption growth throughout computing history.
How do I prevent my statically linked plugins from having any filesystem access, or a bug messing with memory it doesn’t control once it’s loaded?
OS IPC and security configuration, no need to add a WebAssembly runtime and compiler toolchain.
So: slow, hard, complex and highly OS specific vs simple and secure.
Right.
Because WASM tooling is so much better, thank goodness for emscripten.
WebAssembly outside of the browser is a solution looking for a problem that has been sorted out multiple times since the idea of bytecode based execution exist, 1958 to be more precise.
Even on the browser its use, besides bringing back the old plugins is debatable, using GPU compute is much better for number crunching, with much better tooling.