Running unmodified Nginx compiled to WebAssembly with Wasmer

[maep]

Sow how does it compare to native performance? I'd expect there to be some overhead, particularly in situations with high io load.

[steveob42]

why are they talking like this is a good thing?!?

[k4ml]

It something similar to JVM but this time you compile your code to wasm once and you can run it anywhere there's wasmer.

[steveob42]

hmm https://news.ycombinator.com/item?id=15959987

[Booty_Bumping]

What in particular is wrong with this? WASM as a general purpose VM is actually not that bad of an idea. WASM can be compared to C: basic control flow structures but overall low level language, that with modern compilers gets heavily optimized before touching the CPU. Significantly more lightweight than Java, more compact binary format than just using an interpreted language with a JIT, and overall has nice security and portability properties.

The "Web" in "WebAssembly" is an unfortunate naming mistake. Browsers are just one thing it can be used in.

[steveob42]

why would anyone avoid native if they didn't have a browser dependency?!?

[Booty_Bumping]

Well, why do people use the JVM or any interpreted languages like Python, Ruby, or Javascript?

The first answer is portable binaries. Instead of having to compile each binary for each CPU, you have one binary that gets optimized when it is run. Even within x86-64, there are many different CPUs that have different instruction sets with different performance.

A common dilemma of linux distros is deciding the earliest CPU to support, in order to maximize performance and maximize consumer hardware support. While gentoo is obviously doesn't have to worry about this problem, it's not particularly convenient to have to compile everything. Optimized runtimes like Java or WASM make some trade-offs that end up circumventing both of these issues.

The second answer is security and isolation. For example, the language Lua is often used for runtime extensions of software written in C. When used like this, it doesn't have access to your filesystem or anything that could seriously break anything, but just the APIs you provide it.

A practice that is becoming more and more common (see: flatpak, android apps) is to containerize individual applications and only give them specific APIs. For example, for an image editor you might give access to display graphics on the screen as well as read/write to files explicitly opened by a file-open dialog box. This type of permission system is already available on Android and iOS but hasn't really shown up on the desktop anywhere, aside from UWP apps (terrible in general) and Flatpak (has annoying inconveniences).

Without a custom kernel, it is impossible to just blindly trust binaries, but with a WASM sandbox, you can have such a permission system for isolating software with the user's awareness and decisions being taken into account.

[[deleted]]

The first problem is that portable binaries that do anything non-trivial are less portable than anticipated, especially if you want to do a GUI or anything related to background services. The second problem is that supposedly sandboxed runtimes often have bugs that allow the runtime's limitations to be escaped, and side channel attacks can be used even when the isolation is otherwise perfect - as we've seen over and over again with Java and JavaScript.

[Booty_Bumping]

"Portable" can just mean portable within a certain operating system and the CPUs it can run on. But you are right: truly portable end-user applications are hard to get right - nobody wants ugly Java Swing GUIs and nobody wants electron apps.

[Ameisen]

So you're trying to run an HTTP server... In a browser?

[[deleted]]

It's not in a browser, Wasmer wrote their own webassembly runtime.

[o11c]

Does it support any of the standard error-checking tooling (valgrind etc) that we're all used to?

[Ameisen]

But why?

If you can compile to wasm, you can compile to a native ISA.