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.

[kirawi]

We won't be shipping a compiler, though? WASM is a compile target for Rust itself as wasm32-unknown-unknown, and other compilation methods use their own external tool (Wasmer and Wasmtime also provide their own) to compile it down to .wasm, which would be run by the WASM runtime. Languages like Python or Lua currently work by compiling their interpreters down to .wasm, but in the future they could be directly compiled down to .wasm once the WASM GC is standardized and implemented.

Did I understand you correctly?

[matu3ba]

@kirawi How does this change the problem, when the plugin is written in a language that the distribution doesnt ship a compiler (or super old/incompatible or slow libc etc) ?
The plugin then just doesnt work? Or works differently and the plugin author should deal with the mess of different compiler versions?

[kirawi]

No, it's just .wasm. The user doesn't need to download anything else other than that standalone .wasm output which is what the plugin actually is. Think of it as creating an executable, you don't need all the code and compiler stack to run the executable as an end-user, because the OS already has everything it needs to run the executable inside the executable itself. The executable in this case is .wasm, and the OS is the Wasm runtime. Wasm is completely language agnostic and is just bytecode.

[matu3ba]

@kirawi Thanks alot for the clarification.

How is 1.integrity (nobody tampered with the build process/environment), 2. debuggability/tracebility (what stuff got wrong) and related 3. uniformity (potential contributors can reproduce the .wasm to manually reproduce/fix stuff)?

Point 1. is a stopper for usage in any more security-critical developer environments, point 2. is okayish not to have (debugging luajit also doesnt work very good), point 3. can be super annoying to find contributors.

[kirawi]

1. Couldn't you argue that for any software? If you're worried about it, you can compile the plugin yourself.
2. Wasmtime and Wasmer.
3. The potential contributors would need to know the code, but that's the same for any language.

The same challenges exist for any language, but Wasm is a compile target, not a language, allowing for anyone to write any plugin in any language they want, instead of restricting them to one.

[matu3ba]

1. I strongly disagree on 1 reproducable builds, since this gives to much trust to single developers to do potential harm while making it hard to detect it. You can not reproduce a binary/wasm file without an exact identical build environment. Also you may have to deal with third parties shipping binaries etc.
2. thanks alot.
3. Conventions and build systems influence how code is structured, but that is overall correct.

[kirawi]

Indeed, but that is something that is just going to happen no matter what. Every program that people use is going to be written in separate languages, and if you want to do that of risk analysis, you would want to compile it yourself. But the other benefit is that since you can write a plugin in your preferred language, you can for the most part write all your plugins in-house. Lua is arguably worse because it lacks sandboxing, while with Helix and Wasm we would have full control over what a plugin can or cannot do.

It's a tradeoff for sure, but I think Wasm opens up a lot of possibilities to circumvent the cons of using Wasm.

[matu3ba]

@kirawi How much performance loss does sandboxing mean?

L3 cache can likely never fully be mitigated without notable performance loss, since it is shared between cores (and mitigation would require accurate time synchronisation between memory controllers of cores).

Here is the list of possible cache attacks which looks scary to me.
And on top of that: "most existing hardware is broken in terms of security! And the underlying cause is the ISA, which is our hardware-software contract." risc5 timing channel analysis paper should be linked in the article => flushing might not flush cache immediately.

[kirawi]

Wasmer and Wasmtime are both sandboxed, so you can reference the earlier benchmarks for them. Admittedly I'm not sure on the cache aspect, and I'm aware that Wasm sandboxing is far from perfect, but I think that leads back to the point that you would need to evaluate the plugin if you're untrusting of the plugin. I also found this article, maybe it'll shed some light.

Just being on the browser right now, you're probably running quite a lot of JavaScript and Wasm already. I think this discussion, though important in general, is bike shedding in this context. There isn't a perfect solution here, and there probably never will be, but Wasm seems like the best option for Helix.

[pickfire]

Can we have two in one option? On one hand we let developers have it compiled so it could be faster. On the other hand we can have it interpreted to allow testing stuff faster. We could use the interpreted version as one of the compiled plugin. Not sure how feasible is this.

[CBenoit]

That's definitely some workflow we could think of at some point. Makes me think of the gcc-emacs that is compiling elisp instead of interpreting it IIRC.

I prefer investigating the embedded runtime approach fully before we consider that though.

[vshymanskyy]

Just for clarification. Wasm3 is 4-5 times faster than, say, Python 3.9, yet weights only ~150KB.
It doesn't require any JITting, etc. so runs exactly the same on iOS, Android, Windows and other platforms.

On Apple M1 for instance, it showed ~5-7% of native speed, which is somewhat better than 3% that was claimed here.
But this wasn't heavily tested/optimized anyway.

[archseer]

