WebAssembly plugins system

[CBenoit]

Basically load .wasm files.

Capabilities:

• provide new commands,
• hook on events,
• call helix commands,
• access UI stuff…?

At first we could use a basic toml config file or CLI to feed .wasm files to the editor.

A way to configure permissions on a plugin basis could be investigated to use the sandboxing capabilities coming with WASM.
Example with wasmtime:

$ wasmtime --dir=. --dir=/tmp demo.wasm [args…]

(reference)

I think the biggest challenge is to get well-defined interfaces down but let's not fear to break it during early stages.

Later we could investigate embedding a wasm-based scripting language such as Grain or AssemblyScript.

Here are some references:

• [2020/04 (as of writting)] ActuallyUsingWasm, a good introduction to wasm and WASI + comparison between wasmtime and wasmer
• [2020/12 (as of writting)] WASI tutorial: WASI tutorial for wasmtime
• [2019/03] Standardizing WASI: A system interface to run WebAssembly outside the web: good article explaining WASI purpose.
• [2019/11] Announcing the Bytecode Alliance: Building a secure by default, composable future for WebAssembly: on the isolation system it provides
• [2021/06] How to make plugins system with Rust and WebAssembly
• zellij has a WASI-based plugins system (doc)

I'm willing to experiment soon

[archseer]

I think the most basic demo would be implementing one of the existing commands in such a way, e.g.

helix/helix-term/src/commands.rs

Lines 123 to 137 in 407b37c

	pub fn move_char_left(cx: &mut Context) {
	let count = cx.count;
	let (view, doc) = cx.current();
	let text = doc.text().slice(..);
	let selection = doc.selection(view.id).transform(|range| {
	movement::move_horizontally(
	text,
	range,
	Direction::Backward,
	count,
	false, /* extend */
	)
	});
	doc.set_selection(view.id, selection);
	}

It only depends on the Context, and it only uses functions from core (move_horizontally) without interacting with the UI. I think most of the primitives in core should be exposed (selection/range/transaction/etc) and we can have a subset of view exposed (retrieving a selection from a doc, applying transactions)

[archseer]

Mentioned on Matrix:

Re: wasm plugins, rich clipboard support would be a great demo and to that end, neovim/neovim#14706 "[RFC] Neoclip: multi-platform clipboard provider w/o extra dependencies" may be worth watching.

[buster-blue]

What benefit does this provide over binary plugins? Will plugins be able to access eachother's state (functions, variables etc.) in the same way that plugins programmed in a single language (e.g. emacs) are able to, or something else?

My bad if the answer is obvious btw. I'm not very familiar with WebAssembly or plugin architectures.

[kirawi]

What benefit does this provide over binary plugins? Will plugins be able to access eachother's state (functions, variables etc.) in the same way that plugins programmed in a single language (e.g. emacs) are able to, or something else?

My bad if the answer is obvious btw. I'm not very familiar with WebAssembly or plugin architectures.

I think this post explains it well. There's a lot of uncharted ground in regards to plugin systems, especially with sharing state, but you can see past discussion on this here.

[CBenoit]

@kirawi
Thank you for the link to Valoren, I missed that one

[matu3ba]

If you want to embed the wasm compiler with the binary or as library etc, I would advise against wasm due to slower speed and missing performance optimisations on many targets.

"Of course, wasm3 runs fine on aarch64, but at about 3% of native speed."

This benchmark shows very astonishingly the missing optimisations that luajit can do here using this lua libary.

Also it would be advisable to have execution time benchmarks of webassembly against all usable alternatives before making a decision (ie by listing some speed and platform compatibility requirements). Would be not very useful to end up with something significantly slower than neovim.

[kirawi]

If you want to embed the wasm compiler with the binary or as library etc, I would advise against wasm due to slower speed and missing performance optimisations on many targets.

"Of course, wasm3 runs fine on aarch64, but at about 3% of native speed."

This benchmark shows very astonishingly the missing optimisations that luajit can do here using this lua libary.

Also it would be advisable to have execution time benchmarks of webassembly against all usable alternatives before making a decision (ie by listing some speed and platform compatibility requirements).

The intention is to use wasmer or wasmtime which are both written in Rust, and are quite fast in the benchmarks. However, real-world use is not going to be accurately represented by benchmarks. If it wasn't fast, it wouldn't be used by Google or Figma to power some of their most resource-intensive client-side services, nor would it be able to power game engines on the web. (Here is a more complete list.)

Lua lacks multithreading, SIMD, and has a smaller ecosystem. It's a lot more convenient to enable users to opt for their favourite language rather than have them learn a separate language and its ecosystem. I can't speak on behalf of everyone, but I believe that most Rustaceans firmly agree with me, as many libraries have wasm as a compile target. I would say we collectively have a lot more experience with wasm as a whole.

