Introduction to Hippo: The WebAssembly PaaS
deislabs.io
deislabs.io
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.”
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 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...
With WASI too, the possibilities for interoperability between languages looks promising. I would check out the Wasmer runtime if you're curious about it.
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!
Can anyone please ELI5?
I read through the tutorial, but this is still not totally clear to me.
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.