I'm trying to figure out what Extism is actually providing here.

The underlying runtime appears to be Wasmtime, an existing project that you can use separately.

For the system API, Extism supports WASI (a POSIX-like API for WASM) which is already supported by Wasmtime. However it sounds like it also has a different, non-WASI API that provides similar functionality. I'm curious to hear a compare/contrast between these two system APIs, or what motivated inventing a new non-WASI system API. It does appear that WASI is in its early days; WASI was announced in 2019 (https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...) but it appears that all of the specific proposals are still early stage and far from being standardized (https://github.com/WebAssembly/WASI/blob/main/Proposals.md).

For the API, Extism provides a C API/ABI that can be called through FFI, but AIUI Wasmtime already has such an API: https://docs.wasmtime.dev/c-api/

Basically I'm trying to understand the conceptual difference between this project and Wasmtime.

Looks interesting. Based on prior experience, here are some concerns people will bring up with this approach:

1. Spectre. You may have to assume the plugin code can read anything in the address space including any secrets like passwords, keys, file contents etc. If the plugin can't communicate with the outside world this may not be a problem.

2. When you say WASM has a "sandboxing architecture", this is only partially true. It's quite easy to define a simple language that doesn't provide any useful IO APIs and then claim it's sandboxed - that's practically the default state of a new language that's being interpreted. The problems start when you begin offering actual features exposed to the sandboxed code. The app will have to offer APIs to the code being run by the WASM engine and those APIs can/will contain holes through which sandboxed code can escape. If you look at the history of sandboxing, most sandbox escapes were due to bugs in the higher privileged code exposed to sandboxed code so it could be useful, but you can't help devs with that.

3. WASM is mostly meant for low level languages (C, C++, Rust etc). Not many devs want to write plugins in such low level languages these days, they will often want to be using high level languages. Even game engines are like that: "plugin" code is often written in C#, Lua, Blueprint, etc. This is especially true because WASM doesn't try to solve the API typing/object interop problem (as far as I know?), which is why your example APIs are all C ABI style APIs - the world moved on from those a long time ago. You'll probably end up needing something like COM as otherwise the APIs the host app can expose will be so limited and require so much boilerplate that the plugin extension points will just be kind of trivial.

Authors are here to answer questions! To add a little bit of detail:

Extism is an open-source universal plug-in system with the goal of making all software programmable. Easily embed Extism into 13 popular programming languages (server or browser) and safely run high-performance WebAssembly plug-ins inside your code.

What does it mean to "make software programmable"? Simply put, you can give end-users the ability to extend your software with their code.

Plug-in systems are usually implemented in 3 ways: 1. execute a binary that is external to your process (like protoc) 2. re-compile a program with an implementation of some interface 3. dynamically link to native code / dlls

All 3 have major trade-offs on the performance-to-security ratio. Extism provides a way to "have your cake and eat it too" in a sense, that it doesn't compromise security for performance. True, executing WebAssembly as we do here is not running at fully native speed, but it's darn close. And its sandboxed architecture offers the security you want if you're considering an alternative to dll/dlopen.

We're only getting started here, and welcome feedback good and bad. Please join our Discord[0] if you want to chat, or open issues on GitHub[1].

[0]: https://discord.gg/cx3usBCWnc [1]: https://github.com/extism/extism/issues

Hey folks, one of the authors here. Extism is a plug-in system. If you aren't familiar with this terminology, plug-in systems make your software programmable by end users such as your customers or your open source community (e.g. VS-Code Extensions). 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.
Extism tries to cover two completely different things in one package: 1) runtime 2) component model. And this is a problem. Those things should be separated because the component model would be useful independently, without any ties to the specific runtime environment be it WebAssembly or something else.

We already saw this playbook many times before. For instance, .NET. It has a handy set of system types that define the component model, but surprise, it can only be used in the realm of .NET which makes it unusable in, say, Go. Java - the same thing. C++ is the same. Everything more abstract than some primitive data types and plain functions just cannot cross the boundaries between the language ecosystems.

If we had a standard component model then it would allow us to create a library in one language and then use it from many other languages without any manual work. But all we have now is the old plain C-like API as a common denominator between them. It's 1978 all over again for the last 40 years. But I still believe that we can do better than that.

Instead of m * n complexity when every library is doomed to be manually ported to n languages, we may have just m + n complexity by leveraging the benefits of a standard component model. Just imagine the economic effects of such achievement.

