How so? I think WASM has major benefits for specific applications, especially for sandboxing, and running things in a cross-platform way. As far as I can tell, it's not that different from what Java and C# do (compile to your own bytecode, run that in a VM), except that you only give it access to specific functions.
While it might be slightly slower than running native code, I think that for certain users those are benefits that they can't overlook.
WebAssembly co-developed by " W3C; Mozilla; Microsoft; Google; Apple" and unless they put the people to develop it further, it stays at it is.
And I wouldn't be surprised if some of those companies wouldn't be feeling like patent ways to compile and optized WebAssembly into native code, or anything else related to tooling.
Hi! (one of the authors of Spin here)
Interesting to hear your thoughts on this, why do you think that?
We believe that the things that make WebAssembly attractive in the browser (compact binary, near-native speed, the sandbox isolation model) make it really compelling outside the browser, on the server.
> It has frontends for the following programming languages: C, Pascal, Modula-2, Occam, and BASIC.
> Maximum portability is achieved by using an intermediate language using bytecode, called EM. Each language front-end produces EM object files, which are then processed through several generic optimisers before being translated by a back-end into native machine code.
> The hardware isolation provided by the TIMI allowed IBM to replace the AS/400's 48-bit IMPI architecture with the 64-bit RS64 architecture in 1995. Applications compiled on systems using the IMPI instruction set could run on top of the newer RS64 systems without any code changes, recompilation or emulation, while also allowing those applications to avail of 64-bit addressing
I think this is an excellent point — while we do try to give acknowledgement to the previous technology that paved the way for what we are doing (there are a few articles that treat microservices, containers, serverless https://fermyon.com/blog/index), I agree that we could do a better job at talking about programming languages and language runtimes.
