Announcement

Collapse
No announcement yet.

Miguel de Icaza Talks Up WebAssembly Greatness

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mgiammarco
    replied
    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.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by cynical View Post
    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.


    Originally posted by cynical View Post
    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by cjcox View Post
    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.
    Originally posted by cjcox View Post
    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.

    Leave a comment:


  • cynical
    replied
    Originally posted by Luke_Wolf
    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.

    Originally posted by Luke_Wolf
    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.

    Leave a comment:


  • cjcox
    replied
    Originally posted by bug77 View Post
    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...


    Leave a comment:


  • bug77
    replied
    Originally posted by cjcox View Post
    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.
    Originally posted by cjcox View Post
    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.

    Leave a comment:


  • chinoto
    replied
    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?
    Last edited by chinoto; 03-04-2020, 03:52 PM.

    Leave a comment:


  • cjcox
    replied
    Originally posted by bug77 View Post

    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.

    Leave a comment:


  • bug77
    replied
    Originally posted by Michael_S View Post

    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.

    Leave a comment:


  • cybertraveler
    replied
    From the front page of the Wasmer site:

    Code:
    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.

    Leave a comment:

Working...
X