The main problem of an imaginary de-facto standard component model is the danger of being opinionated. We should solve that, otherwise all such efforts will be doomed to fail from the beginning.

Data and functions are good starting points, and they are universal by the laws of math and algebra. That's why they are not opinionated. Consequently, they are used everywhere. We should build a similar formal apparatus for, say, objects to allow OOP interoperability between the languages once and for all.

"make all software programmable"

doesn't mean anything to me, and I doubt it means much to a lot of others either.

I'm just talking a basic marketing fail here. bhelx below made it make more sense that their whole intro page.

Three thoughts:

* That's an absolutely viscerally horrifying logo

* I absolutely love it and its design

* I am confused about why it's used for a project like this and not some kind of internal NSA project, or maybe a nu-witch house band logo, or something

Interesting (I think), but the page lacks a problem statement that the project seeks to solve.

As others have noted, "make all software programmable" seems a bit vague. And it's vague because there's no problem in there. When is software not programmable?

I think the idea is to make application extensions easier to integrate (like photoshop plugins), but I'm not sure.

Start with the problem statement, and everything else will fall into place. Leave out the problem statement, and leave your readers mystified.

I've built a plugin-system back in 2003 or so based on the JVM which can load/re-load bytecode relatively easily.

(the concept became popular in the JVM world and lead to abominations like OSGi)

The problems that arose quickly were: - Executing order of plugins attaching to the same extension point.

- Third party library dependencies having different versions

- Traceability and debugging

- Thread-safety

OTOH, it gave our custom dev team to develop integrations and extensions that could be deployed and maintained independently of the main product. So there's definitely a use-case in there, but it requires some coordination regardless.

The manifest format could perhaps be less terse. It's really hard to guess what this actually means without reading the docs:

  "memory": {
    "max": 5
Presumably the maximum amount of memory available to the plugin, but which unit? 5 megabytes?

Turns out it's measured in pages of 64k each: "The units here are pages where a page is 64Kib." [1]

So max==5 apparently means a hard upper limit of 320 kB. (For when you want to run a 1984 copy of WordPerfect as a plugin, of course.)

Maybe a "max_MB" property might be more useful to plugin authors, and then just calculate the # of pages internally from that?

[1] https://extism.org/docs/concepts/manifest#schema

The pdk is missing Zig which is, for many developers, considerably the best for wasm target. It's as fast as Rust (from benchmark I saw, Rust is fastest), though Zig's binary size is as small as AssemblyScript's. Rust's binary size is considerably in a range of middle to large, mostly middle.

It would be nice if there's an official wasm benchmark of source languages, showing speed and binary size comparison.

As others have said, the term "software" is confusing. Application or software product seem more apt.

The other small point I'd raise: there's mention that due to the sandboxing of WASM it's "safe" to run untrusted code. Maybe I've misunderstood. To me that seems true in so far as the untrusted code cannot break out and can only do actions the hosting app decides to allow, but this isn't much consolation if the app allows actions that can be subverted.

For instance, if the app allows control over saving a file, untrusted code only gets to handle that within the rails the app sets but that still means dodgy code could fill up a hard drive by saving over and over, or it could possibly save over important files.

I wonder how this compares to https://suborbital.dev/
Congrats on the launch! Just yesterday I was pondering if I could do something like this for a saas I’m working on: I’d like to offer users the ability to extend their dashboard in certain ways (a la WP/Shopify plugins), but those ways require extending the ui AND the server code.

Extism seems like a great fit for this, I’ll definitely be checking it out :)

This looks fantastic! I'm working on a desktop app and I've been struggling with the extensibility story in the back of my mind for a couple of weeks now.

Thanks for building this!

edit: For what it's worth, the use case and value of something like this was immediately apparent to me.

To be honest, I don't see why it is advertised here at this stage. I appreciate effort, but project is too young and unable to do any serious plugin. I guess it is try to get new contributors on board?

I see that project on github started few months ago. Isn't it too early to adwertise it to the world?

But it already have fancy website with modern styles and so on. But it lacks good documentation.

Article says that docs have "dozens of examples in different languages", but it just have dozen languages and helloworld in them.

And basically examples are just simple function call from host to plugin. Operating on strings/basic types, and JSON.

That's not what we want from plugins. Wee need some way to expose Host API some way, perhaps in OOP fashion. To let plugin interract with host app, perhaps even change UI.

