[HN Gopher] Hyperlight WASM: Fast, secure, and OS-free
___________________________________________________________________
Hyperlight WASM: Fast, secure, and OS-free
Author : yoshuaw
Score : 192 points
Date : 2025-03-26 14:18 UTC (8 hours ago)
(HTM) web link (opensource.microsoft.com)
(TXT) w3m dump (opensource.microsoft.com)
| yoshuaw wrote:
| 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]: https://news.ycombinator.com/item?id=42078476
| dochtman wrote:
| How does performance compare to running native code?
| yoshuaw wrote:
| It depends on how which performance metrics you'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 ("scale to zero"). That'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'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's great at (cold-starts,
| portability, security) and some other things it isn't. At
| least, not yet. Whether it's a good fit for what you're doing
| will depend on what you're doing.
| ThePhysicist wrote:
| So is Hyperlight a competitor to things like Firecracker or
| does it serve a different niche?
| whs wrote:
| From what I understand Hyperlight'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'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.
| yoshuaw wrote:
| 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.
| ecshafer wrote:
| 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?
| yoshuaw wrote:
| 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:
|
| https://youtu.be/EYCA0cR1dkI
| Muromec wrote:
| You pretty much get deployability of docker with a size of npm
| package. In theory
| Havoc wrote:
| 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?
| amne wrote:
| (looks at laptop running a Node app hosted in minikube running
| on Podman in WSL2 in Windows) of course. easy peasy
| dakom wrote:
| Cool. Trying to understand the value-add here, how does this
| differ from executing via wasmtime?
| Muromec wrote:
| I think they skipped the middlemam and run wasmtime under
| hypervisor without linux inbetween
| huijzer wrote:
| Good question. I think it's the additional security? From [1]:
|
| > 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]:
| https://opensource.microsoft.com/blog/2024/11/07/introducing...
| Jtsummers wrote:
| It'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.
| algorithmmonkey wrote:
| 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'd want. For example, if I'm building a FaaS,
| I may want to provide only an exported event handler and an
| imported key/value interface to the guest for which I've built
| a safe, multi-tenant implementation and strictly disallow all
| other host provided functionality.
| anon291 wrote:
| 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?
| vacuity wrote:
| Unfortunately Unix processes aren'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...
| anon291 wrote:
| Right but the course of action should be to add on to them,
| not invent entirely new stacks.
| wahern wrote:
| The reason processes aren'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'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
| "compile once, run anywhere" 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'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't (at least not
| completely), because people are always chasing newer features
| that various environments invent to differentiate themselves.
| I don't see how WASM resolves that fundamental dynamic.
| Though I don't deny there are marginal benefits, just like
| there were with the JVM, which in many niches effectively
| resolved the Unix/Windows portability issue, allowing people
| to migrate platforms easier as preferences and requirements
| change.
| pjmlp wrote:
| That won'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/DCOM).
| weinzierl wrote:
| 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?
| apitman wrote:
| WASM is widely used and very successful in the browser.
| weinzierl wrote:
| 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
| rstat1 wrote:
| >>Where is WASM in the browser really used apart from
| crypto miners?
|
| Amazon's Twitch service (and by extension also AWS's
| Interactive Video Service product that uses all the same
| backend stuff). Their video player is either fully a WASM
| thing or has some WASM components, I'm not completely sure
| which.
| weinzierl wrote:
| _" has some WASM components"_
|
| See, that's the problem. As long as WASM is not able to
| pull its own weight and needs JavaScript to provide the
| spine it will languish in a niche or two. Ultimately
| someone will decide that supporting two different
| languages and ecosystems is too expensive and not worth
| the marginal advantage and it will go back to JavaScript
| only.
|
| We've been there and we have done that with Java applets.
| tadfisher wrote:
| The ease of interoperation with the host language (JS in
| this case) is a benefit, not a problem. WASM (without the
| WASI stuff) is fundamentally a portable assembler target,
| something that other languages can target, and all the
| baggage of browser and OS APIs can stay in the host
| environment and be selectively exposed to the WASM
| runtime. This makes WASM truly portable (again, without
| the WASI stuff).
| postalrat wrote:
| Come up with great interface for web apps in WASM and the
| world will follow. Eventually browsers can just implement
| your interface directly without the javascript glue.
| apitman wrote:
| Oh are you referring more to browser vendor support for
| WASM, such as adding better APIs for interfacing, etc?
| There I completely agree with you.
|
| I though you meant it isn't used by web developers, which
| it very much is.
| manveru wrote:
| A place I recently saw it was in the web editor for typst.
| It runs the same code as the CLI since it's compiled from
| rust for both targets.
| azakai wrote:
| > Where is WASM in the browser really used apart from
| crypto miners?
|
| Art and design: Photoshop, Figma
|
| Games: Unity, many other engines or components inside
| engines (e.g. Bullet)
|
| Videoconferencing: Zoom, Google Meet, etc.
|
| Productivity: Google Sheets
|
| Other: Google Maps and many, many more. For example, here
| is a talk about how Google uses wasm in a large range of
| its products: https://www.youtube.com/watch?v=2En8cj6xlv4
|
| Look, wasm is a supplementary technology, used where
| JavaScript isn't good enough, like all the examples I just
| gave. Those use cases work extremely well right now, and
| most users on the web benefit from wasm, even if they are
| unaware wasm is running on the page - which is how it
| should be.
|
| That is exactly the success that wasm aimed for from the
| start.
| weinzierl wrote:
| People have made that same argument about Java applets 25
| years ago and we all know how that panned out.
|
| I see your point and I see and love the advantages of
| WASM but I doubt they will be enough to outweigh the
| burden to support two ecosystems in the long run. Support
| in the browser, as well as on the development side.
|
| _" That is exactly the success that wasm aimed for from
| the start."_
|
| If this is true WASM has been doomed from the start. If
| WASM doesn't set out to eat JavaScript's cake it will be
| left with the crumbs and slowly but surely starve to
| death.
| azakai wrote:
| The difference with Java applets from back then is that
| wasm was designed by web browsers in order to work well
| in them.
|
| Java applets were plugins, which led to security issues,
| and worse, security issues not under the control of the
| browser. Wasm is a proper part of the browser.
|
| Java applets had limited interop with JavaScript and
| HTML. Wasm is also somewhat limited there, but it was
| designed to at least have fast calls to JavaScript
| itself.
|
| Java also has language-specific issues. Most native code
| that people want to run on the web is not written in Java
| or another JVM language. Wasm was designed to support
| compilation from C++, Rust, etc. (and it has recently
| added Java support too).
| colonial wrote:
| WASM is also great for enabling web apps to locally
| perform tasks that would be compute/bandwidth intensive
| if foisted upon the server.
|
| E.x. the Cobalt video downloader has an experimental on-
| device video remuxing feature that uses FFmpeg (libav)
| compiled to WASM. It's a win-win for both the provider
| (who saves on hosting and bandwidth fees) and the user
| (who enjoys snappier functionality and enhanced privacy
| guarantees.)
| yoshuaw wrote:
| I suspect that Wasm on the web mostly just works and so we
| don'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]: https://dropbox.tech/tech/2018/06/building-better-
| compressio...
|
| [2]: https://thenewstack.io/adobe-developers-use-webassembly-
| to-i...
|
| [3]: https://www.figma.com/blog/webassembly-cut-figmas-load-
| time-...
|
| [4]: https://blog.1password.com/passkey-crates
| weinzierl wrote:
| 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.
| azakai wrote:
| There is an in-between, which is the world we live in right
| now.
|
| JavaScript and TypeScript are great languages with
| excellent Web integration, whereas wasm is focused on pure
| computation (forcing it to bundle its standard library, for
| example). But wasm has predictable performance that is
| close to native builds, and sometimes you need that.
|
| Very few web pages use only wasm. Most uses of wasm on the
| wasm are as part of a JavaScript site, for the parts where
| wasm makes sense.
| weinzierl wrote:
| I'd bet the current state is not sustainable and we will
| see a consolidation one way or another.
|
| The danger for WASM is that JavaScript doesn't stand
| still either and we might as well see improvements that
| make the gap to WASM's selling points smaller.
| temp0826 wrote:
| So a unikernel/library os?
| algorithmmonkey wrote:
| There are definitely some similarities. I think the main
| difference is the compatibility of Wasm / WASI. Often for
| unikernel / libOS, you would need to recompile applications to
| target the specific unikernel / 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.
| infogulch wrote:
| 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?
| algorithmmonkey wrote:
| This example (https://github.com/hyperlight-dev/hyperlight-
| wasm-sockets-ex...) demonstrates starting a sandbox and loading
| a component. You could imagine you'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'd probably want to take a
| collection of components and compose them together using
| something like https://github.com/bytecodealliance/wac to
| create a final component composed together from multiple
| components.
| infogulch wrote:
| 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/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/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?
| stusmall wrote:
| I'm really excite about this! I've got hopes that WASM/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.
| tliltocatl wrote:
| WASM isn't memory-safe through (no more than just having the
| application running in a separate process) because it doesn't
| type tag the memory. JVM was safe but that's also a serious
| disadvantage, because it bakes type system into the runtime
| system.
| zozbot234 wrote:
| WASM Components are supposed to be memory safe, even in-
| process. Besides, you can compile from a memory-safe source
| language to WASM.
| pie_flavor wrote:
| Why is 'more memory safe than just having the application
| running in a separate process' 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.
| tliltocatl wrote:
| > Literally nothing can clear that bar.
|
| That's just not true. Every language that doesn't allow
| casting pointers to integers (that is, JVM, Javascript,
| Python and literally everything but C/C++) is more memory-
| safe that WASM. Yes, performance on these more or less
| sucks. But what I'm trying to tell, the only advantage WASM
| has over native code is portability, it's no more safe than
| native code, most interpreted languages (where
| "interpreted" includes bytecode and JIT) are safer.
| apitman wrote:
| I started using WebAssembly in earnest a few months ago to make a
| backend auth library that works in several different
| languages[0]. It's built on Extism[1], which abstracts away some
| of the interfacing complexity. It'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'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's happening[2].
|
| For my part, I hope WASM doesn'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]: https://github.com/lastlogin-net/decent-auth
|
| [1]: https://extism.org/
|
| [2]: https://www.assemblyscript.org/standards-objections.html
| pjmlp wrote:
| It will be re-inventing the whole application containers
| ecosystems we had back a few decades ago across JVM and CLR
| ecosystems.
| apitman wrote:
| When you jump into every WASM thread with this take, what are
| you trying to accomplish?
| pjmlp wrote:
| Make everyone aware, born after 2000's what is being re-
| invented, while being sold as innovative.
|
| You are free to ignore my comments.
| apitman wrote:
| That's a fair reason. It's important to realize how often
| we re-invent the wheel in our field. As an example,
| you're an expert in distributed systems, which I've only
| recently started dabbling in. In the process I'm learning
| how so many of the fancy "new" distributed systems and we
| have today were essentially invented decades ago.
|
| But in the WASM case, to what end? There's a cost to your
| comments. I'm sharing an example of how WASM has helped
| me solve a real problem, and might solve real problems
| for other people. Your comments create noise to these
| types of discussions.
|
| Maybe it's worth the tradeoff in your mind, but I'm
| curious what your end goal is?
| pie_flavor wrote:
| WASM is designed to be embedded and its model is that of
| native code rather than any particular high-level
| language's primitives. It is closer to LLVM than Java.
| Comparisons to Java are surface-level and boring, since
| all foundational reasons why Java failed are false of
| WASM.
| pjmlp wrote:
| Interestingly enough, people keep forgetting that since
| UNCOL in 1958 there were many polyglot bytecode based
| runtimes, because comparing to Java is always easier
| argument.
| tadfisher wrote:
| 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.
| pjmlp wrote:
| And in a couple of years the same will most likely happen
| to the WASM backend.
|
| That was already possible with Haskell to JavaScript.
| pie_flavor wrote:
| For all browser targets to die, people must no longer be
| interested in writing Haskell while writing webapps, even
| though people will probably remain interested in writing
| Haskell, and probably remain writing webapps, which seems
| unlikely. For the WASM target to die and the JS target to
| remain, this would have to mean that there is some
| technical barrier that makes the maintenance burden not
| worth the staggering performance gain, and if there is
| some such burden I am not aware of it. 'Java died so WASM
| will die because both are VMs' is basically a content-
| free dismissal - what do you actually think will no
| longer be needed, or is currently not needed but
| overvalued, and why?
| pjmlp wrote:
| Yet we are talking about targeting the server in this
| thread, because so far the tooling for the browser sucks,
| and VCs are more willing to sponsor startups selling
| server products.
|
| Java not only is pretty much alive on the server, so is
| .NET, Erlang, and plenty of compiled languages that have
| always been a better alternative to JavaScript.
| pie_flavor wrote:
| I am comparing your words about WASM to your words about
| JS. Misdirections about VCs are irrelevant. You can
| expect the WASM target to have as great or greater
| longevity than the JS target, and if your prediction
| about future failure isn't true of JS then it won't be
| true of WASM.
| pjmlp wrote:
| WASM on the server isn't the same as JS on the browser.
| stult wrote:
| Also we have suffered a couple decades of JavaScript to
| give us that little extra motivation to make a common
| runtime environment work. And WASM is open source and thus
| not proprietary. And all the browsers (well, really, the
| one browser) are open source. The FOSS community is much
| more robust than it was 30 years ago, and there are many
| times more professional software devs floating around too,
| and security tooling and practices are substantially better
| now. Personally though I think the general antipathy for
| JavaScript and its endless parade of duplicative over hyped
| frameworks alone would suffice to push WASM forward.
| pjmlp wrote:
| And yet, most of the efforts are geared towards using it
| outside of the browser, where better alternatives to
| JavaScript have always been available.
| nilslice wrote:
| One of the maintainers of Extism here! Thank you for the kind
| words.
|
| As you know, we're all about delivering value with the actual
| standards today. This means using truly portable, w3c Wasm core
| modules. Not some "maybe in the future" standard a la
| Components.
|
| If you realistically want to use Wasm everywhere, in
| practically every language, Extism is the way to go and we'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 &
| serialization across the guest-host boundary, worth checking
| out: https://github.com/dylibso/xtp-bindgen
| apitman wrote:
| Thank you for Exstism. My main request is that you keep the
| core interface as simple and forkable as is feasible. You're
| certainly incentivized to make it as complicated as possible
| so only your team can maintain it, but I hope you're able to
| find a sustainable business model that doesn't go down that
| path.
| yoshuaw wrote:
| I agree about what your concerns about complexity, but the way
| I see what we'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'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're targeting the right scope.
| And that carries essential complexity.
| MisterTea wrote:
| > 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.
| apitman wrote:
| I agree that some things are essential, and there'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'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's how you end up in the
| situation where the "user agent" with majority market share
| starts gutting ad blockers.
|
| I'm not saying I'm predicating this will happen with WASM or
| even think it's very likely. I don't know enough to have a
| real opinion on that. I'm just saying I really really don't
| want it to happen.
| yoshuaw wrote:
| > 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?
|
| The big change going from WASI 0.1 to WASI 0.2 is that we
| decoupled the calling convention (Wasm Components) from the
| actual syscall APIs (WASI). That enabled us to make the
| various syscall APIs modular and composable.
|
| Because CDN functions probably shouldn't know about TCP;
| and CLI applications probably don't care about blob
| storage. And now they don't need to. Take a look at the
| WASI Proposals page [1] for an overview of all WASI APIs.
|
| [1]:
| https://github.com/WebAssembly/WASI/blob/main/Proposals.md
| apitman wrote:
| So basically the reasoning is that things like wasi-http
| wouldn't be mandatory for a compliant implementation?
| That would be good.
|
| Thanks for the link. I was trying to find a single page
| with everything listed.
| w10-1 wrote:
| I'd love to hear why WASM now has more promise than Java 1.x.
|
| Java's subsequent development was driven by
| enterprise/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'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?
| pie_flavor wrote:
| 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
| 'advances' doesn't mean any of them address its longstanding
| problems, and you'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
| 'native' modules in a JS-based text editor, or blockchain
| smart contracts. In fact Java basically cannot be reliably
| sandboxed at all.
| apitman wrote:
| Because WASM is currently solving a real problem for me that
| Java can'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.
| ryukafalz wrote:
| Since Wasmtime can run programs built for Wasm GC, I'm curious if
| this can as well. Would be neat if so.
___________________________________________________________________
(page generated 2025-03-26 23:01 UTC)