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)
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.
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.
> 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