10 ms·

“WebAssembly runtimes will replace container-based runtimes by 2030”

113 points by ingve 3y ago

emadda 3y ago
Reasons why WASM will not replace containers: - System calls call into the Linux kernel for things like disk and network access. These are highly tested and reliable. To keep WASMs isolation and portability it would need to replace these APIs with new message passing ones which would kill performance. - C FFI - Dynamic libs Being able to integrate with existing C libraries in the way they are intended to be used. - Better VMs/OS level sandboxing MicroVMs like Firecracker that let you run your code unmodified as if it is running directly on the OS. I like WASM, but feel it is over hyped and the alternatives are “good enough” and already widely used. In the browser it is great though.
mikewarot 3y ago
This is highly unlikely in either of the futures I see for WebAssembly: 1 - The best timeline: WebAssembly keeps its strong capabilities based security model, which requires explicit granting of resources to code inside the sandbox. This is great for security, but it requires giving up full access to the file system, and other I/O... which requires rewrites of things. This will, in turn, mean that many workloads won't shift to WebAssembly 2 - The worst timeline: WebAssembly repeats the mistakes of JVM, and eventually succumbs to the demands to allow full access to all of the resources of the host system, defeating capabilities, and making it a new JVM. Thus, it's not as safe as a VM, why would anyone use it? So, most workloads don't shift to WebAssembly. [Edit/Append] WebAssembly uses a capabilities model of security. You have to explicitly give it access to resources from code outside of the sandbox, which are then passed (like file handles) to the code running inside the sandbox. This completely and securely prevents the code inside the sandbox from causing any undesired side effects in your system. Think of it as handing someone $5 cash to make a purchase. You can't lose more than $5, no matter how confused or wrong things go after that point, you've limited the side effects to that $5. Or think of it as plugging in a device to an outlet with a 15 Amp circuit breaker. No matter what you do, you won't draw 100 amps through the outlet, nor take down the grid (like the power in the old TV show Green Acres). This is different than "capabilities" on a smartphone, which are "allow location access" or things like that, global, non-granular access to big chunks of your system. There is no "allow access to your file system?" flag in WebAssembly. In the best timeline, there never will be.
- da39a3ee 3y ago
  > WebAssembly keeps its strong capabilities based security model, which requires explicit granting of resources to code inside the sandbox. This is great for security, but it requires giving up full access to the file system, and other I/O Can you unpack that a bit for those of us who don't know this area well? Can't "access to filesystem" be one of the capabilities that can be granted or not granted, thus giving no decrease in security because anyone who wishes to host webassembly without granting it is able to do so?
joeyguerra 3y ago
no they won't.
da39a3ee 3y ago
> To get the full experience you should listen while you read. > Click here to listen along while you read. It's better! How could it possibly be better to listen to some people talking thus distracting you while you're reading?
hnaccountme 3y ago
Can we get to a point where we ship binaries NOT source code?
torginus 3y ago
My prediction, is by 2030, a new generation of developers will replace WebAssembly with a brand-new shiny thing that will be clearly superior to what the then-senile and geriatric developers of the clearly-flawed WASM implementation have created, as it will be based on fresh news ideas (tried first in the 1980s). This new thing will address all the shortcomings of WebAssembly, and will be projected to become the standard portable way of running applications by 2040.
o1y32 3y ago
The whole thing feels hallucination from someone who didn't spend enough time with either WebAssembly or containers and simply didn't understand how these things work.
phendrenad2 3y ago
I don't see this catching on when an effectively similar thing (Java app servers) failed to catch on. Containers are just easier.
paulddraper 3y ago
I mean, to state the obvious....no, no they won't.
- recursive 3y ago
  It's not obvious to everyone. Some of us would need to hear some reasoning before we'd find this line convincing.
SirMaster 3y ago
Does it really make sense to run so much inside a web browser? Are we perhaps over-utilizing web browsers?
- adam_arthur 3y ago
  WASM is not strictly for the web, its a generic low-level language target/series of specs. The article itself is talking about server runtimes/workloads, nothing to do with browsers. If generic specs can be built around WASM in such a way that you can run code securely without booting an entire OS, WASM will replace traditional containers. Smaller runtime footprint. A consequence of having a generic compile target/spec is that your applications will also be able to run in the browser with minimal effort
  - jjtheblunt 3y ago
    > WASM is not strictly for the web, its a generic low-level language target/series of specs. What about it is preferable to MLIR or even LLVM? https://mlir.llvm.org/ https://mlir.llvm.org/
    - adam_arthur 3y ago
      WASM is designed with security in mind, and specifically to provide primitives for use in a secure runtime. LLVM doesn't provide that to my knowledge... instead just cross-compiling code specific to each target. Correct me if mistaken. I imagine there are meaningful build time drawbacks to compiling an executable for each environment as well. While WASM will never outperform native code, it can get very close. Minor loss in performance is a small price to pay for portability/security.
- stanleydrew 3y ago
  At the risk of taking the bait, I'll point out that WASM doesn't just run in web browsers.
  - SirMaster 3y ago
