I agree that some things are essential, and there&#x27;s value in specifications. The question is how likely is the current tragectory to follow what happened with browsers? The major players are the same, which is concerning. Then there&#x27;s early signs from the specs themselves. Why do we need wasi-sockets and wasi-http? Why not only specify wasi-sockets and let HTTP be implemented optionally by libraries for apps that need it?Are there any forces in place to prevent the (de facto) mandatory API from becoming so complex that Google (or Fastly) is the only org capable of maintaining an implementation? Because that&#x27;s how you end up in the situation where the &quot;user agent&quot; with majority market share starts gutting ad blockers.I&#x27;m not saying I&#x27;m predicating this will happen with WASM or even think it&#x27;s very likely. I don&#x27;t know enough to have a real opinion on that. I&#x27;m just saying I really really don&#x27;t want it to happen.

&gt; A standard instruction set, standard calling convention, and standard syscalls.This sounds like an OS like user space to run atop WASM similar to POSIX.Standards are good but my hope is the design is well thought out.

I agree about what your concerns about complexity, but the way I see what we&#x27;re
encapsulating is almost entirely essential. To draw analogies with native binaries:- Wasm is a (virtual) instruction format for programs to be compiled into (think: x86).- Wasm Components are a container format and type system that wrap Core Wasm instructions into typed, hermetic binaries and libraries (think: ELF).- WASI is a reserved namespace for a collection of standardized Wasm component interfaces (think: POSIX header files).To reach our goal of having shared, portable binaries that aren&#x27;t locked into
any one vendor we need all three. A standard instruction set, standard calling
convention, and standard syscalls. Wasm Components and WASI might not be
necessarily be perfect, but at a minimum they&#x27;re targeting the right scope. And that carries essential complexity.

Thank you for Exstism. My main request is that you keep the core interface as simple and forkable as is feasible. You&#x27;re certainly incentivized to make it as complicated as possible so only your team can maintain it, but I hope you&#x27;re able to find a sustainable business model that doesn&#x27;t go down that path.

One of the maintainers of Extism here! Thank you for the kind words.As you know, we&#x27;re all about delivering value with the actual standards today. This means using truly portable, w3c Wasm core modules. Not some &quot;maybe in the future&quot; standard a la Components.If you realistically want to use Wasm everywhere, in practically every language, Extism is the way to go and we&#x27;re in it for the long haul.For those who appreciate the WIT IDL being worked on (now for way too long), we support a far simpler, more familiar OpenAPI based version to eliminate the boilerplate of type conversion &amp; serialization across the guest-host boundary, worth checking out: <a href="https:&#x2F;&#x2F;github.com&#x2F;dylibso&#x2F;xtp-bindgen" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dylibso&#x2F;xtp-bindgen</a>

Roughly the same reason as every time someone asks the same question in any post that mentions WASM: Java is a particular model with a particular view of the world, tied to a GC and a particular standard library and various hard limitations such as no user-defined value types that make it impossible to compile C code to properly and run it with reasonably C-like speed. Just because Java has incorporated dozens of &#x27;advances&#x27; doesn&#x27;t mean any of them address its longstanding problems, and you&#x27;re mixing implementation tech with spec design in your reasoning. You, in your daily life, likely use zero software incorporating Java and multiple pieces of software incorporating WASM. You cannot imagine using Java for shaping functions embedded in font files, or sandboxed &#x27;native&#x27; modules in a JS-based text editor, or blockchain smart contracts. In fact Java basically cannot be reliably sandboxed at all.

Because WASM is currently solving a real problem for me that Java can&#x27;t solve, ie easily embedding code I wrote in one language into many other languages. You can do something similar with shared libraries, but you have to compile them for every architecture and OS and solve the associated distribution problems. Ask Python and JS how that works out in practice. A WASM artifact runs everywhere, and has addition security benefits.

I&#x27;d love to hear why WASM now has more promise than Java 1.x.Java&#x27;s subsequent development was driven by enterprise&#x2F;containers (mainly Oracle), and the VM has stayed relevant for 30 years by incorporating dozens of advances in machine and programming models. Both successful and lamentable.If WASM (i.e., the loose collection of organizations driving it) could do it better than Java, wouldn&#x27;t Java (with all its resources and organization) have already done it?The answer has to lie in unsustainable or limiting technical decisions. What exactly are the design decisions WASM made to make it seem like it would escape becoming Java-like?

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.

When you jump into every WASM thread with this take, what are you trying to accomplish?

It will be re-inventing the whole application containers ecosystems we had back a few decades ago across JVM and CLR ecosystems.

