It's "in the browser", so it counts as innovation. More library/emulation/abstraction layers equals progress in the 21st century - didn't you know?

With dynamic recompilation (which PNaCl disallows, if I'm not mistaken), you could run it even on 2000 era hardware.

All I got was: "Error: NaCl module load failed: PnaclCoordinator: PNaCl Translator Error: Error reading bitcode file: Invalid BINOP record"

If it's a javascript emulator, it's going to be really slow. If it's some hybrid that are JIT, then it's not secure. Speed, security, cheap, pick two.

10 Megs of Sram memory, a 50 MB hard drive and I did what I'm doing with windows now. Remember 20 years ago when you played Doom and
that's all you could do? I ran a BBS in the background while playing my games.

That's sort of the inherent nature of emulation. Next thing we know, you'll be complaining that it takes a fairly beefy machine to accurately emulate the C64.

Indeed, Firefox now plays video content via gstreamer, so I only keep Chrome around for recalcitrant flash-only sites.

HAM was around almost two years before VGA debuted (with the PS/2 in April 1987)! (*)

The downside was that it was hard to use for animated graphics, since the colour of most pixels were modified shades of the one to their left, meaning one had to take into account surrounding pixels when moving an object to avoid miscoloured streaking. Few action games used it, though I'm still convinced more games could have exploited HAM if the problem had been analysed methodically and restrictions on the use of base c

Most people at the time were stuck on black and white with PCs, with 256 colors only for those who spent a huge amount of money for it.

I think the demos are still around if you search for Fish Disks. However the original floppies are essentially unusable on any standard PC floppy drive (no ability to control rotation speeds).

And most importantly, you cannot target all these platforms with any single codebase written in any language

Yeah, because that worked out so well for Sun and Microsoft, right?

Different users have different needs that are met by different languages and environments. And unlike other companies, Google seems to have concluded reasonably that they don't know what people are going to be using, so they give people options.

Dynamic linking is cancerous, thank the gods they chose not to use it. Of course, it's Rob Pike and Ken Thompson, so there was never any risk of it. And never will be as long as they're on it.

I'm not a software developer, but as a long-time network admin it always struck me that shared libraries were a great idea except when they weren't.

Before I switched to FreeBSD, Linux always seemed to have headaches with shared library problems, with some apps not working with some versions of shared libraries and a general nuisance being made with multiple versions of shared libraries being around.

Windows, of course, has its reputation for DLL hell, which I think was more of an issue in really old versions

Re Go being statically linked: great! It's meant to be a language for writing services. Those are typically deployed by creating a giant tarball of all the artifacts needed to deploy a service, copying it to all the hosts that will run it, extracting in place, and restarting. In this case, the tarball is the compiled executable. You can copy it to its server and have everything required to run it in a single tidy package.

Contrast with a Java deployment where the tarball will contain many JAR files, etc. Rol

It's really quite simple. A lot of Google projects started from a handful of people going "you know what would be a cool idea?" and doing it with very little approval or red tape (the fabled 20% time). That's certainly the only explanation I can think of for DART, at any rate.

Go is basically what you get when you hire a former Plan 9 developer, expose him to Google's internal hermetic build system (where a 100MiB binary is small), then let him build cool stuff to keep him from getting bored.

Disclaimer: I