isoprophlex 3y ago
When can I start shoveling my python/pytorch/CUDA spaghetti into WASM? I would like serverless or at least rapid booting GPU functions...
panick21_ 3y ago
I have not listen to this podcast. Given the development speed I'm seeing from Webassembly, I really don't think so. Also it seems to solve a different problem, yes some thing containers are useful for Webassemtly might be really useful for. But a lot of other things I just don't see it. Will I run databases compiled to webassembly? That said I really think Webassembly is cool and like many of the ideas. Will listen to this podcast, lets hope I am convinced. Edit: Good title marketing
aidenn0 3y ago
> 1 tight security model > 2 very fast boot-up time > 3 scalability at the edge > 4 much smaller footprints > 5 portability across environments Aren't #2-4, just wasm rediscovering static linking? 95% of the advantage that docker has over a tarball is due to gcc's (and glibc's) strong bias towards dynamic linking and how hard it is to portably package a python application's dependencies.
- recursive 3y ago
  Perhaps not coincidentally, #1 and #5 seem like the most significant features from this list.
- throwway120385 3y ago
  Another often-overlooked advantage of Docker is the fact that its checksummed tarball of your base container image can be shared with other container images. This can cut down on data transfer and data size if you use the same base image for everything because it's only transferring delta images.
  - hinkley 3y ago
    Most of our services use the same base image and some of them run in the same host. The main thing to watch out for is that the steady state disk usage is different from the worst case. During upgrades the amount of disk used can balloon up for a little while, and these sorts of transient costs tend to mess with people’s ability to do capacity planning properly. So there’s a law of diminishing returns for pushing things out of your images into a common base. The more you do the larger the over/under gets. Spend a good bit of energy in shrinking the base image, not just growing it, and you’ll be okay.
  - strangescript 3y ago
    This doesn't even really apply to wasm though. That is the big difference. You would have a runtime that can execute wasm, and its all the same. Any browser can run wasm provided you don't try unsupported sys-calls.
throwway120385 3y ago
It seems like they're conflating the need to run a specific software stack with the need to do configuration management in general. Configuration management doesn't go away with WebAssembly as they're describing. You're just making fatter statically-linked processes that boil down to interpreters plus source code. People are already statically linking with EG GoLang or .NET Core anyway. So I would guess that the future is static linkage with control groups moreso than it is a specific JavaScript/TypeScript software stack running in a specific runtime. Frankly the way we're shipping dependencies in what are basically checksummed tarball blobs is an echo back to static linkage at a time when most OS platforms have gone very deeply down the dynamic linkage rabbit hole to the degree where everyone is shipping dynamic libs instead of statically linking those libs into their executable. Control Groups are supposed to provide process isolation but are being used to solve this configuration management issue as well because a particular company decided to use chroot in this way.
- photonbeam 3y ago
  “Namespaces” in linux provide a lot of the isolation that people associate with containers With a mount namespace you can pivot root
- no_wizard 3y ago
  What company decided to use chroot this way? I'm going to guess its Microsoft, but I think thats not either entirely correct or I'm off base
  - ilc 3y ago
    Google is famous for statically linking everything.
    - no_wizard 3y ago
      I don't think its only static linking that is the source of this practice right?
  - paulgb 3y ago
Deukhoofd 3y ago
If WASM can overcome the current extremely sluggish development speed, I can definitely see some applications of containerization move to WASM, but I really think like containers and WASM are two very different solutions.
paulgb 3y ago
For some context, this is from an “unpopular opinions” section of the podcast where they specifically ask for a controversial opinion. In the ensuing discussion, the prediction is further qualified: > I’m not gonna say it’s gonna replace every use case; it’s clearly not. But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I do think that if WASI gets sockets and threading soon as planned, it suddenly becomes compelling for a bunch of interesting workloads that containers are used for now.
- troupo 3y ago
  > But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I fail to see how it's applicable. Unless your entire world is Javascript and its performance
  - preseinger 3y ago
    wasm is not bound to javascript in any meaningful sense
    - troupo 3y ago
      wasm literally came out of asm.js and browsers. And its original goal is literally to make stuff in browsers more performant compared to Javascript. So when people say stuff like "high-performance latency-sensitive use cases are applicable to wasm" they clearly only understand performance and latency in comparison to Javascript.
      - preseinger 3y ago
        it started there but that's not like the only goal of the thing and like there's plenty of people doing wasm on the server where performance is measured in microseconds
wrs 3y ago
“So you basically have the full SpiderMonkey runtime running within WebAssembly, running your JavaScript or compiled TypeScript code…” From my old cynical curmudgeon viewpoint, this may be a valid approach, but you need to find a way of saying it that doesn’t sound so ridiculous. A wasm SpiderMonkey runtime running inside a native SpiderMonkey runtime? And presumably the inner runtime supports wasm?
- wmf 3y ago
  I still don't understand the point of WASM-only runtimes when V8 can run WASM and JS.
  - nine_k 3y ago
    A WASM runtime can be dramatically smaller, which may be important in some scenarios. WASM runtimes should grow to a maturity level somehow comparable to V8, JVM, .NET runtimes before they start competing with them. Currently WASM accompanies other software, and I find it pretty correct.
- hajile 3y ago
  This was predicted a decade ago. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
dragonelite 3y ago
Containers im not so sure but i can see WASM runtimes be integrated into edge functions like services.
nomilk 3y ago
Is it correct that WASM probably won't affect most CRUD apps, since most don't need significant client-side compute or graphics resources? But that WASM might enable intensive applications (e.g. cutting edge games, or 3D rendering software like an architect might use) to run in the browser, rather than on the OS, thus enabling developers of that software to make much more frequent updates (just like any web application)? What would this mean for page load times (e.g. surely not a 700MB program downloading when the user visits a URL..?.. or.. can it?) (apologise for the newbie questions)
- paustint 3y ago
  WASM is not just a browser technology, it can be (and is heavily) used for edge and servers. I can write code once and run on many runtimes across many different programming languages. I think the server use-cases are actually more compelling than the browser use-cases. For example, Fastly's edge compute supports running WASM code at the edge. Similar to lambda, but in the language of your choice and with great sandboxing qualities baked in.
- candiddevmike 3y ago
  WASM had some neat/gross implications for blackbox CRUD apps without having to show source. Some people might even start embedding secrets in web source code again!
- mike_hearn 3y ago
  WASM probably won't affect most websites today, correct. WASM probably won't enable cutting edge games. It has been around for years and there's no interest from the gaming community there, the newest additions to WASM like GC won't affect games much. There are other issues with the web platform that prevent this from working, e.g. the implicitly managed disk cache, the relatively old graphics APIs exposed into the sandbox, the performance impact of sandboxing, and a few other things. The games world has Steam and consoles, that seems to be good enough for them. There might be some attempts to port desktop productivity software to the web using WASM, probably in partnership with Google, like what an architect might use. But probably not. Installing software isn't hard and pro grade software isn't an impulse buy. How much incremental revenue would a web port bring relative to the cost? Probably not much. 700mb programs downloading when a user visits a URL isn't necessarily a problem if that download actually sticks, but see caching issues above. After all, people routinely download programs that large. Chrome itself is ~500mb on disk!
hosh 3y ago
Bold to make a prediction like that. But I think perhaps the author doesn't understand Kubernetes as much -- you can run Webassembly as the runtime for Kubernetes, and get the other things Kubernetes provide, such as self-healing. It's because Kubernetes is not built monolithically, and things like the runtime or kubelet can be replaced with something else. https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rust https://developer.okta.com/blog/2022/01/28/webassembly-on-ku...
theptip 3y ago
> I’m not gonna say it’s gonna replace every use case; it’s clearly not. But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem Behind the clickbait headline, a much narrower and reasonable claim.
- jerodsanto 3y ago
  This is a phenomenon we see over and over with our "Unpopular Opinions" segment. The summary statement is often unpopular, but once you hear out the person's reasoning (unless it's about food or something purely subjective) most people end up agreeing with them. It's been tough to get _truly_ unpopular opinions (as voted on by Twitter/Mastodon users) represented on the pods.
  - mike_hearn 3y ago
    What are some truly unpopular opinions?
