wasmi VS extism

There was also an option to use Rust and wasmi for the runtime, but although it worked on emulators like PPSSPP, errors occurred on the actual hardware (as shown in the screenshot below).

I'll need to dig a bit deeper in your implementation!

[1] https://github.com/wasmi-labs/wasmi/blob/master/crates/wasmi...

There are lots of solutions to this, I was randomly looking into this yesterday purely out of curiosity and it looks to me like wasmi is the current go-to option.

Hello guys, i was looking for a no std wasm interpreter and i found out about wasmi: https://github.com/paritytech/wasmi/, but when i tried it i get an error module env not found. I suspect that in my program i call an extern function putchar() to be able to print and wasmi doesnt support that, but other interpreters i tried support it, for example wain. Are there any alrernatives, or am i doing sth wrong here. I dont have a deep wasm knowledge, i was just wanted to experiment with wasm in a no std enviroment. Heres my code:

Application plugins could also be wasm. That lets plugin authors write in any language they want and have their plugin work. That's the idea behind the Extism framework:

https://extism.org/

The WebAssembly component model is aimed at having composable components that can call each other. The components can be written in any language, compiled to WebAssembly, and interoperate: https://github.com/WebAssembly/component-model/

Extism is a plugin framework for WebAssembly:

https://extism.org/

https://github.com/extism/extism

Visual Studio Code can run WebAssembly extensions: https://code.visualstudio.com/blogs/2024/05/08/wasm

A project to bring WebAssembly plugins to Godot: https://github.com/ashtonmeuser/godot-wasm

WasmEdge can be embedded in applications: https://wasmedge.org/docs/embed/overview

Wasmer can be embedded in applications: https://blog.wasmer.io/executing-webassembly-in-your-rust-ap...

Wasmtime can be embedded in applications: https://docs.wasmtime.dev/lang.html

Enhance is super cool and the fact that it can be called from basically any server language makes web components really powerful & reusable.

I work on one of the underlying libraries that provide it said portability, Extism, and I love to see how WebAssembly actually bring some of the coolest parts of the web browser into other applications.

https://github.com/extism/extism

this is exactly what we created Extism[0] and XTP[1] for!

[0]: https://extism.org

This is an exciting option as it provides a sandboxed environment to run code. One caveat is that you need an environment with Javascript bindings. However, an interesting project called Extism facilitates that. You might want to follow their tutorial.

Writing code to initiate a WebAssembly runtime, load our module, and call exported functions can be quite a lot of work. Luckily, the team at dylibso has thought about that and built Extism, a framework for building plugins with WebAssembly.

No one is saying anyone should stop exploring new paths. I don't know what you personally are bringing to the table as far as adding to the ambition, so excuse my naivety.

The issue is that there is a misrepresentation by the Bytecode Alliance about WASI, from where it began, to where it is now. And a lot of this has been poorly communicated or not done at all. Which has only left many of us to think that they are trying to pull a fast one over the community to forcefully bring everyone along into Components when that is not desirable.

> Wasm has not allowed actual inter-language operation at any serious scale.

This is untrue, and you may just be unaware of efforts like Extism [0]. While it is intentionally not a binding generator, it does make it very easy to blend languages meaningfully. Disclaimer, I work on Extism and therefore have some bias :) We have different goals than the Component Model, so if you actually want what the component model offers, you should use it!

I believe the easy solution here is to:

1. stop referring to WASI 0.1 as "legacy", implying some obsolete status, or call 0.1 something entirely different. Let it continue to be an easily targetable interface to bridge to the rest of today's software.

2. move WASI and Component Model code repositories out of the WebAssembly github org.

This would clarify the distinction between WebAssembly (the standard) and WASI 0.2 / WIT / CM as a project by Bytecode Alliance. They are not the same, and while the Bytecode Alliance works on making things usable and ready, it doesn't cause harm or confusion for WebAssembly users.

[0]: https://github.com/extism/extism

I'm looking forward to use: https://github.com/extism/extism