That's not quite fair. IIRC workers do have cold starts but it is hidden by the TLS negotiation. So basically the start is nearly almost done by the time the request is received. I don't see any particular reason that this optimization couldn't be applied here.
> An application is packaged as a bindle. Bindles are collected together in a bindle server that you can search.
It’s a good article and nice work. But I couldn’t help but think of that one scene from Rick & Morty when I read this that goes like:
“Everyone has a plumbus in their home. First they take the dingle bop and they smooth it out with a bunch of schleem. The schleem is then...repurposed for later batches.
“They take the dingle bop and they push it through the grumbo, where the fleeb is rubbed against it. It's important that the fleeb is rubbed, because the fleeb has all the fleeb juice.
“Then, a schlami shows up, and he rubs it...and spits on it.
“They cut the fleeb. There's several hizzards in the way.
“The blamfs rub against the chumbles, and the...plubis, and grumbo are shaved away.
At some point we need to stop inventing VMs. VMs like Java, .Net, etc, are already good enough. What is the point of yet another VM? The same people who designed web assembly could have taken java bytecode and added new APIs on top. Instead, they invented yet another machine encoding that has to be targeted, except this time we get to re-invent all the tooling.
Look... I hate the Java language with a burning passion, but the Java VM core technology is perfectly acceptable. So is .Net. There is no reason for webassembly, other than that mozilla wanted to invent something.
We're biased towards additive solutions [0], but sometimes subtraction is the right answer to a design problem. The problems that WA aims to solve from existing VMs like JVM/.NET are caused by the old APIs themselves, adding more API surface would not help.
Sometimes adding the right thing can give you the opportunity to subtract. Code running in WASM may not have to run inside a Docker container running inside a Linux VM.
Nothing needs to run Ina container
Containers are just software engineerings latest name for a unix process. Both were designed to achieve similar levels of isolation.
In reality,there's no such thing as a container. As far as Linux is concerned, containers are just processes with attributes, because that's what they are, we just decided to complicate it a lot
Okay then define a subset of java opcodes supported and then modify the open source hotspot.
Look I'm trying to implement a wasm backend into an existing language right now and it could be a lot easier by either making wasm into a real architecture (with registers) or using an existing stack based vm isa.
Couldn’t wasm be compiled down to either a stack or register based VM equally well?
The text version is basically an ast (with the binary form being a desugared version of that) so you could do whatever you want to transform into something executable.
It is a mechanical transformation from stack to registers. In other parts of the thread you mentioned TCO, one can also convert recursion into iteration, tail calls can be handled by the compiler or with a trampoline.
The universe is much more flexible than you give it credit for.
Recursion can be converted to iteration very easily but then you lose all benefits of web assembly (dynamic linking, for example(.
The conversion from recursion to iteration mandates that all recursive entry points be known ahead of time so you can build a loop/conditional tree. If you want to dynamically load code, this creates two tiers of languages on the runtime.
WA can be transformed into native machine code in linear time, directly executed at (near) native speed, while retaining the VM memory protection barrier. No other VM can come close in these three properties at once.
If you're trying to integrate WA into a host language the easiest, fastest, and safest way would be to pick up one of the established well-polished compilers or interpreters and calling into it with a standard FFI interface.
Firstly... Any stock vm isa can be linearly compiled if you give up certain optimization.
For example, if wa wanted to use a coloring allocator it wouldn't be linear time anymore. That's not a fundamental part of it, just an implenebtation choice.
Firefox's WA backend does streaming compilation (i.e. compiling bytecode directly to machine code while it's still coming off the wire) for Tier 1, right now, by default, today. Afaik, WA is the first mainstream vm isa that it's even possible to do this. Do you know of any other VM that can compile its bytecode in one pass that is on by default? I'm genuinely interested. https://wingolog.org/archives/2020/03/25/firefoxs-low-latenc...
But this whole discussion is out of scope for your use-case. If it's For Fun (tm) that's one thing, but (presumably) this is a practical integration into an existing language. Why are you implementing a VM instead of integrating an existing implementation? Certainly you wouldn't even consider implementing a custom from-scratch implementation of the JVM, the fact that it's even possible to attempt such a thing for WA is already telling about which VM has a better design.
For some reason, it seems like you didn't read my comments. I'm not writing a WASM interpreter or JIT compiler... that would be quite straightforward. I'm attempting to implement a compiler backend for an existing programming language so that it can target WebAssembly. Since this is a functional language, it doesn't do things like have 'structured conditionals' (i.e., prodecural-like If/For/While statements and loops). Instead, it has recursion, which WebAssembly is terrible at. Not that other VMs are much better. You can make a claim this is about performance, but not in good faith. JMP is one instruction on X86_64 and B and friends on ARM are similar.
All these VMs and runtimes want to force you into particular ways of thinking about programming. This is terrible for the community. You can say Web Assembly is meant to be an open standard and you can sing that till the cows come home, but leaving out basic support for things like TCO, direct jumps, etc that are vital for compiling any non-procedural language, is just inexcusable at this point.
I know right, everyone wants to make their own VM become "the one" for computing to collect the sweet sweet tax.
If only the major companies sit together and agree upon a standard and let multiple VM implementations compete in an open-source manner ... oh wait, that's wasm.
The JVM does way more than Webassembly, completely different runtime characteristics. Webassembly is not attempting to be or do anything near what the JVM does.
Webassembly was designed for sandboxing untrusted code in a webbrowser, giving native like performance and limited functionality.
It just so happened the same characteristics for running untrusted code in the browser work really well for usecases people use AWS Lambda for etc. You have small lightweight applications that have limited system access you need to binpack and have fast startup / low overhead.
Webassembly/WASI isn't replacing the JVM/.NET, it's providing an alternative for specific use cases, running untrusted code in isolated environments that is fast and light weight.
Exactly. Web assembly doesn't support basic features like tail calls (neither does java), which are vital for whole classes of languages. This is where silicon excels... at letting you actually implement languages in the best way, instead of forcing you to think in particular paradigms. I believe .NET/CLR supports tail call optimization (I think it must for F#).
F# came later into the game, CLR was designed as COM evolution and was supposed to be for VB, C#, J# (evolution from J++ and migration path to .NET), and C++ (initially Managed C++, the C++/CLI with .NET 2.0).
On top of that, Microsoft enganged with the language community so that there were about 20 other languages available for .NET 1.0 on release date.
> One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.
Naturally MSIL had to support all of them.
The dynamic runtime came later as side effect from IronPython and IronRuby efforts.
Naturally WebAssembly folks are going to tell you they are the very first of this kind of efforts.
This, "...other than that mozilla wanted to invent something." Is not what happened. The browser vendors; Apple, MS, Google and Mozilla, whatever their reasons, decided they were going to kill Java and Flash in the browser. They then flailed about with NACL and other things, before Mozilla put forward WASM and they again, for whatever their reasons, accepted it. Complaining about it now, at least a decade late, is just weird to me. WASM isn't of interest because it's another VM, it's because it's the only VM that runs in the browsers (and soon lots of other places).
I understand that. I'm not saying WASM isn't of interest. On the contrary, since I'm currently implementing language support for WASM, I'd say it's very important.
What I am saying is that it is Java VM 2.0. The java ISA was perfectly fine. People knew how it worked, there was lots of tooling, etc. Instead of building off that, they made something new... just because. WASM is technically inferior to java, and is based upon the same basic principles. It's just like java bytecode in the 90s. It's not even done yet. This is a terrible mess.
The intro has some insider talk (ex, bindle). If you read on a little it describes how Hippo is a PaaS and uses WASM under the hood to make it happen.
This has some great potential. Is the node the code running on Linux, FreeBSD, Mac, Windows, or something else? Doesn't actually matter because web assembly is being executed.
Does this support outbound HTTP requests? wasi-experimental-http?
That bit seems to be the missing in the docs.
I'd say that's a bare minimum requirement to start playing with these services. You need to get data in/out and with no socket support HTTP is the only way. If you can't get data in/out there's little you can create on these.
Then you have things such as log access etc etc for prod workloads.
Fastly C@E with Lucet is really promising but Fastly are lacking marketing/delivery/execution. You can't use it unless you are on the private beta which you can't access as no seats left and even then there's no pricing information and Fastly's current pricing model makes it a non starter for dev with $50 minimum fee instead of pay as you go.
Five years some form of WASI will be available on all the FaaS services by the big cloud providers. Good to see these services starting to appear.
Does this make sense? Let’s say you’re developing a web service in Go or Rust, wouldn’t it be faster without being compiled to WASM but rather running natively?
Maybe so, but in the long-term, I can't help but imagine that a single WASM runtime for cloud functions has to be more predictable and easier to optimize compared to doing the same for the runtimes of all individual languages used. I think the promise of WASM is a huge reduction in duplicated effort industry-wide.
With WASI too, the possibilities for interoperability between languages looks promising. I would check out the Wasmer runtime if you're curious about it.
This looks great! I've been looking for something like this for quite some time now. There were some open source projects with similar goals that never went anywhere. I do have a couple of small Rust services that I'm running on a Digital Ocean node. My current process is cross-compiling them via Docker, copying the binary over, and then manually starting them in a screen or tmux. This is for personal use and doesn't require production level safety so this approach is fine for me. However, it is a hassle. I could run one of the many different docker-based deployment systems out there, but that adds a ton of complexity where I like simplicity.
One thing I'm missing from Hippo is a good example WASM app (preferably in Rust) that showcases a more complex app than Hello World and answers some questions such as:
- How would I add routes? (e.g. which Rust packages are supported)
- How would I access something like SQLite (does that even work?)
- How would I access the filesystem in general
- Is there a way to use HTML templates?
I suppose if I start reading about WASI and WASM more I'd find answers, but a better example app (such as, say, a TodoMVC) would probably be more illuminating.
This looks amazing, but as a complete n00b to wasm (I am familiar w rust and web tech), is there a simple overview on how I can take the compiled program and use in a development or production environment?
I read through the tutorial, but this is still not totally clear to me.
40 comments
[ 3.4 ms ] story [ 94.5 ms ] threadCan anyone please ELI5?
It’s a good article and nice work. But I couldn’t help but think of that one scene from Rick & Morty when I read this that goes like:
“Everyone has a plumbus in their home. First they take the dingle bop and they smooth it out with a bunch of schleem. The schleem is then...repurposed for later batches.
“They take the dingle bop and they push it through the grumbo, where the fleeb is rubbed against it. It's important that the fleeb is rubbed, because the fleeb has all the fleeb juice.
“Then, a schlami shows up, and he rubs it...and spits on it.
“They cut the fleeb. There's several hizzards in the way.
“The blamfs rub against the chumbles, and the...plubis, and grumbo are shaved away.
“That leaves you with...a regular old plumbus.”
https://youtu.be/eMJk4y9NGvE
Look... I hate the Java language with a burning passion, but the Java VM core technology is perfectly acceptable. So is .Net. There is no reason for webassembly, other than that mozilla wanted to invent something.
[0]: Adding is favoured over subtracting in problem solving https://news.ycombinator.com/item?id=26727878
In reality,there's no such thing as a container. As far as Linux is concerned, containers are just processes with attributes, because that's what they are, we just decided to complicate it a lot
Look I'm trying to implement a wasm backend into an existing language right now and it could be a lot easier by either making wasm into a real architecture (with registers) or using an existing stack based vm isa.
The text version is basically an ast (with the binary form being a desugared version of that) so you could do whatever you want to transform into something executable.
The universe is much more flexible than you give it credit for.
The conversion from recursion to iteration mandates that all recursive entry points be known ahead of time so you can build a loop/conditional tree. If you want to dynamically load code, this creates two tiers of languages on the runtime.
You really think I haven't thought of this?
If you're trying to integrate WA into a host language the easiest, fastest, and safest way would be to pick up one of the established well-polished compilers or interpreters and calling into it with a standard FFI interface.
For example, if wa wanted to use a coloring allocator it wouldn't be linear time anymore. That's not a fundamental part of it, just an implenebtation choice.
But this whole discussion is out of scope for your use-case. If it's For Fun (tm) that's one thing, but (presumably) this is a practical integration into an existing language. Why are you implementing a VM instead of integrating an existing implementation? Certainly you wouldn't even consider implementing a custom from-scratch implementation of the JVM, the fact that it's even possible to attempt such a thing for WA is already telling about which VM has a better design.
Take your pick: https://github.com/appcypher/awesome-wasm-runtimes
All these VMs and runtimes want to force you into particular ways of thinking about programming. This is terrible for the community. You can say Web Assembly is meant to be an open standard and you can sing that till the cows come home, but leaving out basic support for things like TCO, direct jumps, etc that are vital for compiling any non-procedural language, is just inexcusable at this point.
If only the major companies sit together and agree upon a standard and let multiple VM implementations compete in an open-source manner ... oh wait, that's wasm.
Both are more advanced
Webassembly was designed for sandboxing untrusted code in a webbrowser, giving native like performance and limited functionality.
It just so happened the same characteristics for running untrusted code in the browser work really well for usecases people use AWS Lambda for etc. You have small lightweight applications that have limited system access you need to binpack and have fast startup / low overhead.
Webassembly/WASI isn't replacing the JVM/.NET, it's providing an alternative for specific use cases, running untrusted code in isolated environments that is fast and light weight.
20 years ago I was running untrusted code in isolated environments via application containers like HP-UX Vault and later Java Application Servers.
On top of that, Microsoft enganged with the language community so that there were about 20 other languages available for .NET 1.0 on release date.
Here, diggging through the archives,
https://docs.microsoft.com/en-us/archive/msdn-magazine/2002/...
> One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.
Naturally MSIL had to support all of them.
The dynamic runtime came later as side effect from IronPython and IronRuby efforts.
Naturally WebAssembly folks are going to tell you they are the very first of this kind of efforts.
What I am saying is that it is Java VM 2.0. The java ISA was perfectly fine. People knew how it worked, there was lots of tooling, etc. Instead of building off that, they made something new... just because. WASM is technically inferior to java, and is based upon the same basic principles. It's just like java bytecode in the 90s. It's not even done yet. This is a terrible mess.
This has some great potential. Is the node the code running on Linux, FreeBSD, Mac, Windows, or something else? Doesn't actually matter because web assembly is being executed.
It reminded of the Birth & Death of JavaScript talk from a bunch of years ago (it's really about wasm)... https://www.destroyallsoftware.com/talks/the-birth-and-death...
That bit seems to be the missing in the docs.
I'd say that's a bare minimum requirement to start playing with these services. You need to get data in/out and with no socket support HTTP is the only way. If you can't get data in/out there's little you can create on these.
Then you have things such as log access etc etc for prod workloads.
Fastly C@E with Lucet is really promising but Fastly are lacking marketing/delivery/execution. You can't use it unless you are on the private beta which you can't access as no seats left and even then there's no pricing information and Fastly's current pricing model makes it a non starter for dev with $50 minimum fee instead of pay as you go.
Five years some form of WASI will be available on all the FaaS services by the big cloud providers. Good to see these services starting to appear.
Good point on the docs, I will open an issue and add some information about it, thanks!
With WASI too, the possibilities for interoperability between languages looks promising. I would check out the Wasmer runtime if you're curious about it.
One thing I'm missing from Hippo is a good example WASM app (preferably in Rust) that showcases a more complex app than Hello World and answers some questions such as:
- How would I add routes? (e.g. which Rust packages are supported)
- How would I access something like SQLite (does that even work?)
- How would I access the filesystem in general
- Is there a way to use HTML templates?
I suppose if I start reading about WASI and WASM more I'd find answers, but a better example app (such as, say, a TodoMVC) would probably be more illuminating.
I read through the tutorial, but this is still not totally clear to me.