Neat talk but like... doesn't it all seem convoluted? What is the function of a Rube Goldberg web service? To allow it be made of anything?
The problem with using Rust in Go is that you entirely miss all the parts you don't use Rust; you get the VM overhead of WASM so it kills Rust perf; you most likely introduce problems at the boundaries of Rust/Go.
Again it's a neat idea but why in all things sane would anyone intentionally do this outside of puzzle-solving satisfaction?
Author of the talk here. When I am doing conference talks to help explain abstract concepts or ideas, I typically prefer to employ a strategy called surrealist satire. This basically helps people understand where something fits into the stack by demonstrating how something fits into the mold and then by doing another completely impractical thing with that surrealist solution. The goal of this is to help people hook something into a greater set of context (due to the assumptions I made about the audience, I had to explain a bit more about the topic than I would have otherwise at say a WebAssembly conference) so that they can figure out how things that seem unrelated are actually quite related.
In terms of performance numbers though, I have quite intentionally NOT included performance benchmarks in this talk because getting stable performance information is nontrivial. I plan to write something in the future about WebAssembly vs native code as a subprocess (the differences with windows may surprise you!), but that is not a thing for today.
> Neat talk but like... doesn't it all seem convoluted? What is the function of a Rube Goldberg web service? To allow it be made of anything?
I don't want to be the guy who explains the joke, but sometimes Xe creates elaborate shitposts that aren't entirely shitposts but contain a very fun element to them rather than being for fully practical sake. Shitposting being an anagram for top insights after all.
That's the lens I used when interpretating this talk.
The current reference (only?) implementation of jpeg-xl is a c++ library, which I do not entirely trust to run in process in my go web server, and yet I would like to process images. Conveniently, the build system for jpeg-xl seems to support building to wasm, so if I can jam that into my process, I'd be a lot happier.
Ah, now THAT's an interesting aspect I wish someone would have brought up over the years I've seen WASM.
I guess WASM as a target and embeddable VM really helps with security in those cases. Couldn't we also do the same though with any number of arch/vm pairings?
I guess what WASM brings to the table is a compile target friendly enough for things like C and C++, i.e. low level code, and a reasonable VM implementation. It just has to be accepted by everything (both as an output format, and virtual machine impl in the language choice) to work, I think...
I don't know the current state, but the JVM had historically quite bad isolation. Javascript's isolation in browsers is actually pretty good. It's possible that the existing non-browser WASI implementations are terrible at isolation; since they exist specifically to allow access system resources they might be bad at denying access to system resources...
The JVM’s security in the Applet days were bad due to actually being capable at many functionality — it is trivial to properly sandbox something that has zero capabilities.
There is nothing inherent in the JVM that would make it less secure, we just realized in the meanwhile that blacklisting is not the way ahead, but whitelisting is.
Library sandboxing is a well known application of WASM. Search for the WebAssembly Component Model. There's also a way to use WASM to sandbox a C library - search for RLBox.
This looks more than a bit like the Inferno OS, created by some of the same folks who created Unix.
WASM allows to distribute cross-platform binary code written in memory-safe Rust, running on pretty compact VM. Think about a plugin architecture that could be built on top of that.
I'm no expert but the JVM is very modular these days and just the minimal modules also give you an order or two smaller runtimes. My guess is a set of minimal OpenJDK modules will be on the same order as a WASM VM. Would be curious to hear from someone more in the know
Looking a the JRE size is a bit misleading bc it's been sort of deprecated. You're not really supposed to make Uberjars to run on a JRE anymore but are expected to bundle with the JVM modules you need. It can make very small bundles..
But naturally an Uberjars would be smaller. I think small executables are possible but are also just a nongoal now in the JVM world. Meanwhile they're obviously still very relevant in the webspace and hence WASM
you're not really gunna send JVM bundles dynamically over the wire.
I do sort of agree with the parent that while the goals are slightly different it feels like WASM reinvented the JVM without really bringing any huge improvement (while you loose several decades of libraries)
There is no such thing as a JRE anymore, the way to package a Java application for quite some time now is by using jlink/jpackage that creates a stripped “JRE” of only the used modules helping both the size and loading times.
The problem with using Rust in Go is that you entirely miss all the parts you don't use Rust; you get the VM overhead of WASM so it kills Rust perf; you most likely introduce problems at the boundaries of Rust/Go.
Again it's a neat idea but why in all things sane would anyone intentionally do this outside of puzzle-solving satisfaction?