Wasmer – Universal WebAssembly Runtime
wasmer.io
wasmer.io
Software is a hard and complex thing to build, people don't tend to work full-time on projects which they can't earn a living from.
> Software is a hard and complex thing to build, people don't tend to work full-time on projects which they can't earn a living from.
Wouldn't these be positive points towards how Wasmer is running the company? They are trying to keep their open source product alive by marketing and finding a way to build revenue, to continue to fund development.
In the end, if they fail, it's all open source, someone can fork and continue it if the demand is there. Until then, they are the ones doing it, and doing it well imo.
It seems like people are specifically interested in spreading FUD about Wasmer and I can't see the justification for it.
It is as if Nodejs tried to trademark V8
Sure it's open source, but unless you're at a scale where you actually can take it over and maintain it, that's not some magical escape hatch.
This isn't a theoretical thing for me. I've got a project in mind that wasmer would be a candidate for, and I ruled it out for this reason.
I'd wish folks focused on the incredible amount of engineering that has gone into wasmer. The breadth of its offering is astonishing for a team of its size. Sad that the engineering team couldn't be together for longer, but the runtime is impressive nevertheless.
I look at wasmer's various OSS repos from time to time to understand how it was put together. It has been very rewarding to say the least.
(yes, I am also aware of the fallout between Syrus, the founder, and a few ex wasmer engs, but let's also focus on the good parts too, folks!)
That said, trademarking WebAssembly seems to spit in the face of the engineering and technical design work that went into WebAssembly before even Wasmer arrived. Perhaps not as sleek and polished as a VC-backed startup, but we can praise Wasmer for what it has accomplished while also expressing reservations regarding the people who stand to profit from its success.
No, as many readers possible should be informed. This no name startup attempted to steal what was supposed to be a standard runtime format. Imagine what they’d do on a larger scale with that sort of behavior. That’s not a company that deserves to grow, we have enough Google’s and Apple’s.
A lot of these companies play good guy by open sourcing their products. Given this one’s commercial struggle, who says they genuinely want the world to see their code, Is it not possible they have no other choice?
An open source, closed spec product doesn’t really add up, it’s ingenuine, greedy, and downright stagnant.
In which case violates the site's guidelines:
> Eschew flamebait. Avoid unrelated controversies and generic tangents.
Seems like unethical behaviour on their part is related to their product offering.
And it is pertinent that there are alternatives like wasmtime that don’t have such issues.
I'm glad for the sliver of technical discussion that did occur in this thread, but most of it was "controversy" that has been discussed over and over before and is pointless.
Personally I think this forum is best when the discussion steers more technical, especially in a tech related thread.
The constant scarlet lettering is tiring.
HN is an advertising medium for tech companies. That’s why it exists. When I and others in this thread see an unethical company benefiting from that exposure, we feel compelled to point out that the company is unethical. That way the target audience for the tech product can make an informed choice about whether they want to do business with unethical folks.
If you feel our comments are off topic, go ahead and flag/downvote.
But I’m guessing it’ll be like tilting at windmills.
> Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity.
What you're doing is violating the guideline:
> Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
I did flag your comments as I feel it violates that guideline at least, and I feel your tone violates others.
On a personal note you at least motivated me to use Wasmer in the future, though I may have chosen them anyway for the performance.
Your crusade may not be having the effect that you think it is.
And my crusade? Look at my comments on this thread, I’ve only replied to you. (And I’ve never commented on wasmer before, to my knowledge). I’ve tried to explain to you why everyone else talks about the shady things this company does. And for explaining that to you, I get condescended to.
The guidelines are what HN aspires to be. It’s a good goal. What I told you was what HN actually is. It’s why Ycombinator funds this website. It’s why tech companies strategise on how best to get attention from HN. How to write blog posts that HN will like. When to post to get the most upvotes and views.
You can blind yourself to that reality if you want. You can go ahead and use whatever tech you want. It’s really no skin off my back. Have a nice day :)
* Intel (WAMR) - Market cap: $105B
* Fastly (Wasmtime) - Market cap: $1.2B
* Google (V8) - Market cap: $1.5T
* Tetrate Labs (Wazero) - Market cap: ~$200M (guesstimate)[1] -https://en.wikipedia.org/wiki/List_of_trademarked_open-sourc...
Web assembly isn't just Wasmer. This move is like trying to trademark "internet" or "hyperlink" or "metaverse".
It seems part of the motivation for Wasmer to apply for the trademark was because they felt snubbed by the Bytecode alliance [^2] and wanted to start their own foundation (with blackjack and hookers, presumably). The Bytecode alliance doesn't own any of the trademarks either, and seems to be more of a collaborative effort, but is worth mentioning as part of the overall story.
[^1]: Groups listed here: https://webassembly.org/. and members here: https://www.w3.org/Consortium/Member/List and https://www.w3.org/community/webassembly/participants. Note that a few Wasmer employees (the CEO, for one) belong to the community group, but don't chair it.
[^2]: https://bytecodealliance.org/ and https://wasmer.io/posts/wasmer-and-trademarks
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. 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)
You say you do, but then you had to disable it, and it will hopefully be in a future release.
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.
The product may be good, but the company stinks.
You don't trust them with what? Their core products are open source.
Previous threads for those who don't know their history:
Co-founder talks about toxicity and the overbearing CEO Syrus Akbary: https://news.ycombinator.com/item?id=28772863
Trademark drama: https://news.ycombinator.com/item?id=30758651
Stay far, far away.
There's a lot more information on their github page here: https://github.com/wasmerio/wasmer
Has support been added for:
1) types other than int, for example strings and what not without the hacks of passing string lengths and addresses?
2) sharing of data. That is can I declare a struct of some sort in the main program, pass that to the webassembly script, operate on it, and return it? Last I looked at that the only thing I could come up with was passing it back and forth as a (pick your format here) json string.Floating point values are also supported.
> for example strings and what not without the hacks of passing string lengths and addresses?
That's not so much a "hack" per se, so much as it is fundamentally how string types are represented when broken down into their basic components. ARM, x64, etc. interact with strings in similar ways. Tools like wasm-bindgen[1] generate JS wrappers around the raw WASM calls, which wrap the address+length APIs in string accepting ones. For non-JS hosts, you might have to roll your own boilerplate or boilerplate generators, but that's straightforward.
> sharing of data. That is can I declare a struct of some sort in the main program, pass that to the webassembly script, operate on it, and return it? Last I looked at that the only thing I could come up with was passing it back and forth as a (pick your format here) json string.
Multiple WASM instances can share a single memory instance without copying data. A non-wasm host will typically copy/serialize data into/out-of WASM memory for simplicitly/convenience/durability, but there are APIs[2][3] that let you directly manipulate WASM memory - and there's nothing stopping you from generating identical structures on both ends and directly using them without copying.
[1]: https://github.com/rustwasm/wasm-bindgen
[2]: https://docs.rs/wasmer/latest/wasmer/struct.Memory.html#meth...
[3]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
for 2) there are reference types, which allow wasm to receive opaque objects similarly to how userland processes receive handles from the kernel. In this way you could pass an object to wasm and let it call host functions to modify it.
If you want to have the same datatype both in wasm and in the host you simply a compiler that supports it.
[0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas... [1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
What exactly do these wasm startups intend to capitalize on, niche markets like IoT devices?
I’m sure they’re all seriously developed, complicated projects. I just don’t see what they have that any much larger company already does.
quite a list, it is becoming a new JVM that runs all different languages.
https://github.com/wasm3/wasm3
Out of curiosity, what kind of use cases would you want to target with microcontrollers running wasm binaries?
Is there anyone in this thread that would be interested in doing sponsored open-source work (we pay you for contributing code to an OS project), with the aim of making Wasmtime [not Wasmer] work better with Ruby?
Basically, to make it easier to call the Wasmtime runtime from within Ruby? (passing of args etc)
https://www.graalvm.org/22.1/reference-manual/native-image/L...
Then use the WASM back-end for LLVM.
Probably won't work though.