Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standardizing WASI: A system interface to run WebAssembly outside the web

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 238 posts

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#41

Post by AnIdiotOnTheNet »

azakai wrote: post #18
tschneidereit wrote: post #11

Earlier quoted context omitted.

Yes!

What about platform differences like how file permissions work on windows vs posix? (i.e., stuff that Python does not fully normalize)

I have a dollar that says all platform difference issues will be solved by just doing whatever POSIX does and expecting the host OS to figure it out if it isn't already POSIX. Whenever you try to abstract away arbitrarily different implementations while retaining their non-common functionality you either end up reimplementing one of them and expecting the others to work around it, or you end up forcing the programmer to bypass the abstraction anyway and implement logic for each implementation.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#42

Post by pjmlp »

rapsey wrote: post #31
titanix2 wrote: post #16

Earlier quoted context omitted.

Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).

Properly sandboxed VM that you can compile practically any language into?

AS/400 TIMI comes to mind, and CLR as well.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#44

Post by AnIdiotOnTheNet »

Touche wrote: post #29

This is nice and I'm excited about it, however there is a concern that people are going to start building code that targets WASI and then shim it to run in the browser. This happened to JavaScript when Node.js was released; people began using APIs intended for servers and then shimmed them to also run in the browser resulting in code bloat. I'm worried that the same is going to happen here; the video actually encoura…

I think the browser shouldn't be a platform at all, frankly, and WASI is one possible way we can finally stop trying to shoehorn it into being one. If everything runs a WASI runtime, which is designed to run applications from the ground up, there really isn't any need for the browser to run applications anymore, is there?

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#45

Post by slimsag »

jxcl wrote: post #22
droobles wrote: post #20

Excuse me if I come across as naive, I'm kind of a noob on these architectural topics, but how is this different/better than what the JVM is/accomplishes? When WASM first popped up I thought about the similarities with Java Web Applets and Flash.

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…

Go already can be compiled to WASM, and it is likely that the Go GC will always perform better than the WASM one for Go applications (with some minor exceptions)

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#46

Post by Touche »

AnIdiotOnTheNet wrote: post #44
Touche wrote: post #29

This is nice and I'm excited about it, however there is a concern that people are going to start building code that targets WASI and then shim it to run in the browser. This happened to JavaScript when Node.js was released; people began using APIs intended for servers and then shimmed them to also run in the browser resulting in code bloat. I'm worried that the same is going to happen here; the video actually encoura…

I think the browser shouldn't be a platform at all, frankly, and WASI is one possible way we can finally stop trying to shoehorn it into being one. If everything runs a WASI runtime, which is designed to run applications from the ground up, there really isn't any need for the browser to run applications anymore, is there?

Yeah, sure, you go ahead and reinvent 30 years of cross-platform application APIs. I'll keep using the web until your new ones match maturity.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#47

Post by jcranmer »

writepub wrote: post #37

I would love for WASI/WasmTime to emphasize on: 1. Backwards compatibility with existing libc. (Maybe pick musl) 2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD #1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross pl…

> 1. Backwards compatibility with existing libc. (Maybe pick musl)

Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#49

Post by ryanschneider »

naikrovek wrote: post #33

ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises? I'm asking honestly - why is WebAssembly outside of the browser needed?

> why is WebAssembly outside of the browser needed?

It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal).

Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain specific.

For example, Functions as a Service. Currently AWS Lambda requires building a blob specially for them targeting their APIs and ABI. But what if Fastly, Fly.io, and the other "App CDN" FaaS providers come up with their own standard for "syscalls" for a WebASM-FaaS-1.0 spec? As a really bad example, the syscalls could be:

  - 1 GET URL
  - 2 POST URL
  - 3 Cache Read
  - 4 Cache Write
Meanwhile, in a totally different ecosystem, Ethereum can publish their own WASI for eWASM, where the syscalls are:

  - 1 Storage Read
  - 2 Storage Write
  - 3 Contract Call
Again, these are bad/contrived examples, the real syscalls would be better thought out than an HN comment, but the point is that you have two totally different runtimes, running is totally different places (on a CDN server, vs. inside an Ethereum node), both using the same tech stack w/ different "system interfaces" abstracting away what things your WASM code should have access to at runtime. Any language that has a compiler that targets WASM can be used in either case.

Furthermore, the barrier for entry as a syscall provider becomes much simpler too! If I want to make a local sandbox for FaaS testing, I just need to implement the syscalls from WebASM-FaaS-1.0 using local stubs, now I can test my FaaS locally. Way easier than the months/years probably spend reverse engineering the lambda environment for local testing. And if I come up with a novel solution for servicing one of those syscalls, hey, maybe I'll take my own stab at being a FaaS CDN. :)

Likewise for Ethereum and eWASM. Maybe I want to make a local test environment sandbox. Instead of re-implementing the EVM I "just" need to implement those syscalls outlined in the eWASM WASI spec (if such a spec existed). So now maybe light clients ship those syscalls over the wire somehow, and don't need to keep gigabytes of block chain data locally anymore.

edits: minor formatting

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#50

Post by gouh »

This sounds great. Basically the web created a cross platform & sandboxed API to access everything we need (Camera, Sensors, OpenGl through WebGl, etc.) but it was very opinionated (for historical reasons) as it imposes the slow JS, the DOM, CSS/HTML etc.

Now this is the same idea but, this time, one layer lower so that we can have performance, the language we want, etc. This is kind what I always wished would happen.

It will be interesting to see how the sandboxing will work with already existing sandboxing solutions. For e.g a WebAssembly app packaged as a Android/Flatpak/UWP/etc. , there will be the need to make mappings between the permissions of the two sandbox systems. Or even maybe one day we'll have the Webassembly sandbox as the only sandbox (like in https://github.com/nebulet/nebulet)

Post reply on HN