191–200 of 371 posts
WASM solves a different problem to containers. Where WASM does well is in running sandboxed code efficiently, because that's where it started out. I think WASM will likely take over as the standard for shipping things like Functions-as-a-Service implementations, and other forms of plugins, where one host application/server of some kind wants to efficiently run pieces of untrusted logic. Containers don't solve that pr…
Cloudflare, Fastly, and Amex use WASM in their FaaS implementations
As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure. > In the year 2030, no one will remember Kubernetes. So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/202…
Earlier quoted context omitted.
I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. There are a few niches where standardization of interfaces and discoverability will be extremely valuable in terms of interoperability and reducing the development effort to bring-up products that deeply integrate with many things, where currently each team has to re-invent the wheel again…
> I'm really eager to see what happens in the near future with WAT & WASI, but I'm also very aware of seeing a repeat of DLL hell. I think we can at least say WebAssembly + WASI is distinct from DLL hell because at the very least your DLLs will run everywhere, and be intrinsically tied to a version and strict interface. These are things we've just never had before, which is what makes it "different this time". Having…
Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through.
Earlier quoted context omitted.
This assumes that everyone implements the same set of APIs that work in the same way. More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementat…
Good point! This is the hard work that people are undertaking right now. Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces: https://github.com/WebAssembly/WASI/tree/main/wasip2 This is what people are building on, in the upstream, and in the bytecode alliance You're absolutely right about e…
I just don't see it. WASM requires throwing away all the decades of x86/ARM compiler work in ecosystems like Java, .NET and C++ and placing all trust in the WASM runtime/V8 to perform as well as them.
I've yet to see a single example of WASM in the wild. How is it supposed to "replace" anything, if nobody is using it?
Firefox also lets add-ons run WebAssembly modules which is something that uBlock Origin has made use of for a long time:
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
Earlier quoted context omitted.
WASM can, but does not replace containers. What is different is that instead of 20 applications running in 20 containers, 1000 applications will comfortably fit in one container, with better sandboxing than the linux process model at the application level.
I really wish you knew how silly this sounds & is. Why would you even run 1 container for 1000 applications if you're saying that WASM provides better sandboxing? Why wouldn't you just run a single WASM process? Also, containers are generally meant for single processes to provide isolation for each app, not to have all your apps running together with the same access. What many people don't get between WASM & containe…
Better sandboxing does not mean completely foolproof sandboxing, and defense-in-depth is a practice for a reason. The idea is a vulnerability in the runtime (your Wasm runtime) would mean system access. A vulnerability in the container runtime underneath (a different layer of security) would mean system access, and then a VM (if there was one underneath) is another layer to break through. This means to get to "root access" on a machine, there are now 3 layers of security to escape.
Running a single wasm process offers better isolation because it is deny-by-default, running a program as a process, or w/ cgroups + namespaces a a container has a wide surface attack surface. You can achieve greater density of applications with Wasm than you can with containers because of the lighter footprint thank a userspace process.
Containers are a hack that packages the assumption of an operating system and a bunch of other files and dependencies into essentially a tarball to make apps run. You must deal with isolation at the OS level (seccomp, etc). Wasm gives you greater control -- you don't have the "same access" for every app, you can vary access infinitely and dynamically, without worrying about OS primitives much more easily with WebAssembly.
It's OK if you think this is silly -- no one is forcing you to adopt the technology, it'll either come around or it doesn't.
> What many people don't get between WASM & containers is that containers don't need software developers to make changes to support containers. WASM however relies on software developers to make changes to their apps. Otherwise, you have to emulate an entire architecture in WASM which doesn't perform well. It is the difference between VMs, which emulates physical hardware & containers which doesn't need to emulate the hardware cause it provides the sandboxing using kernel features.
This is not necessarily true -- WebAssembly support is being added in languages upstream, and the goal (and reality for some programs today) is that compiling to WebAssembly does not require drastic changes. It's not perfect, but this is a stated goal, and is what is playing out in reality. The WebAssembly ecosystem is working very hard both internally and with upstreams to work with use cases/patterns that exist today, and make using WebAssembly close to a no-op/config change.
Any sysadmin/devops person can tell you that the move to containers was/is not pain free. I'm not promising Wasm will be pain free either, but the idea here is that change is happening upstream -- the ecosystem is working to make it pain free. It will be more like changing a few flags (e.g. building for ARM rather than x86) and following the errors. Some languages will be easier to do this in than others.
You'll just wake up one day and your python toolchain will be able to compile to WebAssembly natively with no extra tooling if you want. Maybe you don't have a stack that can make use of that yet, and maybe Django won't be fully supported early on, but Flask more likely will be.
No. Wasm is not useful enough yet. Neither are containers.
https://bandysc.github.io/AvaloniaVisualBasic6/
https://github.com/BAndysc/AvaloniaVisualBasic6
WebAssembly brings all languages to the browser and that's a good thing.
I can write applications for the desktop in any language, I should be able to do the same thing in the browser.
WebAssembly makes that possible.
Earlier quoted context omitted.
This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.
I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?
That's the idea behind the Extism framework:
uBlock Origin uses WebAssembly in Firefox for better performance:
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
Earlier quoted context omitted.
So basically virtual machines, those we can spin up with lxd or firecracker. Not that they don't have file access, it's just that's finnicky compared to containers (I'm thinking docker/podman)
Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model. Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm. The closer comparison is probably the JVM -- but with support for many…
https://en.m.wikipedia.org/wiki/List_of_CLI_languages
https://en.m.wikipedia.org/wiki/IBM_i#TIMI
Really this is only new for those that weren't around, many other examples, even older available.