4 ms·

The idea is to offer extensibility points in software by embedding their runtime into your current software. Say you have a database and instead of a DLS for qu

by ctvo 4y ago

The idea is to offer extensibility points in software by embedding their runtime into your current software. Say you have a database and instead of a DLS for querying, allow someone to upload a WebAssembly binary that has access to APIs you'd expose (`filter`, `map`, ...). I'm guessing they ease some of the complexity in moving data back and forth, their runtime is supported on N languages, and they use wasm's sandboxing properties. The problem, for me, is even though the runtime supports many languages, the languages the plugins can be written in is limited. Rust and Go support wasm well, but AssemblyScript* is not JavaScript / TypeScript. If the idea is to extend software and make it more accessible, they need better support for interpreted languages: JS, Python, Ruby, ... * - Closures are still not supported: https://github.com/AssemblyScript/assemblyscript/issues/798 https://github.com/AssemblyScript/assemblyscript/issues/798

meltedcapacitor 4y ago
Yes! Shipping more copies of interpreter runtimes in trivial plugins is exactly what the world needs.
- ctvo 4y ago
  Or solve it a different way. I don't think your users care. It doesn't change the fact that it's a limiting factor right now.
- bhelx 4y ago
  There will be ways to handle this problem in the future with the Component Model spec. I've seen it working but it's not easy to do yet. As of today though, yes bringing your own runtime is costly.