- secondcoming 3y ago
  How big are app downloads going to get!?
  - theptip 3y ago
    This article discusses replacing your container/VM backend with a tiny wasm bundle probably run at the edge. The app sees no changes to the API requests it makes.
junon 3y ago
Mmmm don't think so, no. They solve entirely different problems. I also don't think containers will be around in 2030, there will be more fleshed out OS-supplied facilities for general purpose sandboxing I'd think. Title is clickbait anyway, and such blatant and Shameless clickbait at that.
remram 3y ago
Probably not. We have virtual machine runtimes which are more secure and more generic than containers, but we still use containers because they are much more efficient. WebAssembly provides only some of the goodies of VMs while taking away most of the efficiency of containers... they have their use, but I don't see why we expect a runtime to take over the others.
TekMol 3y ago
What does that even mean? When I use a container, I get all the stuff a Debian distro brings: A file system Process management My favorite database (SQLite) My favorite webserver (Apache) My favorite runtime (CPython) A gazillion helpful applications and libraries (Like imagemagick) Tons of convenience glue (like /etc/hosts) I get all of that in a reproducible, isolated little universe. How does a "WebAssembly runtime" provide me with those?
- paddw 3y ago
  https://wasi.dev/ https://wasi.dev/ allegedly. Development seems slow though.
- dboreham 3y ago
  Wait until 2030.
- preseinger 3y ago
  wasm doesn't give you a vm, it gives you a process
  - saidinesh5 3y ago
    To be more precise, if you wanted an isolated process, docker already gives you that. Along with the overhead of spinning up a new process for every request you want to handle. What wasm people seem to be interested in is to eliminate the process (and hence a language runtime) spawning overhead, and directly execute the specific function of your application.. "Write your serverless function in any wasm compilable language and our multi tenant runtime can host 1000s of such functions and invoke them without much delay".. Of course, that only makes sense for programs which are written in wasm compilable language. When they do crazy things like running js scripts on top of a quickjs interpreter compiled to wasm to run on top of a wasm interpreter "for portability and safety", it gets weird to see the benefits..
- moonchrome 3y ago
  By same logic why use containers ? You can just ship VM images. It's basically the same thing as using a language runtime vs using a generic container for Lambda, except WASM would be lower level (you would need to ship language runtime on top of WASM but that's probably order of magnitude less overhead than a container) Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs, but I'd much rather deploy runtime/app code only.
nine_k 3y ago
If you were around ~25 years ago, you likely remember the idea that JVM will run everywhere and replace everything. (And some XML on top.) Indeed, JVM can run everywhere, and has reached far and wide, from SIM cards to huge servers. But it has not replaced all other runtimes, even when it achieved really good GC and and near-native speed thanks to JIT compilation. WASM is very similar to JVM in many regards. It will reach far and wide, it will supplant a few things, but I bet it's not going to replace too many things, let alone native code in containers.
- jw1224 3y ago
  WASM is a compiler target for countless languages, unlike JVM which is tied to Java. That’s what makes it incomparable to JVM… It’s a global runtime-on-demand for whatever you throw at it.
  - o1y32 3y ago
    JVM is not tied to Java. Get basic facts right.
  - pjmlp 3y ago
    In relation to JVM true if we ignore the evolution of the ecosystem. Then there are the CLR, IBM TIMI and plenty of other ones all the way back to 1961.
- hajile 3y ago
  Security and universality are the biggest differences here. WASM was ground-up designed with security in mind (learning from earlier projects like pNaCl). Likewise, WASM was designed with a lot of language targets in mind rather than just Java.
  - pjmlp 3y ago
    Sure, if we ignore internal memory corruption inside linear memory. JVM might not be the ideal example of polyglot runtime, yet there are several others of the same vintage, designed with multiple languages in mind, including C and C++, e.g. CLR, TIMI,...
esdott 3y ago
My understanding is that the goal (if not there already) is that you can use wasm tech just like docker/etc. The value prop is wasm would be lighter and have other built in benefits with the adoption of newer browser (security) features like sandboxed file system integration. This would be made available without the overhead of chrome per se. forgive me if I overstate something but this is the gist.
deleted 3y ago
[deleted]
jagrsw 3y ago
While I've only briefly examined the WebAssembly (WASM) security model, it seems like a recurrence of vx32 and NaCL. One inherent issue is the "glue" code enabling the WASM runtime to invoke necessary operating system (OS) primitives, such as memory allocation, file system and network access. The appeal of vx32/NaCL/WASM lies in its bytecode (or verified x86 asm stream), which cannot operate independently due to its lack of access to syscalls or other inter-process communication (IPC). However, a program without syscall access is essentially futile, limited to using the CPU's arithmetic logic unit, reading/writing memory, and potentially handling input/output buffers. Soon enough, developers will require access to modern amenities offered by OSes such as memory mapping, file descriptors, and async IO. Consequently, OS bridge creators will supply proxies to the kernel, some of which will be improperly implemented. Given their complexity and size, these proxies may essentially become exploitable mini OSes. There's no perfect sandboxing, some forms appear more trustworthy (or more thoroughly scrutinized by researchers) than others. WASM may seem safer than vx32/NaCL because it lacks bytecode verification issues; the bytecode is fully understood, unlike verifying x86 instructions (which are prone to erratas). However, the bridge/glue/proxy/broker problem remains unavoidable.
- kortex 3y ago
  What you are describing is basically WASI [1]. Yes there are exploit concerns in the bridge layer, but it is far easier to sandbox these capabilities-based modules, than native programs. For example, many WASM runtimes are written in Rust, which greatly decreases the risk of exploits in general. 1] https://wasi.dev/ https://wasi.dev/