Today in the news: https://wasmer.io/posts/wasmer-2.0

Seems to have some support for reference types. I'd still like to see a comparison with wasmtime beyond just performance.

(Edit: Nice, I see the announcement is written by @syrusakbary himself)

[nrabulinski]

Personally VSCode is far from what I'd describe as an editor that I need no plugins for at all. The only thing it has going for it is built-in JS support which I'd expect given it's literally running in a browser...
Everything else either needs a plugin downloaded or downloads a plugin automatically when you open some file.

And I'm not saying that it's a bad thing. Off the top of my head - I use the pijul VCS, I think it's great and I'd love to have at least some basic integration in helix but I know that I'm in the minority and the vast majority of users don't. Same with more niche languages which rely heavily on custom LSP extensions. Sure, I can add a custom language definition in helix but it won't support all the features I could expect out of other editors and it's not something I think should be welcome in the main codebase.

That's why I'm also in favor of at least "recommended" plugin repositories or having the "official" plugin repo but for the tinkerers or people wanting to live on the edge have the option to extend helix themselves or with not-officially-supported plugins without having to maintain a personal fork.

[notramo]

@nrabulinski Yeah, +1 for Pijul version control. Finally I see somebody mentioning tooling support somewhere.

Also, the support for less popular languages is important. There are some amazing languages out there (e.g. Zig, or Crystal, and not having support for these would

@eulerdisk, including Lua is the worst idea ever.
Please don't include Lua. It sucks.
I don't hate this language. I don't even know it (I started learning it, but it don't worth the effort). But being limited to one language repeats the mistake of the web.

I think we need a plugin system which supports plugins in any language. This opens up the opportunity for everyone to write plugin in their favourite language, and also other new approaches, like languages specifically designed for text editing.

There are two approaches that can fulfill these requirements: WebAssembly, and native binary plugins.

(Sorry if I repeated points that were mentioned before, I just found this software, and haven't followed the discussion before.)

[glyh]

@eulerdisk Then you should probably go with IDEs.

[Jedsek]

Implementing everything in core is a mistake!
Plugin sysytem is very important

[theherk]

Maybe a good topic in lieu of or in supplement to this conversation would be a list of features the community wants, and a discussion on whether each is best suited to a plugin or core implementation, because I feel like each opinion that a plugin system is required is not really that interesting without saying, "Here is a feature I want, that I will make a plugin for, that definitely shouldn't be included in the core distribution." Failing that, I'm not sure what we're talking about.

For me, I think very tight git integration akin to magit... but I think if something like this were planned as a core feature it wouldn't require a plugin.

[emummel20]

@theherk Counterpoint, while I think your question is interesting, ultimately I think it's irrelevant because the whole point of a plugin system is so that anyone can decide for themselves what they need. Maybe someone has some niche use-case that they need a personalized tool for; they can script it themselves. And if it so happens that multiple people agree that a particular tool is important then maybe they can collaborate on one. Yours is a good question for maybe brainstorming but ultimately I don't think it's as crucial as establishing that a plugin system is warranted.

For me, the specifics would be magit, org-mode, and all the other plugins that make the likes of neovim and emacs useful. There are already plenty of great ideas out there. Whether or not I'm actually going to be using all of those is an open question but I would like the flexibility to decide that for myself.

[pianocomposer321]

@emummel20 I see what you're saying, but I think the main thing that @theherk's suggestion would accomplish is to demonstrate what and how many features there is demand for...I think one of the main reasons (if not the reason) that there are still people who don't think helix should have a plugin system is because they don't realize (or haven't completely thought through) the vast number of features that would have to be in core for a plugin system to be unnecessary. A list of those features might be a wake up call.

[theherk]

I don't understand why, @emummel20, you think those can only be implemented as plugins. I'm suggesting the can be or they can be implemented as compiled source. If you don't want to use them, there is no reason configuration can't enable or disable features. To suggest that consideration for specific plugins has no bearing on the creation of a plugin system doesn't make sense to me.

What I mean is, if for example the community agreed that something closely matching the functionality of magit were needed, implementing it a a plugin would make less sense then building it into the core. Same for org-mode, etc.

However, if on this list there were things that only a subset of the community wanted, it would make it clear that such a system is warranted, and further it might help inform how that system should be implemented. I am pretty pro-plugin, but I think a data based approach is the next logical step, and blindly saying "there already exists a binary answer, no further consideration necessary," doesn't really move the needle.

---

editing to expand: As an idea, the author or collaborators could install the github polls app or similar (I guess 👍 / 👎 are also sufficient). Then, we could begin opening issues per requested feature with a poll on if it should be included in the core distribution or not. A page could be added to the Wiki tracking these. It would probably showing quickly that there are many features that many want, but that there isn't necessarily agreement on there inclusion in the core distribution.

[dead10ck]

@theherk the part of this equation you're not considering is the maintainers. The more features are in core, the harder it is to maintain. Every new feature adds to a matrix of support, and thus adds exponentially more work over time. Plug-in systems are just as much for developers as they are for the users. The core maintainers cannot possibly maintain every single feature under the sun.

And furthermore, as much as everyone would love an ideal world where we could base our decisions purely on data, this is simply impossible with the resources this project has at its disposal. Big companies can do this because they do active customer research, meaning they find and actively solicit feedback from users; they do not wait for customers to come to them.

Those who notice and participate in a poll on GitHub is not going to be nearly representative of the entire user base. The vast majority of users are not aware of any part of the development process, nor should they be. And user polls do not represent the other half of the equation (maintainers). You could not possibly hope to gain any statistics meaningful enough to drive roadmaps or design through a Github poll.

[emummel20]

@theherk I didn't say they can only be implemented as plugins. I'm saying that a plugin system is likely the only scalable solution because there are a million plugins that one could want and the dev team for helix is probably going to be too small to either implement everything we might want themselves or review every single pr to merge into the core. Obviously the ideal scenario is that we get everything we want implemented in core but that's a fantasy, and even if we could get a particular plugin in core it still wouldn't be ideal because there are different ways of implementing different features with different tradeoffs and if it's all in core then you're stuck using whatever was implemented with no hope of something else.

Consider neovim's major implementations of org-mode: There's this one and this one. Now I haven't used them, I don't know what the differences are between these but presumably there are some and the point is, as a neovim user you have a choice which one you want to use and which one is better for you -- and the only reason this is possible is because two different teams created two different plugins as opposed to one team implementing one core feature set.

Do you not think it makes more sense to let the dev team work on making the core editor better by fixing bugs and improving architecture rather than worry about implementing magit? I think there's enough to work to be done in the core platform and if the dev team spread themselves thin working on everything under the sun if would be counterproductive.

[dead10ck]

Honestly this issue has so much difference of opinion, no matter what ends up happening, there will probably be a lot of unhappy people. In my opinion, this issue doesn't need more user feedback, it just needs a decision and an implementation.

[glyh]

@dead10ck Isn't it already happening? @archseer is implementing a scheme on rust.

[noor-tg]

@dead10ck Isn't it already happening? @archseer is implementing a scheme on rust.

is there any repository or pull request to track what is done and what is not ?

[noor-tg]

did any one check nushell plugins ?
they use simple file conventions . with JSON-RPC protocol.

[devanlooches]

Just putting lapce out there.
Its an editor in rust and uses WASI plugins already.

[stappersg]

Just putting lapce out there. Its an editor in rust and uses WASI plugins already.

From that webpage: "Vim users, we've got you covered! Built-in support for a Vim like editing experience, without a plugin."

[devanlooches]

Correct, it supports Vim keybindings without a plugin, but it also supports WASI plugins

[devanlooches]

Also from that webpage: "WASI plugin system
You can write a plugin for Lapce with any programing language that compiles to WASI. Choose a familiar language for writing a plugin without learning a new language.

[theherk]

@devanlooches: Maybe you have some insider information, but I was under the impression they were only slightly further along by having decided on the definite inclusion of a WASI plugin system. But the API and implementation are very not done. lapce/lapce#558

[devanlooches]

Ah I see. I only took a quick glance and saw it on the website. I was under the impression it was more completely since there was already a crate on crates.io. lapce-plugin

[kirawi]

I believe that this issue would be better served by a proper discussion. I would urge anyone with comments not pertaining to the implementation to use #3806 instead. Additionally, it might be wise to create a new issue altogether for the plugin system. There's a lot of noise here, and focus has shifted from WebAssembly to other alternatives.

[archseer]

@kirawi Discussion is now fragmented between #122, #3806 and #2949 :/

I also agree with #122 (comment), at this point opinions are being repeated and we don't really need more input, rather development time has to be spent on an implementation.

[bemyak]

I stumbled upon zellij, which has a WebAssembly plugin system implemented, maybe it can be used as a reference.

[CBenoit]

I stumbled upon zellij, which has a WebAssembly plugin system implemented, maybe it can be used as a reference.

It’s mentioned in the very first post.

It’s not against anyone, but for now I think it’s best to lock this issue until further concrete progress is made (see #122 (comment) and #122 (comment) for why). Of course, feel free to comment in the discussion #3806 or to join the Matrix Space, just try to not forget using Ctrl-f in this issue beforehand. I’m not locking to prevent any further discussion from users, but rather to make it obvious to everyone that we already collected most of the opinions and suggestions and that what we really need now is development time.