I'm probably holding it wrong, but the website has a dropdown for CLI, but CLI is the only option in that dropdown, which is at odds with "Run... anywhere" in the headline.
That widget is wonky for me too, but if you go to the runtime page (https://wasmer.io/products/runtime) you'll see SDKs for Rust, Python, JavaScript, Go, Ruby, and C.
It feels very close to docker equivalent for WASM binaries which is very cool.
I think this might be the breakthrough required to make wasm server-side very mainstream. I think there is still complexity and standardization issues on compilation side. When that is solved then server-side wasm would be ready for democratization I think.
The technology is interesting, but I've never bothered to install it. It seems like this ecosystem is missing compelling reasons to use it, sort of like a device or app store that's missing interesting apps.
The demo they put on the front page doesn't really sell it. I already have Python installed. It's need that they got it running, but how is this better?
What would sell it? Suppose there were a well-regarded hosting site that required uploads to be WebAssembly. Or maybe some popular app that required plugins to be written in WebAssembly.
There is a package that "contains a WordPress website that can be run as a WCGI program by Wasmer"[1]. But there is now WordPress Playground: A WordPress that runs entirely in the browser[2]. I wonder if Wasmer will continue to develop their own WordPress browser implementation?
>I wonder if Wasmer will continue to develop their own WordPress browser implementation?
I think it's probably meant more as a demonstration of "run, publish and deploy any code, anywhere" rather than as a serious use case suggestion. It's taking something people are familiar with, know to be a bit messy and complicated and running it in a browser.
Maybe a good place to ask this question: I recently wanted to share lib code between three separate codebases (JavaScript, Swift and Kotlin). I considered writing it in a wasm-compatible language and sharing it as a wasn module. Curious if wasmer may cover these use-cases, since a) it’s cool to share code, but b) building high-quality native wrappers is hard (e.g. to wrap complex data types when different languages may have preferred styles).
Your best bet for this right now would be kotlin multiplatform, which can target IOS native, browsers, and of course android. It also has an experimental wasm compiler but it's not ready for production usage. But you could actually target wasm with it.
Embedding WASM on IOS might be problematic because of Apple's rules regarding what is and isn't acceptable there. They've never liked people embedding interpreters in their apps. That's how they blocked flash as well. And that's how they continue to block the firefox and chrome browser engines.
Rust and UniFFI would cover the native side, although async/futures support is immature currently. You could then also potentially compile to wasm but I haven’t tried that.
> By extension, a headless engine can only execute a WebAssembly module, i.e. a module that has previously been compiled, or compiled, serialized and deserialized.
This offers the potential of using WASM w/ go (or any other language I expect) to create the equivalent of Erlang's "Universal Server". Ie. create an API that receives the code necessary to "become" another API.
I have no personal experience with Wasmer or the people behind it. But with the things I read about them (e. g. https://mnt.io/2021/10/04/i-leave-wasmer/ crossed my path again a few days ago) would make me, to put it lightly, hesitate before building on it.
Thanks for providing the link, readers can probably judge for themselves by checking the comments there if blocking someone just for having a different point of view was the right thing to do by the Zig leadership team
> […] just for having a different point of view was the right thing to do by the Zig leadership team
From reading these threads it’s less about the opinions you hold and more about how you behaved, no?
Zig leadership asked you to not place bug bounties on issues without their consent. You decided to ignore their request and kept the bounty up by moving it to your own repo. Zig leadership decided you weren’t engaging in a particularly constructive way and decided you were unwelcome.
Is not a bug bounty and the bounty was placed for a feature we needed at Wasmer, it was not required to be merged upstream in Zig so of course we kept the sponsorship for the work up
WASIX relies on way too many forked projects to be maintainable. It's part of the reason that I resigned after only a couple months working for you - what you're trying to do isn't a terrible idea, but it is super poorly executed.
The other part is exactly what yoshuaw described as very disrespectful and immature behavior on your part. I know from my interactions with you that you are extremely argumentative _to a fault_, don't take no for an answer, and always assume you know better than everyone around you. Maybe you're somehow proud of that, but it's not surprising to hear you've been banned from participating in the Zig community.
You should respect the Zig community's wishes and be willing to contract the work out with clear terms, taking on some of the risk that it takes longer than expected yourself.
The "different point of view" here seems like you're determined to interact with their community in a way they've explicitly asked you not to [0]:
> Please don’t use bounties to incentivize Zig development.
They explained their reasoning extensively:
- Bounties foster competition at the expense of cooperation.
- Bounties are an utterly simplistic way of dealing with the business management side of creating software:
- Instead of scouting for a suitable candidate, you’re letting battle royale dynamics pick a winner for you, at the expense of everybody who’s going to lose the competition.
- Instead of creating a clear contract where you take on some of the risk, you implicitly put the entirety of the risk on the contestants (eg partial solutions don’t get any payout).
- Instead of allocating time and resources to proper due diligence, you instead penalize any form of thoughtfulness in favor of reckless action (eg a solution just needs to pass a test suite).
- Instead of planning for the full lifecycle of software, which also includes maintenance, you end up with a quickly bitrotting artifact that is of no practical use to anybody.
- Instead of spreading unease to all the people involved, it would be preferable you instead learned how to do business properly.
- On projects less radical than Zig, you might also put pressure on the development team to accept the winning submission, which, given the above, will probably not be the most well-thought-out and maintainable solution.
You responded by moving the request to your own repo, with the following disclaimer [1]:
> Info: while ideally the PR should be merged into Zig master, is not a necessary requirement to receive the bounty. As long as a fork exists that fulfills the requirements laid out before, the bounty will be awarded
To an outsider, this looks like you slapped a new name on the exact thing the Zig team asked you to stop.
Do you feel your new request adaquately addresses the team's issues?
While I respect their point of view, I do not agree that banning bounties in OSS projects is the right way of approaching it, and as such we haven't complied to it. Specially since this is a bounty for a real need that we have at Wasmer.
Furthermore, we also took their post constructively and added two more points on the bounty issue [1] that we believe should solve most of their concerns:
* Wasmer will manage the work and have at most one person or team working on it at a time. Anyone interested on the work should reply here and organization of the work will be done by the Wasmer team
* Partial work that actually works will be rewarded accordingly (for example, the libc layer, or the Zig layer itself)
Of course, the fact that they banned any further conversation from the disagreement doesn't make specially easy to see if such an approach will be sufficient for them or not.
Clearly, they are not compliant with WASI specifications built by the ByteCode Alliance, creators of WebAssembly. They are making their own web-assembly-thing not compliant with anything.
You forked the WASI Preview 1 and are making your own standards from it, and instead of working with the Bytecode Alliance, you are forcing your own standards.
I attempted to delete my Wasmer account a week ago. The button just prompted me to send an email, so I did that, but didn't get response since. Any idea how to enforce GDPR here?
The typical way would be to report it to the data protection authority in the European country in which you reside. Then they'll decide whether to take any action.
Could anyone speak to the core differences between Web Assembly (Wasm) and WebAssembly System Interface (WASI)? I noticed Go 1.21 supports WASI as a target, and given how new that is, I haven't seen many example projects that use it yet. Hoping it could make deploying to places like Cloudflare workers more feasible for Go projects now.
Out of the box WASM programs cannot interact with anything outside of the WebAssembly sandbox. It can only call functions that the host (whatever is running your WASM) has declared.. WASI is a standard set of functions that you can call from your WASM program so that you can interact with the host machine's file system, network and other things. It is modelled after POSIX. It provides some standardization for WASM programs for doing these types of things and guarantees some basic level of support. Otherwise, each host WASM program could implement them differently and WASM programs wouldn't really be portable.
51 comments
[ 2.5 ms ] story [ 225 ms ] threadWasmer 1.0 https://news.ycombinator.com/item?id=25649476 (161 comments)
Wasmer 2.0 https://news.ycombinator.com/item?id=27537541 (56 comments)
Wasmer 3.0 https://news.ycombinator.com/item?id=33721685 (183 comments)
We are planning to add more languages there once the SDKs are fully ready... stay tuned :)
I think this might be the breakthrough required to make wasm server-side very mainstream. I think there is still complexity and standardization issues on compilation side. When that is solved then server-side wasm would be ready for democratization I think.
The demo they put on the front page doesn't really sell it. I already have Python installed. It's need that they got it running, but how is this better?
What would sell it? Suppose there were a well-regarded hosting site that required uploads to be WebAssembly. Or maybe some popular app that required plugins to be written in WebAssembly.
[1] https://wasmer.io/wasmer/wcgi-wordpress-demo
[2] https://news.ycombinator.com/item?id=36726593
I think it's probably meant more as a demonstration of "run, publish and deploy any code, anywhere" rather than as a serious use case suggestion. It's taking something people are familiar with, know to be a bit messy and complicated and running it in a browser.
Embedding WASM on IOS might be problematic because of Apple's rules regarding what is and isn't acceptable there. They've never liked people embedding interpreters in their apps. That's how they blocked flash as well. And that's how they continue to block the firefox and chrome browser engines.
https://github.com/wasm3/wasm3
https://extism.org/
I haven't got around to actually trying it yet though.
1: https://www.fermyon.com/spin 2: https://www.fermyon.com/cloud
https://pkg.go.dev/github.com/wasmerio/wasmer-go/wasmer
> By extension, a headless engine can only execute a WebAssembly module, i.e. a module that has previously been compiled, or compiled, serialized and deserialized.
This offers the potential of using WASM w/ go (or any other language I expect) to create the equivalent of Erlang's "Universal Server". Ie. create an API that receives the code necessary to "become" another API.
Context: https://news.ycombinator.com/item?id=37545192
From reading these threads it’s less about the opinions you hold and more about how you behaved, no?
Zig leadership asked you to not place bug bounties on issues without their consent. You decided to ignore their request and kept the bounty up by moving it to your own repo. Zig leadership decided you weren’t engaging in a particularly constructive way and decided you were unwelcome.
The other part is exactly what yoshuaw described as very disrespectful and immature behavior on your part. I know from my interactions with you that you are extremely argumentative _to a fault_, don't take no for an answer, and always assume you know better than everyone around you. Maybe you're somehow proud of that, but it's not surprising to hear you've been banned from participating in the Zig community.
You should respect the Zig community's wishes and be willing to contract the work out with clear terms, taking on some of the risk that it takes longer than expected yourself.
> Please don’t use bounties to incentivize Zig development.
They explained their reasoning extensively:
You responded by moving the request to your own repo, with the following disclaimer [1]:> Info: while ideally the PR should be merged into Zig master, is not a necessary requirement to receive the bounty. As long as a fork exists that fulfills the requirements laid out before, the bounty will be awarded
To an outsider, this looks like you slapped a new name on the exact thing the Zig team asked you to stop.
Do you feel your new request adaquately addresses the team's issues?
[0] https://ziglang.org/news/bounties-damage-open-source-project...
[1] https://github.com/wasmerio/wasmer/issues/4218
Furthermore, we also took their post constructively and added two more points on the bounty issue [1] that we believe should solve most of their concerns:
* Wasmer will manage the work and have at most one person or team working on it at a time. Anyone interested on the work should reply here and organization of the work will be done by the Wasmer team
* Partial work that actually works will be rewarded accordingly (for example, the libc layer, or the Zig layer itself)
Of course, the fact that they banned any further conversation from the disagreement doesn't make specially easy to see if such an approach will be sufficient for them or not.
[1] https://github.com/wasmerio/wasmer/issues/4218#issuecomment-...
As a matter of fact we pass more tests than any runtime created by the BA as reflected here:
https://wasi.fyi/
I assumed they were compliant with the WASI specifications.
If you can send me an email to syrus@wasmer.io with your Wasmer username that would be appreciated
Staying clear
https://github.com/wasmerio/wasmer-ruby/blob/master/lib/wasm...