nerpderp82 3y ago
True! I think it will happen faster and they set the date so far in the future to not encourage a flame war.
hkgjjgjfjfjfjf 3y ago
[dead]
mike_hearn 3y ago
There's some quite different systems programming topics getting conflated here. This assumption that WASM is a competitor to Docker doesn't seem very sensible and it's hard to understand where it comes from. Will Python or Postgres suddenly stop having versioning and installation issues if they run on a WASM interpreter? No, the issues are at the ecosystem level, they're not related to how code is translated for the host CPU. You can optimize the size of your containers to be pretty small, like tens of megabytes… But WebAssembly is, at its core, designed to be more portable than that. You’re talking about tens of kilobytes, instead of tens of megabytes. And the boot-up times can be measured in microseconds, instead of milliseconds, or tens of milliseconds, or even seconds (!) for containers. This paragraph is emblematic: it's mixing up code size, startup time, portability, containers and virtual machines of two different kinds without really linking them together or defining requirements. The thing is, WASM isn't a new idea. The industry has a lot of experience with VMs that JIT compile portable bytecode. Startup time of any WASM program is going to be dominated by the fact that you're in the interpreter the whole time. As programs get larger they do things like load config files, connect to databases, initialize in-memory caches, possibly reflect themselves because that's often convenient, and so on. Because it's all init code none of this is hot, so it gets interpreted and that's slow. WASM offers nothing in the way of a standard library that could be accelerated, so languages have to bring their own which makes things worse. And the WASM environment is extremely minimalist, so you need to ship a lot of code with your app to make things comfortable especially as most servers aren't written in C++ or Rust and aren't going to be any time soon because that's not their sweet spot.
- ilaksh 3y ago
  WASM can be pre-compiled I assume. A basic use case for moving from containers to WASM is to provide the option for custom backend code for users in a more lightweight way. For example, I have a site that allows procedural image generation via an API and I originally built it using containers. It could be much less resource-intensive and faster startup if I could run that code in web assembly. Or, I was building a generative AI site that creates custom web applications. In order to allow backend code, I set it up so everyone gets their own fly.io VM/container(s). This is very flexible but not very fast startup time and the smallest option is like 128MB or 256MB RAM which needs to stay loaded otherwise they will have to wait for another restart. I never really needed to provide arbitrary Linux capabilities, just sandboxed backend code. So if I do something like that again I will try to use web assembly instead. Probably with lightweight TinyGo or Rust-based request handlers or something like that.
tetha 3y ago
Hm. Controversial opinion is a good way to describe it. The thing is: Docker or Podman is just the runtime coordinated and controlled by Kubernetes or Nomad in our case. Nomad practically already supports a hypothetical WASM runtime or offers simple hooks into this: You have e.g. a java driver in Nomad, which downloads a fat jar from an artifact store, cgroups it as far as I know and launches it with one of the available JVMs. There's a bunch of these drivers, even down to IIS pools. Some generic WASM runtime would slot right in there. However, we don't use them. Once you use them, you're again coupling the application runtime to OS updates and management. Staying in the Java example, currently teams are entirely free to use whatever Java version they want. If they want to update multiple times per year to the latest versions - entirely feasible for tight services with low technical debt and good tests - they can do so. As soon as the JVM becomes part of the OS configuration again through the Java driver, us as in infra-ops are immediately blocking all Java updates across the entire infrastructure again. And on top of that, we have a team providing base Java images with a jvm baked in, so most nomad workers pull the JVM layer once after it's released and then the layer is cached locally forever until no application needs it anymore. So it's not much more storage-expensive than putting the JVM on the disk directly. But that's the smaller part of the problem. Nomad isn't just the driver runtime. I can tell Nomad to run 5 instances of an application and to spread them across AWS regions, or VSphere HVs / Racks as well as possible. And Nomad will implement and maintain this, almost regardless of what the infrastructure does. I can drain workers and shift applications around without really knowing them, since this management is configured in the jobs. Again - this decoupling of OS and infrastructure management and application management makes a container orchestration valuable at a larger scale. The runtime below it is an important detail, but it's a detail for average REST service deployments. A WASM runtime may slot in as being faster and more cost efficient or it may not. Who knows.
lyu07282 3y ago
I can see that happening in the future, in a few decades, tiny modular runtimes with low overhead that start in a few milliseconds, probably an entirely new paradigm of backend development to go along with it. Hard to imagine that now of course so everyone will just laugh, just like everyone laughed at docker.
jw1224 3y ago
It makes sense. Why worry about hosting your own server, when you can just execute one locally in the visitor’s browser?
kortex 3y ago
What is the overhead for WASM like, vs bare metal? I know containers generally run as fast as regular processes, but I imagine there is some interpretation overhead for WASM.
- preseinger 3y ago
  containers are FAR slower than regular processes, by almost all performance metrics wasm is orders of magnitude faster -- actually comparable to native execution, at least on the server
  - kortex 3y ago
    No. Only NAT is slower to any real degree. https://stackoverflow.com/a/26149994 https://stackoverflow.com/a/26149994
    - preseinger 3y ago
      your link describes a very narrowly scoped benchmark, not something that is generally applicable
brianolson 3y ago
If that was true we would have already all switched to Java
deleted 3y ago
[deleted]
rowanG077 3y ago
I honestly dread the world if this happens. WebAssembly is dog slow. It essentially means we will set back literally trillions of dollars of hardware improvement.
notorandit 3y ago
Buzzwords all way down!
jonathannorris 3y ago
Owner of the purposefully controversial opinion here :) Looks like its proven to be very controversial, which was the stated goal of the podcast segment :) For context, I had just returned from KubeCon + CloudNativeCon EU in Amsterdam. I had a chance to talk to many of the great folks pushing the WASM ecosystem forward, and there certainly seemed to be a large amount of momentum behind using WASM in the server space and at the edge. I'd had a great time learning from the folks at various open-source projects / companies pushing WASM forward: - https://bytecodealliance.org/ https://bytecodealliance.org/ (shout out to Bailey) - https://cosmonic.com/ https://cosmonic.com/ - https://www.fermyon.com/ https://www.fermyon.com/ - https://wasmcloud.com/ https://wasmcloud.com/ At DevCycle we are using WASM to help share core Feature Flag decisioning code across our Cloudflare Worker APIs and our server SDKs for local decisioning. We've learned a bunch about compatibility / optimizing performance / limitations that I'm happy to chat about in more detail. But we are generally excited for the future of WASM, especially for the new features coming: Component Model / Threading / Garbage Collection changes / Networking. If you are looking for how to use WASM Components to replace container-based runtimes, look at the companies linked above.
colinsane 3y ago
“wasm boots fast, containers boot slow”: as someone who uses neither (unless you count cgroups), i assume there’s a reason that ”classic” containerization is slow? like, your container today provides a complete linux userspace with a filesystem, scheduler, user/permissions enforcement, elf loader/dynamic linker, service manager (systemd/openRC/whatever), maybe a DNS stub resolver, etc — and maybe you don’t actually need half of these? what does using a new bytecode/architecture have to do with optimizing any of this? is it just a sneaky way of swapping out libc and the abstractions beneath it (and if so, why not do just that on “plain” x86_64)?

