If you can't even get error handling right and consistent, what claim do you have to consistency? At least in java it's pretty much all exceptions.

The math library, as mentioned above, is pretty darn iffy.

The existence of both 'path' and 'filepath' is possibly a mistake.

The 'heap' and 'list' in collections both seem like they should be similar, but 'heap' operates on a thing that fulfills its interface and list operates directly on arbitrary objects without some interface needed.

Due to the lack of 'protected', the std library is littered with exported fields you shouldn't use (e.g. gob.CommonType and template.Template.*parse.Tree and so on).

Sure, the library is consistent in many places because the language is so small there's little else it can do but be consistent, but the fact that it falls flat in error handling and has visible warts makes me feel that it's a very broad std library, but far less consistent than, say, Rust's (where everything returns consistent Optional error types) or Java's or Smalltalks. Sure, it's more consistent than the clusterfuck that is ruby and/or python or javascript or (heaven forbid) c/c++, but by no means is being better than any of those an achievement in this category.

Everything in Go's math library operates on Float64 types, so:

My biggest disappointments early on was not even having a Max/Min function for ints.

Part of the problem with comment syntax is that it's intentionally lexical and uniform. This simplicity means that you can easily obliterate the content of comments at any point in the input file stream via the tokenizer. However, Go instead has to bend over backwards in it's compiler toolchain to preserve comments beyond the lexer: in the parser, AST, code generator, etc.

Compare to docstrings in SmallTalk/Python/Clojure, where they are actual parsed string literals. Also compare to C#, which has explicit and distinct syntax for comments, metadata, and compiler directives. Comments can be inserted more or less anywhere. Metadata only where it's unambiguously attached to an AST node. And directives similarly to statements, unambiguously detached from other AST nodes.

It's interesting how none of that video was anybody using IE... they just used holograms and skateboards. Was skateboards supposed to be the future of computers? If that was the prediction they went wrong in more way than just IE-only.

Basically, C# instead of ActionScript, "more secure" since .NET CAS, the same shape stuff as Flash minus shape tweening but plus data binding without Generator, and your WPF desktop app only needs tweaks rather than a full rewrite to go on the Web.

Also support for PlayReady/PlaysForSure DRM. Which is all anyone actually used it for.

Yep, horrible performance due to display lists hierarchy is totally not a problem for games. Neither is lack of hardware acceleration (prior to 10.1) or 3D graphics (prior to 10.0). And every game developer loves stringly-typed enums!

As I mentioned in my previous post, there are only two reasons people made games in Flash: it's quite easy to get started, and there was no real alternative (not true anymore since the advent of HTML5 and Unity).

It's sad how far we are from a true alternative to JS on the browser. Google with Go/Dart, Mozilla with Rust and ASM, and MS with whatever they are doing this month.

To get a new language, browser vendors would not only have to throw away thousands of dev hours sunk into their js engines, but would also have to work together without screwing each other over patents, "synergy" features, public opinion, prestige...

And in the end, all we'd get is once again something like javascript. Look around. It's not like there are viable new language ideas floating around.

We should be happy EcmaScript is actually moving forward and making js better, unlike many other languages stuck in the rut. This is the best we'll get in the foreseeable future.

As I mentioned in my previous post, there are only two reasons people made games in Flash: it's quite easy to get started, and there was no real alternative (not true anymore since the advent of HTML5 and Unity).

Oh I see. So it's a bad choice but the better choice is an imaginary thing that doesn't exist.