To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it in production. Wasm still feels like a toy compared to that
You likely visited a website using wasm today without realizing it, and major apps like Photoshop have been ported to wasm, which was the original dream behind it all. That has all succeeded.
But if you want to replace containers specifically, as this article wants, then you need more than wasm 1.0 or even 2.0. I don't know when that future will arrive.
Like, how easy is it to write a web application in Wasm? Or how easy is it to compile your average program written for a native platform to Wasm without hand picking your dependencies to work on the platform?
Wasm succeeded at its initial goals, and has been expanding into more use cases like compiling GC languages. Perhaps some day it will be common to write websites in wasm, but personally I doubt it - JavaScript/TypeScript are excellent.
https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...
But the rest of the community prefers using the original implementation. If some library that you want to use doesn’t work, no one is going to help you. You’re using the second class implementation.
And I was able to get things working with an understanding of the whole system. You could instantiate the WASM from either a file, or from a byte array, pass in the byte array that held 'system memory' for the WASM program, call the WASM functions from the JavaScript code, and see results of making the function calls. The WASM binary was under 3KB in size.
Now once you want to use libraries, everything light and small about WASM goes out the window. You're at the mercy of how efficiently the library code was implemented, and how many dependencies they used while doing so.
I think the "WASM as containers" and "WASM as .jar" approaches are rather silly, but language support is good enough to use the technology if you think it's a match. I don't think it will be for most, but there are use cases where pluggable modules with very limited API access are necessary, and for those use cases WASM works.
Plus, if you want to run any kind of game engine in the browser, you're going to need WASM. While I'm not replacing my Steam install with a browser any time soon, I have found that WASM inside itch.io runs a lot faster and more stable than Winlator when I'm on my Android tablet.
Around the same time Linux is ready for the desktop.
There is naturally the version that works, keeping the Linux kernel, and replacing the userland with managed language frameworks, I have heard they are making a huge success in mobile devices and throwaway laptops.
Sleep worked perfectly until Microsoft decided that device manufacturers should replace sleep with overheating in your bag (a much better sleep mode than, y'know, actual SLEEP).
Not sure what "modern UEFI features" means. Whenever something is described as "modern" that screams to me that someone is trying to conflate recentness with quality which is a red flag. UEFI itself has worked fine for as long as it has existed as far as I know?
Why you would replace the userland with "managed language frameworks" is quite beyond me.
That must be why Linux forums are full of VA-API tutorials and how to enable hardware decoding on Chrome then.
> UEFI itself has worked fine for as long as it has existed as far as I know?
Depends on the board, some boards don't play ball with Linux distros.
> Why you would replace the userland with "managed language frameworks" is quite beyond me.
Google has their reasons, as does LG, seems to work quite well in market share.
Meanwhile on Windows I am not exaggerating when I say that every computer I have owned and every peripheral device I have ever used has had serious issues. Wireless headphones randomly disconnect, microphones require frequent unplug-replug cycles, rebooting is often required, reinstalling is common. Mice and keyboards have weird compatibility issues with software drivers. This experience is shared with most people I know that I have discussed it with. People are just used to it.
Maybe it isn't Linux that is the problem. Maybe the problem is that consumer hardware is designed and built on the cheap and is not designed to last, and they get away with it because most people (1) have no idea it could be so much better and (2) have no insight into these issues before buying because they are rarely covered in reviews.
For some reason when this happens on Windows, the hardware is to blame, but when it happens on Linux, Linux is to blame.
Then, of course, I was also curious whether their reasoning was grounded, so I manually enabled acceleration and re-run the test - and found out that both Chrome and Firefox will inevitably crash in 2-3 hours of active browsing with it enabled, so they disable it for a reason.
As far as "maybe Linux isn't the problem" - you're broadly correct that it's really an issue of hardware quality and/or lack of good first party drivers. But from the end user perspective, if you can't reliably use Linux with popular off-the-shelf hardware, it's not really "ready for the desktop", regardless of where the blame lies. I've been a Linux user for 25 years now, with about a decade of using it as a primary desktop OS, and this exact excuse has been around for as long as I remember (I've used it myself plenty of times way back!). And yet, here we are.
More commonly you have to wait six months for good/full support of new hardware.