113 points by ingve 3y ago

Reasons why WASM will not replace containers: - System calls call into the Linux kernel for things like disk and network access. These are highly tested and reliable. To keep WASMs isolation and portability it would need to replace these APIs with new message passing ones which would kill performance. - C FFI - Dynamic libs Being able to integrate with existing C libraries in the way they are intended to be used. - Better VMs/OS level sandboxing MicroVMs like Firecracker that let you run your code unmodified as if it is running directly on the OS. I like WASM, but feel it is over hyped and the alternatives are “good enough” and already widely used. In the browser it is great though.

mikewarot 3y ago

This is highly unlikely in either of the futures I see for WebAssembly: 1 - The best timeline: WebAssembly keeps its strong capabilities based security model, which requires explicit granting of resources to code inside the sandbox. This is great for security, but it requires giving up full access to the file system, and other I/O... which requires rewrites of things. This will, in turn, mean that many workloads won't shift to WebAssembly 2 - The worst timeline: WebAssembly repeats the mistakes of JVM, and eventually succumbs to the demands to allow full access to all of the resources of the host system, defeating capabilities, and making it a new JVM. Thus, it's not as safe as a VM, why would anyone use it? So, most workloads don't shift to WebAssembly. [Edit/Append] WebAssembly uses a capabilities model of security. You have to explicitly give it access to resources from code outside of the sandbox, which are then passed (like file handles) to the code running inside the sandbox. This completely and securely prevents the code inside the sandbox from causing any undesired side effects in your system. Think of it as handing someone $5 cash to make a purchase. You can't lose more than $5, no matter how confused or wrong things go after that point, you've limited the side effects to that $5. Or think of it as plugging in a device to an outlet with a 15 Amp circuit breaker. No matter what you do, you won't draw 100 amps through the outlet, nor take down the grid (like the power in the old TV show Green Acres). This is different than "capabilities" on a smartphone, which are "allow location access" or things like that, global, non-granular access to big chunks of your system. There is no "allow access to your file system?" flag in WebAssembly. In the best timeline, there never will be.

da39a3ee 3y ago
> WebAssembly keeps its strong capabilities based security model, which requires explicit granting of resources to code inside the sandbox. This is great for security, but it requires giving up full access to the file system, and other I/O Can you unpack that a bit for those of us who don't know this area well? Can't "access to filesystem" be one of the capabilities that can be granted or not granted, thus giving no decrease in security because anyone who wishes to host webassembly without granting it is able to do so?

joeyguerra 3y ago

no they won't.

da39a3ee 3y ago

> To get the full experience you should listen while you read. > Click here to listen along while you read. It's better! How could it possibly be better to listen to some people talking thus distracting you while you're reading?

hnaccountme 3y ago

Can we get to a point where we ship binaries NOT source code?

torginus 3y ago

My prediction, is by 2030, a new generation of developers will replace WebAssembly with a brand-new shiny thing that will be clearly superior to what the then-senile and geriatric developers of the clearly-flawed WASM implementation have created, as it will be based on fresh news ideas (tried first in the 1980s). This new thing will address all the shortcomings of WebAssembly, and will be projected to become the standard portable way of running applications by 2040.

o1y32 3y ago

The whole thing feels hallucination from someone who didn't spend enough time with either WebAssembly or containers and simply didn't understand how these things work.

phendrenad2 3y ago

I don't see this catching on when an effectively similar thing (Java app servers) failed to catch on. Containers are just easier.

paulddraper 3y ago

I mean, to state the obvious....no, no they won't.

recursive 3y ago
It's not obvious to everyone. Some of us would need to hear some reasoning before we'd find this line convincing.

SirMaster 3y ago

Does it really make sense to run so much inside a web browser? Are we perhaps over-utilizing web browsers?

adam_arthur 3y ago
WASM is not strictly for the web, its a generic low-level language target/series of specs. The article itself is talking about server runtimes/workloads, nothing to do with browsers. If generic specs can be built around WASM in such a way that you can run code securely without booting an entire OS, WASM will replace traditional containers. Smaller runtime footprint. A consequence of having a generic compile target/spec is that your applications will also be able to run in the browser with minimal effort
- jjtheblunt 3y ago
  > WASM is not strictly for the web, its a generic low-level language target/series of specs. What about it is preferable to MLIR or even LLVM? https://mlir.llvm.org/ https://mlir.llvm.org/
  - adam_arthur 3y ago
    WASM is designed with security in mind, and specifically to provide primitives for use in a secure runtime. LLVM doesn't provide that to my knowledge... instead just cross-compiling code specific to each target. Correct me if mistaken. I imagine there are meaningful build time drawbacks to compiling an executable for each environment as well. While WASM will never outperform native code, it can get very close. Minor loss in performance is a small price to pay for portability/security.
stanleydrew 3y ago
At the risk of taking the bait, I'll point out that WASM doesn't just run in web browsers.
- SirMaster 3y ago

isoprophlex 3y ago

When can I start shoveling my python/pytorch/CUDA spaghetti into WASM? I would like serverless or at least rapid booting GPU functions...

panick21_ 3y ago

I have not listen to this podcast. Given the development speed I'm seeing from Webassembly, I really don't think so. Also it seems to solve a different problem, yes some thing containers are useful for Webassemtly might be really useful for. But a lot of other things I just don't see it. Will I run databases compiled to webassembly? That said I really think Webassembly is cool and like many of the ideas. Will listen to this podcast, lets hope I am convinced. Edit: Good title marketing

aidenn0 3y ago

