Hacker News Reader

Comment by tomrod | Hacker News Reader

I feel like I'm missing the bead.

What does it mean to "make all software programmable" -- meaning make Wasm work with all languages? Is this really feasible?

Maybe I'm simply getting old and don't understand recent jargon shifts.

View on HN

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

Yes! Shipping more copies of interpreter runtimes in trivial plugins is exactly what the world needs.

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.

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.

Extism is a plug-in system. Plug-in systems make your software programmable by end users (such as your customers or your open source community). Currently plug-in systems are quite difficult to build and limited to certain host and guest languages. Extism makes this easier regardless of your language or domain knowledge.

> Plug-in systems make your software programmable by end users (such as your customers or your open source community)

I am confused. Who is the "end user" or the "customer? It seems like "developer" who is writing software for a customer is your end user or may be not. Who will actually use this is not clear from the website.

From couple of examples I think this comes close to something like a SQL CLR integration, where for example you can call a C# routine from SQL query.

https://learn.microsoft.com/en-us/dotnet/framework/data/adon...

Your end user would be a user of your application, e.g. a customer. But it could also be a marketplace like situation where people are developing plugins for your customers. Examples of plugin systems are things like VS-Code Extensions, Figma plugins, firefox extensions, etc.

Here is a good example of a wasm plugin system for an open source project: https://istio.io/latest/docs/reference/config/proxy_extensio...

No, it took me a bit to understand as well. It looks like a set of host SDKs and a sandboxed runtime (guessing this is why they're using wasm) you can drop into your own software and expose some hooks that would allow your users to write their own plugins for your app in a variety of languages.

I think it would be better described as a 'universal framework for incorporating plugins into your application'. If I am right about these aspirations, they are quite grandiose. Shiver Shades of COM or corba reborn?

If I understand it, this is more about the plumbing of calling the Rust wasm execution engine from various languages. And probably the secondary problem of how do you package wasm-hosted code such that it can interface with multiple calling languages. Rust can build a shared object with C linkage. All the languages have ways to call "native" code (code with C linkage). This is the sauce to connect those dots in a multi-language, batteries-included way. Hopefully I got that right.

It's all in-process so not more like OLE than Corba ;)

You got that right! :)

Reply on news.ycombinator.com