wasm_plugin icon indicating copy to clipboard operation
wasm_plugin copied to clipboard

Wasmtime Support

Open XAMPPRocky opened this issue 3 years ago • 5 comments

Hello, I came across this project, and I was interested in using it for prototyping my own, however I was planning on using wasmtime as my engine and see that this project only supports wasmer. Would you be up for changing, or accepting a change that adds wasmtime support?

XAMPPRocky avatar Jul 04 '21 06:07 XAMPPRocky

Absolutely a thing I'd consider. Exploring wasmtime has been on my list for a while but haven't had a strong reason to. Out of curiosity, why are you choosing wasmtime over wasmer?

alec-deason avatar Jul 04 '21 06:07 alec-deason

Multiple reasons:

  • Wasmtime is an open collaboration between the members of the bytecodealliance, which includes a number of large companies. https://bytecodealliance.org Where as wasmer is mostly maintained by a single entity.
  • Relatedly there are reasons wasmer is not part of that group, I'm not going to link anything, but you can search for the specifics, the head of that project has shown some pretty gross behaviour in the past, so I'd rather not use it.

XAMPPRocky avatar Jul 04 '21 07:07 XAMPPRocky

Ok, those are pretty compelling reasons.

There are two technical problems I've had so far with wasmer, one wasmtime likely fixes and the other I don't think it helps with.

The first is an awkwardness in exporting closures from the host and very aggressive Send/Sync bounds even in places where they are (I think) not necessary when host and guest share a thread. Together those make exporting APIs from the host to the guest an uncomfortable dance with context objects. I assume that's all a detail of wasmer's internal design and wasmtime wouldn't have those issues.

The second is support for the case when the host is itself a WASM program. One of the reasons I initially chose wasmer is that I misunderstood how their js integration worked. I thought it was their rust as WASM running in the browser, but it's a completely separate codebase. It would be nice to have in-browser support without having to write a separate backend for it. I don't believe wasmtime helps with that either. When I looked around a couple of months back it seemed the only way to do it with a single implementation was to go to one of the pure rust WASM VMs which is too much of a performance cost to pay for slightly simpler internals. So any move to wasmtime would need to be done with the idea of eventually supporting a second backend for running in browser.

alec-deason avatar Jul 04 '21 17:07 alec-deason

So any move to wasmtime would need to be done with the idea of eventually supporting a second backend for running in browser.

You could add a trait to abstract over the runtime API. I don't think there's any WASM VM inside WASM atm, I believe supporting that would be blocked on WASI and the Browser APIs being available to WASM, so if you wanted to support that today, you'd need to write a JS polypill that actually instantiates the module. I don't think this would require a separate backend from wasmtime (though I don't actually know they have any plans in this area), just needs the underlying tech to catch up.

Relatedly this is why I'm interested in this crate, it would let me ignore writing a well formed ABI and just pass everything as an object until I finish the prototype and hopefully it's easier to create environments in wasm.

XAMPPRocky avatar Jul 05 '21 05:07 XAMPPRocky

I'm not going to comment any of the non-code related issues laid out by @XAMPPRocky, specially because I identify them as political and highly biased (since she seems to be related to the BytecodeAlliance and I work for Wasmer).

On the code side, Wasmer will add support for targeting JS environments very, very soon. So you should be able to target wasm_plugin to the browser with the same syntax :) https://github.com/wasmerio/wasmer/pull/2460

The first is an awkwardness in exporting closures from the host and very aggressive Send/Sync bounds even in places where they are (I think) not necessary when host and guest share a thread. Together those make exporting APIs from the host to the guest an uncomfortable dance with context objects. I assume that's all a detail of wasmer's internal design and wasmtime wouldn't have those issues.

I'm curious about this one, specially if we improve and can make our API better based on the feedback! Could be possible to have a few examples of what are you referring to? Thanks!

syrusakbary avatar Jul 22 '21 23:07 syrusakbary