> 1 tight security model > 2 very fast boot-up time > 3 scalability at the edge > 4 much smaller footprints > 5 portability across environments Aren't #2-4, just wasm rediscovering static linking? 95% of the advantage that docker has over a tarball is due to gcc's (and glibc's) strong bias towards dynamic linking and how hard it is to portably package a python application's dependencies.

recursive 3y ago
Perhaps not coincidentally, #1 and #5 seem like the most significant features from this list.
throwway120385 3y ago
Another often-overlooked advantage of Docker is the fact that its checksummed tarball of your base container image can be shared with other container images. This can cut down on data transfer and data size if you use the same base image for everything because it's only transferring delta images.
- hinkley 3y ago
  Most of our services use the same base image and some of them run in the same host. The main thing to watch out for is that the steady state disk usage is different from the worst case. During upgrades the amount of disk used can balloon up for a little while, and these sorts of transient costs tend to mess with people’s ability to do capacity planning properly. So there’s a law of diminishing returns for pushing things out of your images into a common base. The more you do the larger the over/under gets. Spend a good bit of energy in shrinking the base image, not just growing it, and you’ll be okay.
- strangescript 3y ago
  This doesn't even really apply to wasm though. That is the big difference. You would have a runtime that can execute wasm, and its all the same. Any browser can run wasm provided you don't try unsupported sys-calls.

throwway120385 3y ago

It seems like they're conflating the need to run a specific software stack with the need to do configuration management in general. Configuration management doesn't go away with WebAssembly as they're describing. You're just making fatter statically-linked processes that boil down to interpreters plus source code. People are already statically linking with EG GoLang or .NET Core anyway. So I would guess that the future is static linkage with control groups moreso than it is a specific JavaScript/TypeScript software stack running in a specific runtime. Frankly the way we're shipping dependencies in what are basically checksummed tarball blobs is an echo back to static linkage at a time when most OS platforms have gone very deeply down the dynamic linkage rabbit hole to the degree where everyone is shipping dynamic libs instead of statically linking those libs into their executable. Control Groups are supposed to provide process isolation but are being used to solve this configuration management issue as well because a particular company decided to use chroot in this way.

photonbeam 3y ago
“Namespaces” in linux provide a lot of the isolation that people associate with containers With a mount namespace you can pivot root
no_wizard 3y ago
What company decided to use chroot this way? I'm going to guess its Microsoft, but I think thats not either entirely correct or I'm off base
- ilc 3y ago
  Google is famous for statically linking everything.
  - no_wizard 3y ago
    I don't think its only static linking that is the source of this practice right?
- paulgb 3y ago

Deukhoofd 3y ago

If WASM can overcome the current extremely sluggish development speed, I can definitely see some applications of containerization move to WASM, but I really think like containers and WASM are two very different solutions.

paulgb 3y ago

For some context, this is from an “unpopular opinions” section of the podcast where they specifically ask for a controversial opinion. In the ensuing discussion, the prediction is further qualified: > I’m not gonna say it’s gonna replace every use case; it’s clearly not. But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I do think that if WASI gets sockets and threading soon as planned, it suddenly becomes compelling for a bunch of interesting workloads that containers are used for now.

troupo 3y ago
> But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I fail to see how it's applicable. Unless your entire world is Javascript and its performance
- preseinger 3y ago
  wasm is not bound to javascript in any meaningful sense
  - troupo 3y ago
    wasm literally came out of asm.js and browsers. And its original goal is literally to make stuff in browsers more performant compared to Javascript. So when people say stuff like "high-performance latency-sensitive use cases are applicable to wasm" they clearly only understand performance and latency in comparison to Javascript.
    - preseinger 3y ago
      it started there but that's not like the only goal of the thing and like there's plenty of people doing wasm on the server where performance is measured in microseconds

wrs 3y ago

“So you basically have the full SpiderMonkey runtime running within WebAssembly, running your JavaScript or compiled TypeScript code…” From my old cynical curmudgeon viewpoint, this may be a valid approach, but you need to find a way of saying it that doesn’t sound so ridiculous. A wasm SpiderMonkey runtime running inside a native SpiderMonkey runtime? And presumably the inner runtime supports wasm?

wmf 3y ago
I still don't understand the point of WASM-only runtimes when V8 can run WASM and JS.
- nine_k 3y ago
  A WASM runtime can be dramatically smaller, which may be important in some scenarios. WASM runtimes should grow to a maturity level somehow comparable to V8, JVM, .NET runtimes before they start competing with them. Currently WASM accompanies other software, and I find it pretty correct.
hajile 3y ago
This was predicted a decade ago. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

dragonelite 3y ago

Containers im not so sure but i can see WASM runtimes be integrated into edge functions like services.

nomilk 3y ago

Is it correct that WASM probably won't affect most CRUD apps, since most don't need significant client-side compute or graphics resources? But that WASM might enable intensive applications (e.g. cutting edge games, or 3D rendering software like an architect might use) to run in the browser, rather than on the OS, thus enabling developers of that software to make much more frequent updates (just like any web application)? What would this mean for page load times (e.g. surely not a 700MB program downloading when the user visits a URL..?.. or.. can it?) (apologise for the newbie questions)

paustint 3y ago
WASM is not just a browser technology, it can be (and is heavily) used for edge and servers. I can write code once and run on many runtimes across many different programming languages. I think the server use-cases are actually more compelling than the browser use-cases. For example, Fastly's edge compute supports running WASM code at the edge. Similar to lambda, but in the language of your choice and with great sandboxing qualities baked in.
candiddevmike 3y ago
WASM had some neat/gross implications for blackbox CRUD apps without having to show source. Some people might even start embedding secrets in web source code again!
mike_hearn 3y ago
WASM probably won't affect most websites today, correct. WASM probably won't enable cutting edge games. It has been around for years and there's no interest from the gaming community there, the newest additions to WASM like GC won't affect games much. There are other issues with the web platform that prevent this from working, e.g. the implicitly managed disk cache, the relatively old graphics APIs exposed into the sandbox, the performance impact of sandboxing, and a few other things. The games world has Steam and consoles, that seems to be good enough for them. There might be some attempts to port desktop productivity software to the web using WASM, probably in partnership with Google, like what an architect might use. But probably not. Installing software isn't hard and pro grade software isn't an impulse buy. How much incremental revenue would a web port bring relative to the cost? Probably not much. 700mb programs downloading when a user visits a URL isn't necessarily a problem if that download actually sticks, but see caching issues above. After all, people routinely download programs that large. Chrome itself is ~500mb on disk!

hosh 3y ago

Bold to make a prediction like that. But I think perhaps the author doesn't understand Kubernetes as much -- you can run Webassembly as the runtime for Kubernetes, and get the other things Kubernetes provide, such as self-healing. It's because Kubernetes is not built monolithically, and things like the runtime or kubelet can be replaced with something else. https://developer.okta.com/blog/2022/01/28/webassembly-on-kubernetes-with-rust https://developer.okta.com/blog/2022/01/28/webassembly-on-ku...

theptip 3y ago

> I’m not gonna say it’s gonna replace every use case; it’s clearly not. But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem Behind the clickbait headline, a much narrower and reasonable claim.

jerodsanto 3y ago
This is a phenomenon we see over and over with our "Unpopular Opinions" segment. The summary statement is often unpopular, but once you hear out the person's reasoning (unless it's about food or something purely subjective) most people end up agreeing with them. It's been tough to get _truly_ unpopular opinions (as voted on by Twitter/Mastodon users) represented on the pods.
- mike_hearn 3y ago
  What are some truly unpopular opinions?