I started using WebAssembly in earnest a few months ago to make a backend auth library that works in several different languages[0]. It&#x27;s built on Extism[1], which abstracts away some of the interfacing complexity. It&#x27;s been an awesome experience. Frequently feels like magic.WASM is in an interesting place. The value has clearly been proved with a pretty minimal core spec. Now there&#x27;s a big push to implement a much larger API surface for WASI and the Component Model. A lot of people in the community are concerned about this direction, or at least the way it&#x27;s happening[2].For my part, I hope WASM doesn&#x27;t go the way of the rest of web browsers where it gets so complicated that only big tech is capable of making implementations and experimenting.[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;lastlogin-net&#x2F;decent-auth" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lastlogin-net&#x2F;decent-auth</a>[1]: <a href="https:&#x2F;&#x2F;extism.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;extism.org&#x2F;</a>[2]: <a href="https:&#x2F;&#x2F;www.assemblyscript.org&#x2F;standards-objections.html" rel="nofollow">https:&#x2F;&#x2F;www.assemblyscript.org&#x2F;standards-objections.html</a>

Though both share the ability so securely execute multi-tenant workloads, but they make very different tradeoffs when it comes to compatibility vs performance. To compare:Firecracker is great if you want to securely execute an OS image. It has the benefit of compatibility with many existing programs, but that comes at the cost of some overhead.Hyperlight is great if you want to securely execute program runtimes. This requires bespoke guest bindings, but it has the benefit of having less overhead.There’s a place for both approaches, and I see both happily co-exist.

From what I understand Hyperlight&#x27;s boot process is more similar to a microcontroller than a PC (although it use your CPU architecture) - the VM directly boot into your code. Unlike Firecracker, Hyperlight VM doesn&#x27;t have any hardware while Firecracker do have VirtIO devices, serial console and keyboard so that traditional operating systems can be adapted to Firecracker. Host-Guest communication is done with shared memory.

So is Hyperlight a competitor to things like Firecracker or does it serve a different niche?

It depends on how which performance metrics you&#x27;re interested in, where you draw the boundaries for individual workloads, and how you then schedule those workloads. Hyperlight can start new Wasm workloads so quickly that you might not need to keep any idling instances around (&quot;scale to zero&quot;). That&#x27;s new, and it makes comparisons a little more complicated. For example:- If we take VMs as our boundary and compare cold start times, Hyperlight confidently comes out on top. That&#x27;s 1-2ms vs 125ms+.- If we take warm instances and measure network latency for requests, Hyperlight will come out on top if deployed to a CDN node (physics!). But if both workloads run in the same data center performance will be a lot closer.- Say we have a workload where we need to transmux a terabyte of video, and we care about doing that as quickly as possible. A native binary has access to native instructions that will almost certainly outperform pure-Wasm workloads.I think about Hyperlight Wasm is as yet another tool in the toolbox. There are some things it&#x27;s great at (cold-starts, portability, security) and some other things it isn&#x27;t. At least, not yet. Whether it&#x27;s a good fit for what you&#x27;re doing will depend on what you&#x27;re doing.

How does performance compare to running native code?