But not of examples show that, how to pass at least basic functions into plugin.

As I understand it comes with it's own HTTP stack, presumably implemented in Rust. This can be used as starting point to make your own macro processor that would be able to expose API for plugins, and then dogfoof this codegen for your own HTTP lib.

And passing JSON around is not thing that is needed. With same success IPC could be used, with relatively similar performance.

We need proper marshaling.

There much work to be done, sadly. That's big endeavor.

Well, I hope this project would grow in something good, but it's in really early stage.

If I understand it correctly, it is as overlap with the "sidecar" design-pattern, correct? (https://learn.microsoft.com/en-us/azure/architecture/pattern...)

If so, then super interesting product! Have actually had a somewhat similar idea myself for a product that allows you to create "subsystems" that are isolated from one another, allowing you great freedom in how the subsystems are deployed. They could be deployed all on the same machine, or, if greater scalability is needed, a subsystem (or plugin) could be moved to its own machine, or even scaled up to run multiple instances.

Have only read through the simple code example on your website, but also, it would be great if there was a standard for calling and receiving requests through FFI's. Because this would give it the utmost flexibility on where the plugins can be deployed to. To me, this means both the actual mechanism for the call (REST over HTTP, graphQL...) and in the plugin and host themselves, with the syntax of the call. So for the syntax, it would also be great if this looked more like a regular method call instead of having to wrap parameters in an object:

  hostWrapper.somemethod(param1, param2) or
  hostWrapper.call("somemethod", param1, param2)

(Although, not sure how difficult this is to do, given all the different method call syntaxes of the different languages).

And, am glad that you and your company is really trying to make this happen, it's a great idea! Looking forward to giving it a try!

I'd love to see C# support for something like this as well. Would be nice if Unity games could start supporting wasm plugins. Not sure if something like that works for Ureal already.

Another question... Is something like this possible on iOS or will these kinds of runtimes be banned by Apple?

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.

For those who want to go straight to the code: https://github.com/extism/extism
If I want to make all software programmable, I install Frida and easily hook into pretty much anything at the same privilege level.

Still, misleading headline aside, this sounds pretty cool as a reasonably well sandboxed plug-in architecture for software that chooses to use it.

Though if running in-process, it seems unlikely to be able to defend against hostile plugins that use e.g. speculative execution techniques to extract otherwise inaccessible data. But perhaps that's not the threat model here.

As others have mentioned, "making software programmable" isn't really landing for me.

In the tradition of borrowing terms from the games industry (where we often see early popularization of good ideas), I wonder if "modding" could be a helpful addition somewhere in your marketing.

This seems to have worked for the term "multiplayer", though "moddable" probably isn't as widely appreciated yet.

Will WASM finally be the write once run everywhere system we've been promised for the past few decades?

I can imagine every language compiling to the common format that is WASM, so you can mix and match libraries from other languages as you please, as well as chip manufacturers adding hardware accelerated WASM processing units if it gets popular enough.

This really is the birth and death of Javascript.

Huh, just a week ago I thought it would be cool to add WASM plugins to my Go app, as a way to not be dependent on Go for plugins.
Interesting. Just this week I've been building a little experiment in order to utilize WASM based plugins in a project I'm involved with. I'm using WasmEdge for the task and so far am having pretty good luck.

Questions: 1. Can WASM plugins with Extism easily call back into host provided APIs? 2. Complex types are supported?

Damn, this looks really cool. I've wanted to add wasm support to my project at work for some time now, but unfortunately with no good C# integrations (with Unity as the host), it just hasn't met the mark yet. Really hoping that can be addressed in the near future.
I'm thinking on this for second day, and this though can't leave my head.

It sounds like sexism. And thous I think it's bad name. It continues ringing the bell for me.

Is the interface defined through wit?


I'm genuinely curious: is the WebAssembly ecosystem just reinventing the JVM piecemeal? "Write once run anywhere"?
How big is the WASM runtime? If I embed Extism in my application what is the impact on install size and memory usage?
WebAssembly ecosystem booming it seems.
How are you implementing JS platform support, is it a WebAssembly JS interpreter?
Why not use protobuf for serializing data between plugin and host language?
Does it require JIT? In other words, does it work in iOS?
More like, "make all software exploitable"
Is it possible to run wasm blobs directly on Linux?
Why not continue using long-standing C FFI?

This is not so clear.

This page needs a working example use-case.
Is it single threaded?
and...still no dotnet