secondcoming 3y ago
How big are app downloads going to get!?
- theptip 3y ago
  This article discusses replacing your container/VM backend with a tiny wasm bundle probably run at the edge. The app sees no changes to the API requests it makes.

junon 3y ago

Mmmm don't think so, no. They solve entirely different problems. I also don't think containers will be around in 2030, there will be more fleshed out OS-supplied facilities for general purpose sandboxing I'd think. Title is clickbait anyway, and such blatant and Shameless clickbait at that.

remram 3y ago

Probably not. We have virtual machine runtimes which are more secure and more generic than containers, but we still use containers because they are much more efficient. WebAssembly provides only some of the goodies of VMs while taking away most of the efficiency of containers... they have their use, but I don't see why we expect a runtime to take over the others.

TekMol 3y ago

What does that even mean? When I use a container, I get all the stuff a Debian distro brings: A file system Process management My favorite database (SQLite) My favorite webserver (Apache) My favorite runtime (CPython) A gazillion helpful applications and libraries (Like imagemagick) Tons of convenience glue (like /etc/hosts) I get all of that in a reproducible, isolated little universe. How does a "WebAssembly runtime" provide me with those?

paddw 3y ago
https://wasi.dev/ https://wasi.dev/ allegedly. Development seems slow though.
dboreham 3y ago
Wait until 2030.
preseinger 3y ago
wasm doesn't give you a vm, it gives you a process
- saidinesh5 3y ago
  To be more precise, if you wanted an isolated process, docker already gives you that. Along with the overhead of spinning up a new process for every request you want to handle. What wasm people seem to be interested in is to eliminate the process (and hence a language runtime) spawning overhead, and directly execute the specific function of your application.. "Write your serverless function in any wasm compilable language and our multi tenant runtime can host 1000s of such functions and invoke them without much delay".. Of course, that only makes sense for programs which are written in wasm compilable language. When they do crazy things like running js scripts on top of a quickjs interpreter compiled to wasm to run on top of a wasm interpreter "for portability and safety", it gets weird to see the benefits..
moonchrome 3y ago
By same logic why use containers ? You can just ship VM images. It's basically the same thing as using a language runtime vs using a generic container for Lambda, except WASM would be lower level (you would need to ship language runtime on top of WASM but that's probably order of magnitude less overhead than a container) Containers feel like a clever hack to get existing apps packaged up and reduce the overhead of VMs, but I'd much rather deploy runtime/app code only.

nine_k 3y ago

If you were around ~25 years ago, you likely remember the idea that JVM will run everywhere and replace everything. (And some XML on top.) Indeed, JVM can run everywhere, and has reached far and wide, from SIM cards to huge servers. But it has not replaced all other runtimes, even when it achieved really good GC and and near-native speed thanks to JIT compilation. WASM is very similar to JVM in many regards. It will reach far and wide, it will supplant a few things, but I bet it's not going to replace too many things, let alone native code in containers.

jw1224 3y ago
WASM is a compiler target for countless languages, unlike JVM which is tied to Java. That’s what makes it incomparable to JVM… It’s a global runtime-on-demand for whatever you throw at it.
- o1y32 3y ago
  JVM is not tied to Java. Get basic facts right.
- pjmlp 3y ago
  In relation to JVM true if we ignore the evolution of the ecosystem. Then there are the CLR, IBM TIMI and plenty of other ones all the way back to 1961.
hajile 3y ago
Security and universality are the biggest differences here. WASM was ground-up designed with security in mind (learning from earlier projects like pNaCl). Likewise, WASM was designed with a lot of language targets in mind rather than just Java.
- pjmlp 3y ago
  Sure, if we ignore internal memory corruption inside linear memory. JVM might not be the ideal example of polyglot runtime, yet there are several others of the same vintage, designed with multiple languages in mind, including C and C++, e.g. CLR, TIMI,...

esdott 3y ago

My understanding is that the goal (if not there already) is that you can use wasm tech just like docker/etc. The value prop is wasm would be lighter and have other built in benefits with the adoption of newer browser (security) features like sandboxed file system integration. This would be made available without the overhead of chrome per se. forgive me if I overstate something but this is the gist.

deleted 3y ago

[deleted]

jagrsw 3y ago

While I've only briefly examined the WebAssembly (WASM) security model, it seems like a recurrence of vx32 and NaCL. One inherent issue is the "glue" code enabling the WASM runtime to invoke necessary operating system (OS) primitives, such as memory allocation, file system and network access. The appeal of vx32/NaCL/WASM lies in its bytecode (or verified x86 asm stream), which cannot operate independently due to its lack of access to syscalls or other inter-process communication (IPC). However, a program without syscall access is essentially futile, limited to using the CPU's arithmetic logic unit, reading/writing memory, and potentially handling input/output buffers. Soon enough, developers will require access to modern amenities offered by OSes such as memory mapping, file descriptors, and async IO. Consequently, OS bridge creators will supply proxies to the kernel, some of which will be improperly implemented. Given their complexity and size, these proxies may essentially become exploitable mini OSes. There's no perfect sandboxing, some forms appear more trustworthy (or more thoroughly scrutinized by researchers) than others. WASM may seem safer than vx32/NaCL because it lacks bytecode verification issues; the bytecode is fully understood, unlike verifying x86 instructions (which are prone to erratas). However, the bridge/glue/proxy/broker problem remains unavoidable.

kortex 3y ago
What you are describing is basically WASI [1]. Yes there are exploit concerns in the bridge layer, but it is far easier to sandbox these capabilities-based modules, than native programs. For example, many WASM runtimes are written in Rust, which greatly decreases the risk of exploits in general. 1] https://wasi.dev/ https://wasi.dev/

nerpderp82 3y ago

True! I think it will happen faster and they set the date so far in the future to not encourage a flame war.

hkgjjgjfjfjfjf 3y ago

[dead]

mike_hearn 3y ago