A couple of months ago we announced Hyperlight [1], a lightweight VMM that can spawn new VMs in about a millisecond.Today we’re happy to announce the Hyperlight Wasm guest based on the Wasmtime runtime. This makes it possible to run Wasm Component binaries on top of WASI interfaces without the need for a guest OS in the VM. In this post we explain how this works and walk through an example.[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42078476">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42078476</a>

WASM Components are supposed to be memory safe, even in-process. Besides, you can compile from a memory-safe source language to WASM.

Why is &#x27;more memory safe than just having the application running in a separate process&#x27; the benchmark? Literally nothing can clear that bar. It is more memory safe than most existing VM languages, which is all anyone actually cares about.

You are spot on. I was loose with my terms. I was thinking safe in the concept of sandboxing the host, but you are spot on, it isn&#x27;t memory safe.

WASM isn&#x27;t memory-safe through (no more than just having the application running in a separate process) because it doesn&#x27;t type tag the memory. JVM was safe but that&#x27;s also a serious disadvantage, because it bakes type system into the runtime system.

I&#x27;m really excite about this! I&#x27;ve got hopes that WASM&#x2F;WASI will grow into the dream of the JVM from the 90s. A memory-safe target for development that allows easy of porting and testing across multiple platforms. WASM can, and hopefully will, be for so much more than browsers.

That’s the idea! This is at the heart of our upcoming Azure Front Door Edge Actions platform. Our CTO Mark Russinovich talked more about this at Ignite last fall:<a href="https:&#x2F;&#x2F;youtu.be&#x2F;EYCA0cR1dkI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;EYCA0cR1dkI</a>

You pretty much get deployability of docker with a size of npm package. In theory

This seems interesting. So the use case of this would be if you wanted to role your own Cloudflare Workers or Lambda equivalent with WASM?

A Wasm component running inside of Wasmtime is just fine. However, when you start to use resources from outside of Wasm, e.g. systems, network interfaces, GPUs, etc., Wasmtime uses OS resources from the host that it is running upon. If this host is running on your trusted compute base, then it implies you are trusting the host implementations in Wasmtime, which for some is just fine. However, Hyperlight-Wasm gives platform builders the ability to describe the interface between the guest and the host explicitly, so you could only expose the host functionality you would want with the trusted implementation you&#x27;d want. For example, if I&#x27;m building a FaaS, I may want to provide only an exported event handler and an imported key&#x2F;value interface to the guest for which I&#x27;ve built a safe, multi-tenant implementation and strictly disallow all other host provided functionality.

Good question. I think it’s the additional security? From [1]:&gt; Hyperlight is able to create new VMs in one to two milliseconds. While this is still slower than using sandboxed runtimes like V8 or Wasmtime directly, with Hyperlight we can take those same runtimes and place them inside of a VM that provides additional protection in the event of a sandbox escape.[1]: <a href="https:&#x2F;&#x2F;opensource.microsoft.com&#x2F;blog&#x2F;2024&#x2F;11&#x2F;07&#x2F;introducing-hyperlight-virtual-machine-based-security-for-functions-at-scale&#x2F;" rel="nofollow">https:&#x2F;&#x2F;opensource.microsoft.com&#x2F;blog&#x2F;2024&#x2F;11&#x2F;07&#x2F;introducing...</a>

I think they skipped the middlemam and run wasmtime under hypervisor without linux inbetween

It&#x27;s the same reasoning that leads people to move things from running in an OS process to running in a VM. In theory, it adds security and better isolation. Hyperlight appears to substantially reduce the overhead of running VMs which makes it more appealing as a target if this fits your needs and you want the isolation of VMs.

Cool. Trying to understand the value-add here, how does this differ from executing via wasmtime?

That reminds me of the time when Java applets had their high time.I think that WASM in the browser will either largely replace JavaScript or will wither away like Java applets did. I fear there is no in-between and if it is only because no one will support two languages and ecosystems in parallel and in the long run. Not the big companies and certainly not the small ones.

I suspect that Wasm on the web mostly just works and so we don&#x27;t hear too much
about it. It is occasionally mentioned in passing though, usually as part of
another announcement. Well-known production users of Wasm on the web include
Dropbox [1], Adobe [2], Figma [3], and 1Password [4].[1]: <a href="https:&#x2F;&#x2F;dropbox.tech&#x2F;tech&#x2F;2018&#x2F;06&#x2F;building-better-compression-together-with-divans" rel="nofollow">https:&#x2F;&#x2F;dropbox.tech&#x2F;tech&#x2F;2018&#x2F;06&#x2F;building-better-compressio...</a>[2]: <a href="https:&#x2F;&#x2F;thenewstack.io&#x2F;adobe-developers-use-webassembly-to-improve-users-lives" rel="nofollow">https:&#x2F;&#x2F;thenewstack.io&#x2F;adobe-developers-use-webassembly-to-i...</a>[3]: <a href="https:&#x2F;&#x2F;www.figma.com&#x2F;blog&#x2F;webassembly-cut-figmas-load-time-by-3x" rel="nofollow">https:&#x2F;&#x2F;www.figma.com&#x2F;blog&#x2F;webassembly-cut-figmas-load-time-...</a>[4]: <a href="https:&#x2F;&#x2F;blog.1password.com&#x2F;passkey-crates" rel="nofollow">https:&#x2F;&#x2F;blog.1password.com&#x2F;passkey-crates</a>

That is not the world I see. Where is WASM in the browser really used apart from crypto miners?The world I see is one where WASM is a permanent second class citizen and probably already has reached its peak adoption.Not that I hope for it, quite the contrary, but that is what it looks to me.EDIT: crypto miners and fancy tech demos I should say

WASM is widely used and very successful in the browser.

All these cool and interesting projects make me think that WASM is successful everywhere except the browser.Maybe we should drop the Web from Web Assembly and call it something else?

(looks at laptop running a Node app hosted in minikube running on Podman in WSL2 in Windows) of course. easy peasy

Any ideas on how one might cram this into a promox setup for testing purposes?As I understand it this is designed to sit on bare metal and this is all a bit hamfisted but I don’t have a spare bare metal x86 around.Guessing just throw this into a vm and accept that it’s nested virt?

Thank you for the illuminating references! So this sockets example is a host that runs on a raw vm (x86_64-unknown-none target) and spawns sandboxes. To get at my original idea, I could imagine a sandbox with special functions imported from the host that can spawn new sandboxes. This could be complicated by the fact that spawning these sandboxes and hooking up inputs&#x2F;outputs seems to be statically compiled...I wondered how components were supposed to be used. So wac takes a group of wasm components and merges them into a new .wasm file with inputs&#x2F;outputs mapped according to a defined .wac file. Then you can just run the new .wasm file. Does this not obviate the isolation benefits of having separate wasm modules? Is there a path to running a tree of components directly while maintaining the sandbox between them?

This example (<a href="https:&#x2F;&#x2F;github.com&#x2F;hyperlight-dev&#x2F;hyperlight-wasm-sockets-example&#x2F;blob&#x2F;de8d0692b1073dbe6951054b09f37a7dd46c649e&#x2F;src&#x2F;main.rs#L73-L101" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hyperlight-dev&#x2F;hyperlight-wasm-sockets-ex...</a>) demonstrates starting a sandbox and loading a component. You could imagine you&#x27;d write an app that starts and stops any number of components in their own sandboxes.As for executing a tree of connected components, in the current state of Hyperlight-Wasm you&#x27;d probably want to take a collection of components and compose them together using something like <a href="https:&#x2F;&#x2F;github.com&#x2F;bytecodealliance&#x2F;wac" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bytecodealliance&#x2F;wac</a> to create a final component composed together from multiple components.

How are instances started and managed? Via some API?Can you give a Wasm Component binary the capability to execute a tree of connected Wasm Components, delegate capabilities, and manage their life cycle?

The reason processes aren&#x27;t enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge subsystems, exposing significant kernel surface area that&#x27;s susceptible to exploits when kernel bugs are discovered.The WASM ecosystem is recapitulating this stage of affairs by increasing the surface area with external systems in the same fashion.Unix processes combined with seccomp (or pledge) to reduce exposed kernel surface and landlock (or unveil) to limit filesystem access puts you back at square one. Processes running WASM interpreters should be leveraging those interfaces, anyhow. What really differentiates WASM is the &quot;compile once, run anywhere&quot; portability allure.But we live in an age of open source (in the literal sense). Ecosystems like Go and Rust assume source code availability; binary blobs are the exception. There&#x27;s not much of a difference between C, Go, or Rust textual source code on the one hand and a WASM binary on the other; both are going to be compiled to native code by the downstream user. When you have the source code available to compile, then standards like POSIX should suffice. But they don&#x27;t (at least not completely), because people are always chasing newer features that various environments invent to differentiate themselves. I don&#x27;t see how WASM resolves that fundamental dynamic. Though I don&#x27;t deny there are marginal benefits, just like there were with the JVM, which in many niches effectively resolved the Unix&#x2F;Windows portability issue, allowing people to migrate platforms easier as preferences and requirements change.

Right but the course of action should be to add on to them, not invent entirely new stacks.

Unfortunately Unix processes aren&#x27;t up to snuff, hence we introduced a bunch of dubious add-ons. Recently HN had a post on seL4; microkernels and capabilities were brought up. But of course backwards compatibility is tough...

That won&#x27;t sell startup ideas reinventing the application servers ecosystem.Instead of WebSphere, WebLogic, IIS et al, you get Hyperlight WASM, with WASI components (aka CORBA&#x2F;DCOM).

So essentially we have a VM (wasm) meant to sandbox programs running in a hardware VM meant to sandbox programs running in a user space process (Linux process) which is an abstraction meant to isolate programs.Have we ever thought of .... Using Unix processes for what they were meant to do, which is .. isolate programs?

There are definitely some similarities. I think the main difference is the compatibility of Wasm &#x2F; WASI. Often for unikernel &#x2F; libOS, you would need to recompile applications to target the specific unikernel &#x2F; libOS. The goal is that you should be able to take a component that you would run with Wasmtime or other component model compatible runtime and be able to run that on Hyperlight-Wasm.

Since Wasmtime can run programs built for Wasm GC, I&#x27;m curious if this can as well. Would be neat if so.

Hyperlight WASM: Fast, secure, and OS-free