Miguel de Icaza Talks Up WebAssembly Greatness

[mgiammarco]

Simply speaking,
De Icaza is a Microsoft fanboy and (secretly) evangelist.
Some years ago pushed mono to try to persuade opensource developers to use Microsoft tools and he get promoted in Xamarin.
Now Microsoft has a big problem: has lost control of web developing.
Web developers use opensource technologies and not microsoft ones. Also there are so many legacy third party Windows applications that must be ported on web.
The solutions is to push developers to use Blazor which is based on WebAssembly so C# developers can be recycled in building web applications and Microsoft can take again control of the developers' world.
So De Icaza again wears the evangelist hat and starts pushing WebAssembly.

[Luke_Wolf]

The JVM can turn heap allocations into stack allocations for the simple cases where it is actually possible.

It's cute of you to say that, but there's a reason that JVM programs are uniquely memory heavy, and that reason has nothing in particular to do with the underlying architecture of say a Java vs a C# application. In fact most of the broad strokes of how they're written are going to be the exact same, it is more in the fine strokes where they differ, and therefore an average C# and Java program should be using a similar amount of memory. Well they for all intents and purposes are (with the caveat mentioned in my previous post), the difference is that in the real world Java is throwing everything on the heap and you're at the mercy of the Garbage Collector whereas .NET handles about as much as a program written in other languages on the stack, and so the automatic memory management of the stack limits the impact on the memory overhead of the program.

Java didn’t have the luxury of breaking backwards compatibility and forcing everyone to rewrite their software. They are looking at possible solutions that are less disruptive. Some of that is coming in Java 14/15.

Java like every Sun Microsystems products other than Solaris didn't have the luxury of skilled developers, and even then that was mostly Bill Joy. They were almost as bad as Adobe. Sun Microsystems could have very easily have resolved the issue without forcing everyone to rewrite their software, a simple recompile with the artificial delineation between primitive types and Object derivatives being removed from the JVM ByteCode would have been enough, to be quite clear there's nothing in Java's fundamental language design that says primitive types can't be Objects and participate in generics. However there's plenty wrong with the type system that the Java Virtual Machine Bytecode implements, and merely gutting the JVM (and its bytecode) from the language, and reimplementing the language ontop of CIL (Common Intermediate Language, .NET's version of Bytecode) would allow for immediate fixing of the generics system, with no changes required in client software... simply a recompile. It's really not a language layer but an implementation (Or rather in this case an Intermediate Language) layer problem.

[bug77]

Is NoScript blocking (allowing control) right now? WASM is live ... now....

I don't know whether you can block WASM directly, but WASM is always bootstrapped/called from JS. Block JS and WASM goes away as well.

Uh... why am I wrong? So, you have total control over WASM right now? What runs, what doesn't run? Full source?
Don't be belligerent just because...

You have exactly the same level of control as you have for JS.

[cynical]

So if it's a primitive type it's loaded on the stack, if it's a class type it's loaded on the heap.

The JVM can turn heap allocations into stack allocations for the simple cases where it is actually possible.

Everything else... Doesn't have this problem. In .NET everything is an Object and it's generics are also more intelligently designed

Java didn’t have the luxury of breaking backwards compatibility and forcing everyone to rewrite their software. They are looking at possible solutions that are less disruptive. Some of that is coming in Java 14/15.

[cjcox]

I don't assume anything, I'm running NoScript as I type. If anything, you're assuming WASM will not be blockable in the same manner.

Is NoScript blocking (allowing control) right now? WASM is live ... now....

I know you believe that, but you are wrong. I was asking why, hoping I could address your concerns.

Uh... why am I wrong? So, you have total control over WASM right now? What runs, what doesn't run? Full source?

Don't be belligerent just because...

[bug77]

You're assuming that people don't block Javascript.

I don't assume anything, I'm running NoScript as I type. If anything, you're assuming WASM will not be blockable in the same manner.

Regardless, I believe it is actually different.

I know you believe that, but you are wrong. I was asking why, hoping I could address your concerns.

[chinoto]

What malicious things can WebAssembly do that Javascript can't do?
Sure, WebAssembly is used for cryptocurrency mining, but so is Javascript, albeit less efficiently, though that doesn't make a difference to a user, the miner is likely still using about the same percentage of cycles.
There is a potential Spectre/Meltdown vulnerability with WASM threads, but that isn't going to be enabled until the vulnerability has a fix.
Look at the instruction set (link), there's basically math, control flow, and memory.grow. Am I missing something?

[cjcox]

What do you mean? How is downloading WASM IR any more dangerous than downloading JS?

You're assuming that people don't block Javascript. Regardless, I believe it is actually different.

[bug77]

There is also GraalVM which lets you compile to a native binary and only includes the bits of the standard library that your program uses. But you can't use certain Java APIs, especially Reflection, and for long-running processes GraalVM is slower than the standard JVM because it doesn't have the full JIT optimization engine.

There really isn't GraalVM
Native image is experimental, it has lots of bugs on top of the inability to deal with reflection. Even it worked as advertised, Java libraries haven't been modularized and GraalVM still can't tell what to include and whatnot. You need to use PGO to overcome this. I'd like to say it's getting there, for the 3 years or so I've been eyeing it, I haven't noticed much progress.
But when it does work, seeing something written in Java start in under a second and not automatically grabbing 200-300MB RAM is something to behold.

[cybertraveler]

From the front page of the Wasmer site:

curl https://get.wasmer.io -sSfL | sh

Who actually runs these pipe curl output to sh snippets?!

I don't think I'd even use that command in a VM; if not because of VM escape bugs, then because I wouldn't even be sure of what commands were executed.