[Conlectus]

Given my experience, I would not recommend using Wasmer over an alternative like Wasmtime for several reasons.

1. Lack of support for `externref`, AKA opaque references to host data. Sure, the Wasmer 2.0 blog post _claims_ they added support for it, but that amounts to allowing you to read the type signature in an existing module, but not actually use the feature yourself. With some digging, my educated guess is they wanted this to be their headlining 2.0 feature but weren't able to get it working, so they just pretended in their blog post and left the incomplete version behind a development flag.

2. An awkward context API for host calls. All host data associated with an instance must be `Send` + `Sync`. In practice I've found this leads to wrapping your entire context object in a `Arc<RefCell<T>>`, even if your data could otherwise live on the stack. Wasmtime does not have this limitation, so it's not a hard technical requirement.

3. It took me about 2 weeks of development to run into a use-after-free bug bubbling up into Rust.

4. The performance, at least for my use case, was not meaningfully better than Wasmtime. This may not be true if you're doing a lot of intense number crunching.

5. Lack of support for instance resource allocation pools. Wasmtime allows you to pre-allocate / reuse the resources associated with an instance, whereas you would have to roll this on your own with Wasmer.

6. Lack of support for the module linking proposal. This proposal may be incomplete, but it is still helpful ahead of its replacement.

This is on top of, as others have mentioned, their questionable business practices[1][2].

All of this may improve, but as things currently exist, Wasmtime should give you everything you would want from Wasmer in a more stable, more complete and more ergonomic package.

[1]: https://mnt.io/2021/10/04/i-leave-wasmer/

[2]: https://wasmer.io/posts/wasmer-and-trademarks

[the_duke]

No comment on the other points (I also prefer Wasmtime), but:

I believe the linking proposal is dead for now and replaced by the component model: https://github.com/WebAssembly/component-model

The wasmtime implementation is in progress.

[Conlectus]

Yep, I'm aware ("ahead of its replacement"), but in the mean time it really helps to have something that just solves the "take these two modules and merge their functions" problem.

[syrusakbary]

Hey Conlectus, let me address your technical comments (note: I work at Wasmer)

> 1. Lack of support for `externref`, AKA opaque references to host data.

We do support `externrefs`, but had to partially disable it due to big impacts on performance due to how we did the initial implementation. We are refactoring this in Wasmer 3.0 and this shall be completely addressed in the Wasmer 3.0 release.

> 2. An awkward context API for host calls.

This is probably the point I agree most with. This is already being worked on. Please take a look on this PR if you are interested on knowing how things will look like for Wasmer 3.0 [1]

> 3. It took me about 2 weeks of development to run into a use-after-free bug bubbling up into Rust.

Sorry to hear that! We are working hard make sure there are no such leaks/bugs in Wasmer

> 4. The performance, at least for my use case, was not meaningfully better than Wasmtime

In general, being able to have to have a pluggable compiler infrastructure I think makes the runtime infrastructure way more resilient and with almost zero effort we should be able to support more chipsets (such as RISC-V). In the case of Wasmtime they are using the partially-optimized compiler Cranelift, but they only support for x86_64 and aarch64. They are doing super interesting things such as the ISLE initiative but IMHO they are far from having the robustness that projects like LLVM already have. Which is why Wasmer chose a pluggable compiler infrastructure rather than tying itself to only one.

> 5. Lack of support for instance resource allocation pools.

Yup, this is on our plans!

> 6. Lack of support for the module linking proposal

This have been very intentional. IMHO module linking is an over-engineered solution that can be solved more easily with a static spec definition outside of Wasm. I personally think it's unlikely that it will reach broad adoption. But I can assure you that Wasmer will implement this once browsers do (if they ever do, of course)

[1]: https://github.com/wasmerio/wasmer/pull/2892

[mkesper]

"I work at wasmer" is really weak wording when you're founder and CEO.

[lenovouser]

Why does it matter who he is at the company? I actually like the touch of not making a difference between "regular" employees and being Founder or CEO. On me this made a positive impression. In my opinion what matters is what is being said, not who is saying it.

[zcw100]

It’s a lack of transparency. A CEO has a very different set of motivations than an employee. Just like saying they are telling you they are an employee chances you perspective on what that have to say so would telling you they’re the CEO.

[CJefferson]

With regards (1), do you support externrefs at the moment, or not?

You say you do, but then you had to disable it, and it will hopefully be in a future release.

[syrusakbary]

We support them fully in the `context_api` branch, which is not yet merged into master but will be very soon as part of the Wasmer 3.0 release