There's some quite different systems programming topics getting conflated here. This assumption that WASM is a competitor to Docker doesn't seem very sensible and it's hard to understand where it comes from. Will Python or Postgres suddenly stop having versioning and installation issues if they run on a WASM interpreter? No, the issues are at the ecosystem level, they're not related to how code is translated for the host CPU. You can optimize the size of your containers to be pretty small, like tens of megabytes… But WebAssembly is, at its core, designed to be more portable than that. You’re talking about tens of kilobytes, instead of tens of megabytes. And the boot-up times can be measured in microseconds, instead of milliseconds, or tens of milliseconds, or even seconds (!) for containers. This paragraph is emblematic: it's mixing up code size, startup time, portability, containers and virtual machines of two different kinds without really linking them together or defining requirements. The thing is, WASM isn't a new idea. The industry has a lot of experience with VMs that JIT compile portable bytecode. Startup time of any WASM program is going to be dominated by the fact that you're in the interpreter the whole time. As programs get larger they do things like load config files, connect to databases, initialize in-memory caches, possibly reflect themselves because that's often convenient, and so on. Because it's all init code none of this is hot, so it gets interpreted and that's slow. WASM offers nothing in the way of a standard library that could be accelerated, so languages have to bring their own which makes things worse. And the WASM environment is extremely minimalist, so you need to ship a lot of code with your app to make things comfortable especially as most servers aren't written in C++ or Rust and aren't going to be any time soon because that's not their sweet spot.

ilaksh 3y ago
WASM can be pre-compiled I assume. A basic use case for moving from containers to WASM is to provide the option for custom backend code for users in a more lightweight way. For example, I have a site that allows procedural image generation via an API and I originally built it using containers. It could be much less resource-intensive and faster startup if I could run that code in web assembly. Or, I was building a generative AI site that creates custom web applications. In order to allow backend code, I set it up so everyone gets their own fly.io VM/container(s). This is very flexible but not very fast startup time and the smallest option is like 128MB or 256MB RAM which needs to stay loaded otherwise they will have to wait for another restart. I never really needed to provide arbitrary Linux capabilities, just sandboxed backend code. So if I do something like that again I will try to use web assembly instead. Probably with lightweight TinyGo or Rust-based request handlers or something like that.

tetha 3y ago

Hm. Controversial opinion is a good way to describe it. The thing is: Docker or Podman is just the runtime coordinated and controlled by Kubernetes or Nomad in our case. Nomad practically already supports a hypothetical WASM runtime or offers simple hooks into this: You have e.g. a java driver in Nomad, which downloads a fat jar from an artifact store, cgroups it as far as I know and launches it with one of the available JVMs. There's a bunch of these drivers, even down to IIS pools. Some generic WASM runtime would slot right in there. However, we don't use them. Once you use them, you're again coupling the application runtime to OS updates and management. Staying in the Java example, currently teams are entirely free to use whatever Java version they want. If they want to update multiple times per year to the latest versions - entirely feasible for tight services with low technical debt and good tests - they can do so. As soon as the JVM becomes part of the OS configuration again through the Java driver, us as in infra-ops are immediately blocking all Java updates across the entire infrastructure again. And on top of that, we have a team providing base Java images with a jvm baked in, so most nomad workers pull the JVM layer once after it's released and then the layer is cached locally forever until no application needs it anymore. So it's not much more storage-expensive than putting the JVM on the disk directly. But that's the smaller part of the problem. Nomad isn't just the driver runtime. I can tell Nomad to run 5 instances of an application and to spread them across AWS regions, or VSphere HVs / Racks as well as possible. And Nomad will implement and maintain this, almost regardless of what the infrastructure does. I can drain workers and shift applications around without really knowing them, since this management is configured in the jobs. Again - this decoupling of OS and infrastructure management and application management makes a container orchestration valuable at a larger scale. The runtime below it is an important detail, but it's a detail for average REST service deployments. A WASM runtime may slot in as being faster and more cost efficient or it may not. Who knows.

lyu07282 3y ago

I can see that happening in the future, in a few decades, tiny modular runtimes with low overhead that start in a few milliseconds, probably an entirely new paradigm of backend development to go along with it. Hard to imagine that now of course so everyone will just laugh, just like everyone laughed at docker.

jw1224 3y ago

It makes sense. Why worry about hosting your own server, when you can just execute one locally in the visitor’s browser?

kortex 3y ago

What is the overhead for WASM like, vs bare metal? I know containers generally run as fast as regular processes, but I imagine there is some interpretation overhead for WASM.

preseinger 3y ago
containers are FAR slower than regular processes, by almost all performance metrics wasm is orders of magnitude faster -- actually comparable to native execution, at least on the server
- kortex 3y ago
  No. Only NAT is slower to any real degree. https://stackoverflow.com/a/26149994 https://stackoverflow.com/a/26149994
  - preseinger 3y ago
    your link describes a very narrowly scoped benchmark, not something that is generally applicable

brianolson 3y ago

If that was true we would have already all switched to Java

deleted 3y ago

[deleted]

rowanG077 3y ago

I honestly dread the world if this happens. WebAssembly is dog slow. It essentially means we will set back literally trillions of dollars of hardware improvement.

notorandit 3y ago

Buzzwords all way down!

jonathannorris 3y ago

Owner of the purposefully controversial opinion here :) Looks like its proven to be very controversial, which was the stated goal of the podcast segment :) For context, I had just returned from KubeCon + CloudNativeCon EU in Amsterdam. I had a chance to talk to many of the great folks pushing the WASM ecosystem forward, and there certainly seemed to be a large amount of momentum behind using WASM in the server space and at the edge. I'd had a great time learning from the folks at various open-source projects / companies pushing WASM forward: - https://bytecodealliance.org/ https://bytecodealliance.org/ (shout out to Bailey) - https://cosmonic.com/ https://cosmonic.com/ - https://www.fermyon.com/ https://www.fermyon.com/ - https://wasmcloud.com/ https://wasmcloud.com/ At DevCycle we are using WASM to help share core Feature Flag decisioning code across our Cloudflare Worker APIs and our server SDKs for local decisioning. We've learned a bunch about compatibility / optimizing performance / limitations that I'm happy to chat about in more detail. But we are generally excited for the future of WASM, especially for the new features coming: Component Model / Threading / Garbage Collection changes / Networking. If you are looking for how to use WASM Components to replace container-based runtimes, look at the companies linked above.

colinsane 3y ago

“wasm boots fast, containers boot slow”: as someone who uses neither (unless you count cgroups), i assume there’s a reason that ”classic” containerization is slow? like, your container today provides a complete linux userspace with a filesystem, scheduler, user/permissions enforcement, elf loader/dynamic linker, service manager (systemd/openRC/whatever), maybe a DNS stub resolver, etc — and maybe you don’t actually need half of these? what does using a new bytecode/architecture have to do with optimizing any of this? is it just a sneaky way of swapping out libc and the abstractions beneath it (and if so, why not do just that on “plain” x86_64)?