Work Continues On WebAssembly For Low-Level, In-Browser Computing

[peppercats]

.NET allows the use of stack variables and structs, unlike Java. Java promotes using objects for everything and yet makes it as slow as possible to use things like a Point3D object. Java code that actually wants to be FAST has to do ridiculous tricks like using a float Array of coordinates divided into groups of three instead of an Array of Point3D objects. Java GC has to check the world for pointers to every single Point3D object. While .NET can say "That thing in this class is a struct and must be copied so no references can exist."

Also, .NET applications seem to start much faster than Java.

Yes .NET is just better.

Not a popular opinion in FOSS camps, but it really is.
C# is a vastly better language than Java, and .NET is much better than the JVM.

[caligula]

.NET allows the use of stack variables and structs, unlike Java. Java promotes using objects for everything and yet makes it as slow as possible to use things like a Point3D object. Java code that actually wants to be FAST has to do ridiculous tricks like using a float Array of coordinates divided into groups of three instead of an Array of Point3D objects. Java GC has to check the world for pointers to every single Point3D object. While .NET can say "That thing in this class is a struct and must be copied so no references can exist."

Also, .NET applications seem to start much faster than Java.

Yes .NET is just better.

Huge portion of the slowdown is caused by complex OOP design combined with huge number of heap allocations. Java developers have no idea about data oriented design or stack allocation. Java can sometimes guess when to allocate from stack, but you can't force it. Languages like Rust are totally the opposite. Sure, JIT is also slow, but it gradually stops compiling stuff and the compilations are usually < 10-100 ms per (larger) class when the runtime encounters a hot spot. For example on this 3 year old Core i7 laptop I have

$ java -version
openjdk version "1.8.0_66"
OpenJDK Runtime Environment (build 1.8.0_66-b17)
OpenJDK 64-Bit Server VM (build 25.66-b17, mixed mode)

$ cat Hello.java
class Hello {
  public static void main(String[] args) {
    System.out.println("Hello world!");
  }
}

$ time javac Hello.java

real    0m0.373s
user    0m0.723s
sys    0m0.033s

$ time java Hello
Hello world!

real    0m0.040s
user    0m0.040s
sys    0m0.003s

This isn't cheating. It loads the whole standard runtime lib and starts the VM, everything in 0.040 seconds (from SSD). The language isn't awfully slow, the virtual machine isn't that slow. If you use Webstart applications via the browser, it even caches the binaries and libraries on local disk. Many pages load longer than 0.040 seconds. I'm pretty sure you wouldn't even notice if it runs Java. It's just that the plugins are bad.

In web context, I'd put most of the blame on the browser plugin. I don't know what it does, but it starts up really slow. Otherwise it's usually the application that's failing. OOP patterns with huge complex class hierarchies and frameworks, and lots of factories and other useless stuff. That's what makes the code slow. Many Java apps also start some scripting engine or parse XML (slowly) because Java is crap for configuration.

[caligula]

Not a popular opinion in FOSS camps, but it really is.
C# is a vastly better language than Java, and .NET is much better than the JVM.

.NET isn't available on Linux. Mono could be still slower for computationally demanding tasks so for the Linux/BSD folks JVMs could still offer better performance. There are also other JVMs than the Oracle's one. It's mostly geared towards server side stuff.

Java, on the other hand, is a dead end. It's basically one of the reasons holding the JVM back from evolving.

[Luke_Wolf]

.NET isn't available on Linux. Mono could be still slower for computationally demanding tasks so for the Linux/BSD folks JVMs could still offer better performance. There are also other JVMs than the Oracle's one. It's mostly geared towards server side stuff.

Java, on the other hand, is a dead end. It's basically one of the reasons holding the JVM back from evolving.

Where have you been for the past year and a half? .NET is very much available for Linux https://github.com/dotnet/coreclr https://github.com/dotnet/corefx https://github.com/dotnet/roslyn it's just still in RC status as opposed to having an actual release yet. Yes WinForms, WPF, and WinRT are still tied to windows, but you can use GTK or XWT instead.

[SystemCrasher]

Once, there was this Java thing. It had a decent bytecode format. Decent performance. JNI. Cross platform runtime. Nowadays it's truly cross platform and open source and the performance is great. Sadly, for political reasons we're not allowed to use it anymore.

It also...
1) Had a really huge runtime with insane amount of crap for all occasions.
2) Due to this fact there is always shitload of vulns. Oracle fixes like 30 vulns each month and being utterly irresponsible, trying to shut up security researchers. Which is not going to work and at very most they can achieve 0day vulns being sold on black market instead. Somehow, Oracle is retarded enough to fail to understand it.
3) Startup time of this crap could be rather annoying, thanks to 1.
4) There're many performance issues.
5) Wasn't low level enough. You can't get rid of GC, runtime would do many nasty things (and just huge) and it is hard to get reasonable performance in some cases. E.g. writing game in java is PITA, you face crappy performance due to many extra checks in all places, strange runtime functions implementation, doing it yourself proves to be rocket science to get decent speesd, and there're sudden lags due to GC, etc. Sun mumbled it can be realtime. Maybe. But it takes rocket science. Written once, debug and profile everywhere, eh? That should be REAL motto of Java. That's how it performs in real world.

LLVM is nearly first thing which lacks inherent reasons to be huge, laggy or too restrictive in low level aspects. Something that no VMs/runtime before it managed to afford. That's what made them a poor choice - they were not flexible enough.