[CBenoit]

We'll probably go with wasmtime and I can see in one of the benchmark you linked that performances are far from bad. By the way wasmtime has been supporting WASI for a while prior to the article publication date, but they don't mention it, so I assume they used old data from a previous benchmark,

Older versions of the following runtimes had been tested in the previous rounds: […]

Given that Cranelift code generator is still very young and already that good, I'm not too afraid. Furthermore performance tracking is a thing at the bytecodealliance.

Besides all the other good points made by @kirawi on performance, I really like the ecosystem argument which is the reason why we want to use WASM in the first place. Given that performance is probably good enough (or more than enough), the main focus should be on whether user/developer experience is good.

[syrusakbary]

Thanks for considering Wasmer! We are working on a set of benchmarks at the moment, we had two bugs that prevented Wasmer to shine in the one you showcased @CBenoit, but those are already solved in master.

Right now Wasmer is about 20~30% faster than the other runtimes when using the LLVM compiler!

In general, we recommend Cranelift if the compilation times need to be fast (that is mainly for development), and LLVM for production (similar to how Rust uses LLVM always to compile in release mode, and Cranelift as an experimental compiler for faster compilation times in debug mode) :)

[kirawi]

Thanks for considering Wasmer! We are working on a set of benchmarks at the moment, we had two bugs that prevented Wasmer to shine in the one you showcased @CBenoit, but those are already solved in master.

Right now Wasmer is about 20~30% faster than the other runtimes when using the LLVM compiler!

In general, we recommend Cranelift if the compilation times need to be fast (that is mainly for development), and LLVM for production (similar to how Rust uses LLVM always to compile in release mode, and Cranelift as an experimental compiler for faster compilation times in debug mode) :)

This is a question I've had for a while, but what is the main difference between wasmtime and wasmer? I can't recall exactly, but I believe they're targeting different use cases, correct?

[CBenoit]

Thank you @syrusakbary for your input!

This is a question I've had for a while, but what is the main difference between wasmtime and wasmer? I can't recall exactly, but I believe they're targeting different use cases, correct?

I'm interested in hearing more as well!

I was more in favor of wasmtime for the following reasons:

• backed by the @bytecodealliance
• @alexcrichton and other notable names from the Rust compiler and std lib team are working on it
• a single back-end is supported (Cranelift) so we can expect it to be well supported and maintained while supporting three back-ends (Singlepass, Cranelift and LLVM) sounds like a heavy task

On the other hand, wasmer:

• including dependencies, is less lines of code (on lib.rs: ~5.5–8.5MB for ~177K SLoC vs wasmtime with ~18MB for 417K SLoC), meaning we probably get faster compile time and a smaller hx binary without even using lto (we would need to actually see what we get in practice though),
• is used by Veloren
• is used by zellij
• (has Japanese documentation 😛 )

I'll also ask on Veloren's Discord why they decided to use wasmer to form a better opinion.

I also found this article published a few months ago:

• Wasmer has the best overall support compatibility with every programming language at super-speed
• Wasmtime is lightning-fast and compact, with good configurability but fewer languages supported
• Lucet is a specialized solution for running untrusted WebAssembly programs inside a larger application
• WAMR runs with a small footprint

[matu3ba]

@CBenoit @kirawi There are 2 mutual exclusive possible use cases for WASM for plugins, where one really wants to have a plugin manager: 1. shipped compiler or 2. hook into the repo build system and the used compiler to build the WASM libraries/binaries.

1. interpreted which one usually wants to ship a dedicated compiler (which is language-specific for performance => This is effectively a soft language-lockin as one wants to ship it with the editor and not bundle all compilers/programs that can emit WASM.

2. compiled (fastest) which can be completely independent, but requires support of 1. the build system and 2. distribution package managers etc to have the compilers installed. If the language does not support easy build system integration and there is no convention where to put stuff upstream, it does scale poorly (because the package manager of helix can not build stuff).

Solution 1. gives more of a "it always works" experience with the language that the compiler supports

Solution 2. gives more of a "its super fast", but needs some setup and might break. Unless you can use nix for 2. ie with flakes 2 is just painful due to 2.1 many distros not shipping all compilers or only specific versions and then you are stuck on one (ie not yet stable languages) and 2.2 you want to simplify build system stuff for plugin developers.

nix with flakes is the de-facto best solution for 2.1 (shipping compilers+libc(s)? and make sure they exist, are configured/build identically and up-to date enough for the plugin ecosystem).
For 2.2 nix flakes should work, but a convention how build commands/shell scripts are supposed to be called could also work (I am not sure how stable flakes are for that use case for all the build systems that exist).

Ask yourself which solution is better for the goals of the project helix or how you want to deal with the mess of 1. shipping compilers and 2. supporting the build systems of plugins.