141–150 of 371 posts
WASM does not run on real hardware. At best, WASM can be considered a virtual machine (in the way that the JVM and the .NET CLR are virtual machines). I guess we can call that a "runtime". Containers package applications that run directly on real hardware (well, directly on a real kernel that is running on real hardware). There is no runtime. I am talking OCI containers here (Docker and Kubernetes). At least they can…
Earlier quoted context omitted.
> I'm no wasm expert, but I find it just fantastically unlikely that they're going to beat the decades of research that have gone into the JIT in the JVM anytime soon Probably not, but that's sort of orthogonal to my point. Java started as "write once run anywhere", but it has almost become the opposite of that: "write once, run it on your specific server". "Portability" is not nearly the same concern with Java as it…
> "write once, run it on your specific server". Funny, how people forget that a "specific server" can be running Linux on bare metal ARM or a x86 container, or maybe Windows or even MacOS.
For a server environment, I set all the parameters I want and then I code around it. Obviously there's a lot of variation between different servers, but you typically develop your server code a specific set of servers.
One advantage of containers is that run lots of software with it. Take old Perl application, wrap it in container, and then run in the cloud. Keep that old binary application that somehow lost the source for. Also, I think most uses of containers lose the advantage of WASM. WASM is about running on any platform, great for browsers and serverless. But containers are usually run in controlled environment where can comp…
Earlier quoted context omitted.
> but I’m sure we’ll still be using k8s (and COBOL) in 2125. If you want a vision of the future, imagine a bare metal hypervisor hosting Linux hosting K8S hosting V8 hosting a WASM-based IBM mainframe emulator running COBOL.
It's running on a quantum computer emulating a classical computer ofc.
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…
Lots of people use wasm in production right now, and toolchain support is in a good place across several languages. In that sense we are already there. You likely visited a website using wasm today without realizing it, and major apps like Photoshop have been ported to wasm, which was the original dream behind it all. That has all succeeded. But if you want to replace containers specifically, as this article wants, t…
Like, how easy is it to write a web application in Wasm? Or how easy is it to compile your average program written for a native platform to Wasm without hand picking your dependencies to work on the platform?
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…
> When are we actually getting this future? Around the same time Linux is ready for the desktop.
"Learning how to use Docker is a distraction" As if you need to learn anything, you get your Dockerfile and that's it, what else there is to learn? Your WASM app still need Kubernetes to run so it's not adding any value. The complexity is not in running your app in Docker, the complexity is running your container somewhere, and WASM does not help at all with that. WebAssembly is not going anywhere, it's pretty clear…
Disagree. It's not trivial to manage a running container or group of, with firewalls and filesystems and whatnot. My biggest gripe is that it's quite redundant with the os and tends to reinvent stuff. You end up needing to learn, doc, and build towards both os layer fw and container layer fw for example.
I've grown less young since then, and I can probably count numerous other claims for some great idea to replace "all this crap very soon." Turns out, "one-size-fits-all" solutions are almost always hype, sometimes not even backed up with pragmatic arguments. There are simply no silver bullets in our industry, especially in relation to web tech. Guess what? Some websites are still being built with jQuery, and maybe there's nothing wrong with that.
No, WASM not going to replace containers. At best, it will likely find its specific niches rather than becoming a universal solution. That's all.
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
>But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. So an operating system?
Check out the WASI repository. For people not understanding what WASI is, I always tell them it's something like a reference/specification of cross platform syscalls that have to be implemented in WASM VMs.
Of course, access to such things always come with assumptions of control and policies that rely on behavioral analysis. So I hope that something similar to host and web application firewall rules will come out of this, similar to how deno does it.