Try to write, say, decompressor of custom compression algo. E.g. brotli can compress much better than zlib and if you want to deliver some game, it can make sense to use it to comress resources. If you do it right, in extreme cases it can compress like 2x better than zlib. And decompression speed stays the same. If you do it in C, ofc. So you can spend less time on transferring data, same time on decrunching them and overall, startup time can be reduced. But if it have to be Java, you get increase of decompression time by 3x, and it quickly getting pointless. I can ask to install brotli JNI part? Ok, in this case it getting easier to ask to install native app version. Without all issues associated to milti-megabyte Java clusterfuck.

You see, when someone needs high-speed interface, java would not do. E.g. these days highspeed algos are only noteworthy if they do something better than competitor. Compress better at same compression speed and you' win. Or decompress faster while retaining same comression ratio. And so on. Java kills it by 3x right on start, making it utterly incompetitive. For this reason no compression algos devs are using Java and .NET. They need for speed, and slowing self down by 3x... you stand no chance vs competitor and whole thing happens to be utterly pointless. Google's brotli is only interesting because if you can afford more time on compression and care about data transfer time over slow channel and about decompression speed, you can have some scenarios where it cuts down download size and time and decompresses at same speed as zlib, hence advantage. Fail to do that, and algo's place is garbage bin. Nobody would use it.

So who would need Java and why? I can see some enterprises used it, but that's all it managed to afford, facing .NET as competitor. Both are living in rather specific niches and web version of .net aka silverlight has died by horrible death, being more or less plagued by same shortcomings like Java but even less spread, even more bugged & troublesome overall, and so it is utterly unwelcome. Both are two overgrown, oeverengineered, overbloated monsters. LLVM lacks inherent reasons to be like this and low level enough to just translate code AOT, rather than do shitload of unwanted/troublesome things. I think LLVM can do it better than that, hitting some reasonable point where e.g. gamedevs would actually use it. Without constant flow of curses and swearing.

[SystemCrasher]

Yes WinForms, WPF, and WinRT are still tied to windows, but you can use GTK or XWT instead.

And it is so cool to rewrite half of program, dammit. At the end of day if somone writes C or C++ program using GTK+ or Qt under Linux, they can just rebuild it for Windows or something with zero changes or so, and it takes orders of magnitude less of human time to get there. Actually, it often happens windows builds are even made by different people, so it takes ZERO human time of program author(s). That's how opensource works. You can be crossplatform with almost zero efforts, and can offload platform support efforts on those using it, if they need your program. Something proprietary nuts never mange to figure out and seeing some "advantage" while there is none. Tee-hee, it is disadvantage of proprietary software it is not portable and bound to some platform, not something else. Not to mention in Linux we are not going to be just some mere third rate microsoft ghetto, whatever .net morons prefer to see. At the end of day, there are very little reasons to use .net in Linux, except maybe case when you're seriously dreaming about living in ghetto suburb of microsoft techs. Which is strange wish, to say the least.

[SystemCrasher]

Not a popular opinion in FOSS camps, but it really is.
C# is a vastly better language than Java, and .NET is much better than the JVM.

But they share something in common. Both failed miserably in web and both have got rather specific uses. They have very similar disadvantages overall

[Lennie]

Nope WebAssembly is the successor to PNaCl as a technology, whether Mozilla proposed it or not. Google just finally got Mozilla to agree to breaking the Javascript monopoly on the web.

asm.js was a competitor to PNaCl, because asm.js uses normal Javascript code as the bytecode instead of a new bytecode. WebAssembly is 100% based on asm.js with only changing ascii to binary.

Actually no it doesn't. HTML5 Video has been a very troublesome beast as an easy example and what is far more noticeable is that less and less of the web has worked on alternative browsers since the rise of HTML5 while sites have remained much the same or gotten even worse. The reality is that further developing XHTML was the right way forward instead of them sticking to the stance that it should be forgiving for non-programmers.

HTML5 video has problems because of the codecs and patents, nothing to do with HTML. XHTML ? Yeah, browser vendor and very little webdevelopers believe that was a good idea. The HTML5 way was better: define how to fail. This works for the browser vendors following HTML5. I'll agree with you that all the specs are large, so browser engines is not an easy investment. But building any application environment is a lot of work. Building a Win32-API is a lot of work just ask the WINE people. Building a JVM is probably even more work, because Java like HTML has specifications to write and everything that goes with it.

If you aren't happy about the existing HTML-elements, you can even create new ones. See the new HTML web components standard.

[mdias]

The unsigned types are different only on very high level, before compilation. JVM supports unsigned types just fine with wrappers. You're making the assumption that raw pointers and C like languages are a goal we should aim at. In reality it's not.

WebAssembly is about getting rid of workarounds. If we accept "supports X with wrappers" we're down to square one; I mean, after all C++ code can already be compiled into javascript.

I don't think you understand the point of WebAssembly just yet. Pointer support is needed not just to support C-like languages, but to expose basic functionality of a real CPU, hence the name "WebAssembly". You're only getting near-native performance if your assembly code is able to expose functionality that can easily be translated into your native CPU's code.

Now, depending on the language you use the generated WebAssembly code may be more or less efficient depending on how close this language can represent the underlying code. This is why C-like languages are generaly faster than everything else: they can represent the generated ASM code relatively well.

Actually if you take a closer look at asm.js you will see that it's "just" a bunch of tricks to give more hints to your JS interpreter in order to be able to make some assumptions and perform faster. This is a hack though, and WebAssembly is here to solve this problem the proper way. This includes being able to use whatever language you like (before ebeing compiled into WebAssembly) for web programming, instead of just javascript.

[abral]

Nope WebAssembly is the successor to PNaCl as a technology, whether Mozilla proposed it or not. Google just finally got Mozilla to agree to breaking the Javascript monopoly on the web.

Nope, WebAssembly is the successor of asm.js. It was proposed and designed by Mozilla. I don't see how you could consider Google as the primary developer...