WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM.
Reading a bit of mainframe history would do some good it seems.
Reading a bit of mainframe history would do some good it seems.
> we’ve encountered the dilemma where you want to make it easy for users to write their own application logic using the system but at the same time want to keep that logic decoupled from the implementation details of whatever platform the application is running on
A common problem with a whole range of solutions. A decade or two ago the "obvious" choice would have been Java bytecode instead. Even the little "BASIC Stamp" microcontroller system matches this description.
I don't know, I know nothing about mainframes. I do not understand if your criticism is that they are making mistakes that have already been solved half a century ago (which is a good criticism, if true) or that they are not giving proper recognition.
The new shiny thing about WASM is that it fits into the constraints of the web platform. I suspect that even the best mainframes bytcodes had at least slightly different constraints.
I would really like a discussion and a comparison of them, seriously, I would read any such article I could find as the topic is interesting. But comments like this feels a lot like a hipster hating on the mainstream.
Chrome PNaCL SDK came with C, C++ and OCaml support, with an open source version available, which Mozilla refused to use and came up with asm.js instead.
I wonder if anyone has a list of awesome mainframe features so that we know what modern computing is going to "invent" next? :P
(See also: hot-swappable parts, virtualisation, containers, etc... I never got to work with mainframes myself, just each time I dig into some new "industry game-changer" tech, I learn that mainframes had it in the 60's)
The trick is identifying which parts were abandoned by mistake, and which parts were abandoned because they were genuinely bad. Nobody wants 21st century JCL. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...
So it has actually a chance to not be limited to one ecosystem or one company.
In fact, the simple idea that it's going to have a monopoly in the browser pretty much guaranties a broad attempt of adoption.
JVM and main frames could have been it, but they never were.
Let's try if we can make it work with a different name this time.
And some of them, also with multiple vendor offerings.
Chrome already has preview features available, that other browsers might adopt, or not.
And one of the most successful 'Portable execution format' nowadays I believe is JavaScript. WASM is just a sequel of JavaScript.
However if this is done through a simple reinventing the wheel route, there is a high chance of hitting the same walls and repeating the same mistakes.
This is kind of similiar to a "let's rewrite this code from scratch in new shiny lang/lib/framework" with the expectation that new code will be bug-free from the start. It's not always bad, it is sometimes necessary or it may turn out to be more effective than trying to fix bloated code. But very often the new code has problems exactly the same as previous code and effectively the developers reinvent the wheel multiple times in the process of rewriting.
It is just pointing out people likes to reinvent technology every once in a while with 95% of the same thing. And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had.
Sometimes these sort of Full Circle makes me wonder if software has really moved forward at all.
I'm quite sure that very often the "reinvention" is literally a reinvention - that is not based on previous invention, but an independent solution that just happens to be similiar to something created earlier (without the reinventors knowledge of the existing previous invention). With an abstraction level high enough, many concrete problems become one abstract problem with a few abstract solutions, and sometimes only very few "obvious"[0] solutions. This leads to a situation when many independent persons/teams come up with a concrete solution to their concrete problem that coincidentally happens to be very similiar to other solutions. If one of those solutions where created in the past, and others where rediscovered later, we then retrospectively call those later solutions as "reinventions" regardless of them being literal or just figurative reinventions.[1]
[0] in this context "obvious" defined as "most likely to be independently found/created by any sane person"
[1] "literal reinvention" being a solution that was consciously based on some previously existing invention and a "figurative" when it just happens to be similiar to something created in the past but the inventor did not (consciously) base their work on something already existing
I would find a comparison of wasm with older bytecodes very interesting as for sure none of them are perfect. But this kind of reply is clearly dismissive. It contains no criticism and it offer no insight over why some failed and other succeeded.
I essentially see it as lamenting that another similar technology was/is treated unfairly. Which is a fine comment, since many technologies meet a unjust or undeserved demise. It is still irrelevant as essentially boils down to "how dare you succeed where others have failed".
This is even worse than just saying that it is bound to fail miserably the same way Java applets did.
There are for sure negative sides to wasm, the fact that many parts are similar to past ideas is simply inconsequential on the merits.
HN top comment on dropbox wasn't really wrong either. Triviality proved to be a valid point. Plenty of companies made similar software once they saw there was a need for it. I mean who still uses dropbox today?
I don't know how to answer the rest of your comment... I don't think we have enough common ground to understand each other.
Another extremely plausible option is simply to sandbox mods for games. There are even projects for allowing userspace modules to run safely inside the kernel similarly to EBPF.
This last one in particular is something entirely new.
Without even considering the obvious application of allowing photo editing in web interfaces with reasonable performance.
Or on the other side of legality many people will try and use the new performance to have better cryptomining botnets.
Just by considering plugins (with dynamical loading and safety) and number crunching in-browser I would say that 'few hundreds' becomes a significant understatement.
I was considering wasm for myself too, read the spec, articles, played with their ocaml implementation, parsed a bit of bytecode, but concluded that it's not a good tech, too browser specific to use elsewhere and waste time on it.
I will assume so :)
There was a nice article detailing how for many application usage wasm today is less safe (under certain aspects) of x86, specifically due to the high quality level of tooling available for x86 and due to the fact that today debugging/inspection support of wasm is very low.
Other than that I would say that it is specific to the constraints you have in a browser. Two of which are the ability to run on minimal implementations requirement (as new optional features might be missing and might be running in a variety of environments) and the ability to safely run arbitrary untrusted code.
If you do not care about these then wasm does not offer much to you.
On the other hand it is perfect as a compilation target for plugins.
> application developers won't be touching it directly.
On the web it is meant to replace asm.js, it is not meant to be written by hand (unless you are a compiler developer).
The whole point of the article in this case is that it is a perfect interface for plugins over a specific and limited interface that allows running untrusted and opaque binaries.
For this specific usage only high-level languages where a viable choice up to now (two common choices were js and lua). wasm is comparatively closer to C than javascript/lua, but it is still safe to arbitrarily embed without using OS-level mechanisms.
It is a very specific use case, but also a relatively common one in applications.
One of the big sponsors (Fastly) in investing a lot in it due to the usefulness for them regarding lightweight sandboxing (for this reason they are also developing a debugger for wasm [1]).
On the other hand it is essentially useless if your application is something like a unix utility.
[1] I am not sure it is in this episode, but here the CTO of fastly explain why it is useful for their use case: https://softwareengineeringdaily.com/2019/09/25/webassembly-...