[naikrovek]

OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen.

No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included.

If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform.

If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible.

This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser.

There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on?

I'm skeptical that this is a good idea for anything serious.

Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.

[ryanschneider]

> OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen.

It's _not_ a requirement, but at least to me it seems like a pretty good _possible_ solution.

I sense you're pretty jaded about web development, and I get that, but I don't agree this is "web people" trying to do things outside the browser, but rather I see it more as "systems people" trying to bring _some_ order to the chaos.

> nearly all developers are terrible at thinking about preventing security vulnerabilities

I totally agree. Which is why you should have a solid abstraction between the sandboxed code and what it's allowed to do, which WASM seems particularly good at (by only exposing services as syscalls). In theory, sandbox escapes in WASM should be the same level of difficulty as modern kernel exploits, so still _possible_ but _pretty hard_. And if multiple runtimes are using WASM for different things, if one is exploited it can be a learning lesson for all the other WASM runtimes, vs. the bespoke scenario where each custom VM has to go through the security bug discovery process by itself.

If _think_ what you're against is some sort of future where a "WASM-based-Electron" becomes the de facto standard for modern apps, and _that_ I largely agree with. In fact, re-reading the WASI standard I do feel like they are already "baking in" too much w/ WASI-core; I was expecting the core to just focus on a simple syscall ABI, not to include syscalls like filesystem reads and writes.

Some maybe what I'm really looking for is a "wasi-minium-abi" that just standardizes _how_ syscalls are made without actually standardizing any actual syscall numbers.

In summary, I feel like syscalls are a _very_ tried and true way to specify the API/ABI for a runtime, and that I hope we see more runtimes use WASM and a syscall ABI vs. rolling their own VM, but I agree that I'm in no rush to see WASM/WASI become the "Electron 2.0" of local app deployment.

[naikrovek]

I don't think that web technologies are going to be a good solution to anything that is not the web.

The web development community haven't even solved their own problem space very well; spreading to new problem spaces will likely not suit them as much as they believe it will.

[hutzlibu]

You should consider, that you just have a bias against "web people".

But this technologie comes not from javascript webprogrammers, but from browsermakers.

People who specialize in sandboxing, performance and portability since years. And they had to do this with javascript... and now they want a better foundation, BECAUSE of the flaws of javascript.

So I don't know if they will succeed making a better jvm either, but they certainly have the expertise that they might succeed.

[naikrovek]

I have no bias against "web people", I have a bias against using the wrong tool for the job.

This REEKS of developers who are psyched about WASM and want to create solutions where no problem exists.

If they want performant code outside of the browser, use any one of the 2-3 dozen languages that already do this! WHY is a new runtime, with the inevitable serious security issues that will be exposed throughout it's life, needed for this?

[RivieraKid]

Look at it this way, this won't cause any harm and there's some chance that it will develop into something useful and successful.

Right now there's no reason to conclude that this will turn into something that's no better than Java.

[naikrovek]

Has a single sandbox ever been written that has not had an escape vulnerability? I don't know of any. Sandboxes aren't safe, and everyone thinks of them as being a perfect prophylactic when they provably, demonstrably, and historically are not, in any way.

the solution is not to create another sandbox to run software in.

[morgancmartin]

Okay, I'll bite, what's the solution then? Personally, I don't have any novel software ideas lying around that are demonstrably better than what is proposed by WASI.

One advantage in this new push to build another sandbox is that Rust is leading the charge and is the de facto language of choice when building a greenfield WASM project. Given its propensity for memory safety and WASI's emphasis on capability-oriented security, I think the WASI team has a good chance of building something with a lot of value. Nothing here is novel (except perhaps Rust's extreme prioritization of memory safety) but that doesn't mean it can't or won't be an improvement over prior attempts.

I wonder how many of the previous sandbox vulnerabilities were viable due to some quirky memory manipulation techniques? Quite a few I would imagine.