I think it's a bit simplistic to assume native, already compiled code is the only payload worth considering.
The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.
Wasm also seems like a potentially better target than what we have here, which seems interpetter focused. Wasm otoh might actually be able to jit/aot compile down (which the mentioned wasm3 interpretter eskews with a list of good reasons, for anyone looking for counterarguments). And likely will have more invested in the ecosystem in doing optimizations in general.
> I think it's a bit simplistic to assume native, already compiled code is the only payload worth considering.
WASM IS compiled code
> The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.
1. They said that about java too.
2. Problem is...you need to compile something to WASM, and currently a lot more somethings are compileable to native than to wasm, and i doubt this will ever change, since compiling to wasm is a strict superset of compiling to native, in terms of work involved in making a compiler. (this is not true for old esoteric architectures, but i do not see you offering me a WASM runtime for the 8051 either)
> Wasm otoh might actually be able to jit/aot compile down
You know what else does that? Any compiled language ... to native code... In fact, we "AOT" it from the start in a process we call ... compilation. Your local free copy of gcc can do this for you. Check it out.
> And likely will have more invested in the ecosystem in doing optimizations in general.
You know what else does good optimization for a given target? You local free copy of gcc. Check out the "march", "mcu", and "O" flags
Point is: I buy the use of interpreted code on IoT: so people who cannot program can still make a light blink. But as soon as you go to compiled code, might as well compile for your actual target, and not a pointless IL (which is what WASM is until you show me your HDL for a WASM cpu)
That way, you get the portability of C, the optimisation power of GCC or your favourite C compiler and the portablity and determinism of WASM! Obviously there’s some overhead but there are definitely situations where this is a good option, especially where there’s a compiler available for WASM but not for whatever obscure platform you want to use
I feel like you are super trapped in a very small way of thinking.
Say I run an IoT system across a variety of embedded systems. I could dynamically load small behaviors & scripts to all targets with this. User scripts could target all devices.
Your aim that native code can target everything seems to be pretty limited. A lot of languages can't or won't invest in wide micro-architectural & embedded support.
I feel lile you are confining yourself to a very very narrow position, & refusing to see possible middle grounds or uses. We needn't adopt such stark framing.
> The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.
I'm old enough to have lived the Java experience: "Write Once, Run Everywhere".
The portability of wasm will be pretty excellent, and over time there may be a great cross-language ecosystem surrounding wasm that native may not match.
Wasm also seems like a potentially better target than what we have here, which seems interpetter focused. Wasm otoh might actually be able to jit/aot compile down (which the mentioned wasm3 interpretter eskews with a list of good reasons, for anyone looking for counterarguments). And likely will have more invested in the ecosystem in doing optimizations in general.