4 ms·

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 pro

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 https://discord.gg/cx3usBCWnc [1]: https://github.com/extism/extism/issues https://github.com/extism/extism/issues

RodgerTheGreat 4y ago
There's at least one more approach to program extensibility that you should probably address: interpreted languages, especially Lua. Many games and utilities today use Lua or JS as an extension language. They have battle-tested runtimes, come with high-performance JITs, and provide the potential for rich interactive debugging and incremental development options that are not free with a WASM-based statically-compiled approach.
- nilslice 4y ago
  Thank you - that's a great point, and totally slipped my mind when writing this.
- bhelx 4y ago
  We think Lua is great and in many ways, Wasm has yet to catch up! I do think it's still early days for Wasm, but it will.
- localhost 4y ago
  There are even entire applications written this way - Adobe Lightroom was originally built from some core C++ imaging code lifted from Photoshop but with all of the UI built in Lua. The dev builds of Lightroom have an entire integrated Lua dev environment in them.
traverseda 4y ago
So what is the plan for higher level languages? Let's say I wanted to be able to write extensions in python, is that one the roadmap at all?
- bhelx 4y ago
  If that is something you need come join the discord and let's work on it! I've been experimenting with higher level languages, specifically quickjs (js) and c#. Python should work from what I know, but I can't speak intelligently to how well it would work.
exelib 4y ago
You should put it into one-two sexy sentences. It was too difficult to understand why do I need it.
noveltyaccount 4y ago
This is really interesting to me. I used to run a team that owned a software library (that you've probably heard of) that runs on Mac, Windows, iOS, Android, and embedded Linux. The product is over a decade old, so it's in C++ because that was the only real choice back then. We bolted on static analysis yet still had senior engineers working full time to iron out stability issues (deadlocks and other race conditions). I've been thinking about alternatives for a while now; Rust naturally, but also C# with Native AOT in .NET 7 (only supports Windows and Linux so far, but maybe in the future). It got me thinking though, why have to choose? There are a good number of languages that can compile to WASM, so maybe just bridge the platform-native presentation layer to WASM and put all the core logic in WASM. It "should" provide near-native performance and open up many other languages, and provide a nice migration path to run the existing C++ and new code in another language side-by-side. I know it's not explicitly the goal, but Extism seems like it could provide that functionality. I'll be following this project!
- nilslice 4y ago
  Very interesting, would love to know more about the library ;) It does sound like you have found a _great_ use case for WebAssembly, and yes, Extism could provide similar functionality! We call it a "plug-in system" because that's a fairly concrete thing to say, but there are many other ways to use it.
kodablah 4y ago
Awesome. Now I just need a way to define a cross-language contract and this would be very helpful for my uses. Ignoring performance for a second, one wonders if you could take proto and use that as the data in/out _and_ the API/RPC definition. Like many others, I've been wanting to add plugin support to my software, but I want a well-defined contract usable from others w/ complex types and known RPC calls. I think code-gen from proto for all supported client/host languages could get you there (at a perf cost compared to flat buffers or capn proto).
- nilslice 4y ago
  Yes, protobuf can absolutely be used here. You just want to make sure that the plug-in language supports it.
raible 4y ago
I've had great success with a fourth way: my project language compiles to C, which is loaded at runtime with libtcc (specifically: git://repo.or.cz/tinycc). I've gone down the .so/.dll route a few times in the past, but I can safely say: never again. libtcc has the advantages of a jit (native C speed), but with an elegant API and laudable portability.

RodgerTheGreat 4y ago

There's at least one more approach to program extensibility that you should probably address: interpreted languages, especially Lua. Many games and utilities today use Lua or JS as an extension language. They have battle-tested runtimes, come with high-performance JITs, and provide the potential for rich interactive debugging and incremental development options that are not free with a WASM-based statically-compiled approach.

nilslice 4y ago
Thank you - that's a great point, and totally slipped my mind when writing this.
bhelx 4y ago
We think Lua is great and in many ways, Wasm has yet to catch up! I do think it's still early days for Wasm, but it will.
localhost 4y ago
There are even entire applications written this way - Adobe Lightroom was originally built from some core C++ imaging code lifted from Photoshop but with all of the UI built in Lua. The dev builds of Lightroom have an entire integrated Lua dev environment in them.

traverseda 4y ago

So what is the plan for higher level languages? Let's say I wanted to be able to write extensions in python, is that one the roadmap at all?

bhelx 4y ago
If that is something you need come join the discord and let's work on it! I've been experimenting with higher level languages, specifically quickjs (js) and c#. Python should work from what I know, but I can't speak intelligently to how well it would work.

exelib 4y ago

You should put it into one-two sexy sentences. It was too difficult to understand why do I need it.

noveltyaccount 4y ago

This is really interesting to me. I used to run a team that owned a software library (that you've probably heard of) that runs on Mac, Windows, iOS, Android, and embedded Linux. The product is over a decade old, so it's in C++ because that was the only real choice back then. We bolted on static analysis yet still had senior engineers working full time to iron out stability issues (deadlocks and other race conditions). I've been thinking about alternatives for a while now; Rust naturally, but also C# with Native AOT in .NET 7 (only supports Windows and Linux so far, but maybe in the future). It got me thinking though, why have to choose? There are a good number of languages that can compile to WASM, so maybe just bridge the platform-native presentation layer to WASM and put all the core logic in WASM. It "should" provide near-native performance and open up many other languages, and provide a nice migration path to run the existing C++ and new code in another language side-by-side. I know it's not explicitly the goal, but Extism seems like it could provide that functionality. I'll be following this project!

nilslice 4y ago
Very interesting, would love to know more about the library ;) It does sound like you have found a _great_ use case for WebAssembly, and yes, Extism could provide similar functionality! We call it a "plug-in system" because that's a fairly concrete thing to say, but there are many other ways to use it.

kodablah 4y ago

Awesome. Now I just need a way to define a cross-language contract and this would be very helpful for my uses. Ignoring performance for a second, one wonders if you could take proto and use that as the data in/out _and_ the API/RPC definition. Like many others, I've been wanting to add plugin support to my software, but I want a well-defined contract usable from others w/ complex types and known RPC calls. I think code-gen from proto for all supported client/host languages could get you there (at a perf cost compared to flat buffers or capn proto).

nilslice 4y ago
Yes, protobuf can absolutely be used here. You just want to make sure that the plug-in language supports it.

raible 4y ago

I've had great success with a fourth way: my project language compiles to C, which is loaded at runtime with libtcc (specifically: git://repo.or.cz/tinycc). I've gone down the .so/.dll route a few times in the past, but I can safely say: never again. libtcc has the advantages of a jit (native C speed), but with an elegant API and laudable portability.