Yup. WASM lacks the "domain specific" acceleration available to native code. So you miss out on any hardware codec support. Same is true for openSSL, there is a bunch of encryption acceleration in modern CPUs that WASM can't access at the moment.
There are compelling applications for WASM in the embedded space, here we run C / C++ applications and WASM supports this well. We can also run other languages compiled to WASM too.
On the server side this is less clear. Typically we don't write system level languages server side - we use other languages, like Ruby, Python, JavaScipt etc. These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient. The benefit to the cloud / infrastructure provider is often not-clear, not when it's possible to run these very same applications in existing infrastructure. On the server side the benefit to the application developer is also not clear. There are few providers who have infrastructure to support WASM applications directly. You'd really need to see the big 3 cloud providers look at supporting WASM directly, without hypervisors / vm / container technology under it, to realize any performance improvements and hence pass on some cost benefit to the developer ecosystem.
"running stuff in the browser"; isn't old news. There are a growing number of applications that are migrating toward web-based UI and for these WASM is really useful. WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world....
Rust-Focus; yes, you are correct the existing technology, with the exception of perhaps WAMR and CloudEdge runtimes are rust based. As WasmTime is the only standalone technology which currently supports preview2, and it's written in rust, then the associated examples and tooling are naturally rust focused.
> WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world
The jco project (https://github.com/BytecodeAlliance/jco) provides an implementation of the Component Model and WASI Preview 2 for JavaScript systems. Right now, node.js support is complete, but support for Web embeddings is in progress and coming soon.
> These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient.
The Bytecode Alliance has made big improvements to SpiderMonkey performance on WASM/WASI systems, and has work in progress to take advantage of SpiderMonkey's "native" codegen targeting WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/. We targeted JS first for this work because it is the most popular language with our customers and users, but we expect that this will show the path to adding similar improvements to Ruby, Python, and other languages commonly thought of as "interpreted".
unfortunately wasi-threads is deprecated. You'll need to wait for threading support from "core-wasm" and that's a while off, there is no date on the horizon for this, as far as I know.
The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get existing wasi binaries to run preview2, and of course, preview2 binaries won't work on non-preview 2 runtimes...
For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split:
> components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory.
Hopefully it's trivial to push C structs around by value if poking around in other instances memory isn't allowed. Otherwise it sounds like a lot of hassle just to appease "fringe languages" ( ;P ) that don't have a linear memory model. This sort of "directly reading and writing the WASM heap" is quite essential for JS code that sits between a WASM instance and a web API for instance (in the "WASM in browsers" scenario).
...for instance how do you share large amounts of data between components then, there must be some sort of cheap way to safely share portions of memory between components right? Because there are situations where multiple copy steps are simply out of question.
If you watch the video I linked to in the sibling comment, Luke addresses that exact question around 21 minutes in. The WIT spec I also linked to talks about resources and handles in some depth.
I thought this keynote presentation[0] by Luke Wagner at Wasmcon was great and covered it very well. I also found the WIT Format design doc[1] in the component model repo to be the most complete explanation of how it's all going to hang together.
Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use).
When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practice.
I'd encourage you to read up on the component model. The talk by Luke Wagner linked in other comments is incredibly informative if you can make time to watch it. It's not about replacing WASI, it's about providing a coherent model for both implementing APIs like WASI and also providing structure and tooling for integrating codebases together in a sensible way using WebAssembly.
No, blogging won't return. Not in the same way as before. In the days of the dial up modem the written word was king. Twitter originally had SMS as a communication mechanism. But look at what the younger generations do, the use the internet for 3D gaming, for video watching.
It's the same micro-attention span as a tweet, but the media has changed. In the immediate term it's video content. But this will also give way to the next thing...
But, unfortunately the written word requires more attention than modern internet users have to spare.
There's still the same amount of intelligent, thoughtful, people with attention spans out there, you could still write for them, the same as always. You just wouldn't be writing for the masses anymore. But do you need to? Do you need your content to be applicable to everyone?
Yes and the Neobanks, both N26 and Revolute rely on fact that financial regulators across the block recognise each other, so N26 regulated in Germany can operate in Ireland. Etc.
From a technology point of view there is a lesson in how a company controls the media it's customers consume. How alternative sources of data get discredited and how untrusted the information found online is. The result, when you can't trust anyone, is to trust the source you want to believe. Many men want to believe they'll get a bigger penis.
> Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc.
Reminds me of when Microsoft and Sony where going head to head with consoles, and Microsoft tried to introduce a marketplace for selling or sharing a game. The resulting advert from Sony; One guys says to the other "Here just take it" and passes a physical disk to his friend. That ad, basically sunk the idea with consumers.
Post COVID cloud spending is down. Companies are starting to wind in their IT budgets, why would they want to pay yet another subscription?
