Wasmer – Run, Publish and Deploy any code, anywhere | Hacker News Reader

Wasmer – Run, Publish and Deploy any code, anywhere

wasmer.io

121 pointsgorenb51 comments

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.

This CEO in question also appeared yesterday here and was blocked from ziglang. https://news.ycombinator.com/item?id=37541994

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

Context: https://news.ycombinator.com/item?id=37545192

> […] 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.

Please read the comments on other threads https://news.ycombinator.com/item?id=37558807

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?

[0] https://ziglang.org/news/bounties-damage-open-source-project...

[1] https://github.com/wasmerio/wasmer/issues/4218

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.

[1] https://github.com/wasmerio/wasmer/issues/4218#issuecomment-...

Isn't that how oss works? You should be able to add bounties to your fork. Then zig team can choose not to merge these if they want.

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.

What do you mean? We are as compliant with WASI as a Wasm runtime can be. We have tests assuring that for each commit on our repo.

As a matter of fact we pass more tests than any runtime created by the BA as reflected here:

https://wasi.fyi/

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.

Where is that clear?

I assumed they were compliant with the WASI specifications.

They are forking from WASI Preview 1, but Bytecode Alliance is working on WASI Preview 2.

"Get started" links to discord? This get more and more common, but no thanks.

Can some into discord explain why it's good for documentation? It seems like a dumpster fire to me.

That's a bug. The proper link should be pointing to the Wasmer runtime docs. Thanks for pointing this out!

Previous discussions:

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

Wasmer 3.0 https://news.ycombinator.com/item?id=33721685

Thanks! Fixed.

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.

How does this compare to Fermyon’s Spin [1] and Cloud [2]?

1: https://www.fermyon.com/spin 2: https://www.fermyon.com/cloud

From the Go runtime docs here

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.

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.

That's the languages. I'm expecting/hoping to be able to run it in the CLI, web browser, native GUI, mobile, and on an ESP32.

It’s a developer “product”, so you can package it however you like.

You are completely right... we need to improve that!

We are planning to add more languages there once the SDKs are fully ready... stay tuned :)

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?

[1] https://wasmer.io/wasmer/wcgi-wordpress-demo

[2] https://news.ycombinator.com/item?id=36726593

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

All three languages have C FFI support of some kind. You could write it in C or C++ with some generated (or manual) wrappers/shims.

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.

Technically you could run the wasm code in a web view, but that would make all calls have overhead in the milliseconds range

There’s a wasm interpreter you can use on iOS.

https://github.com/wasm3/wasm3

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.

You want something like this:

https://extism.org/

I haven't got around to actually trying it yet though.

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.

Thanks! This is really helpful.

Wasmer rubs me the wrong way for some reason

Staying clear

Cool, so Wasmer could in theory allow me to run functions from Rust in Ruby via a wasm module?

Can't you already do that by writing a shared library?

Through FFI? Yeah.

The calls to WASM would also be through FFI, right? Because it's not part of the actual ruby runtime.

Looks like it's done through shared library

https://github.com/wasmerio/wasmer-ruby/blob/master/lib/wasm...

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.

Not sure how that slipped through the cracks, but I will handle it directly to make sure the account deletion is properly handled asap.

If you can send me an email to syrus@wasmer.io with your Wasmer username that would be appreciated

Reply on news.ycombinator.com