I can understand where you're coming from since I like static typing as well, but I don't think what you're saying is fair. It's good to be able to statically identify certain classes of errors so that you can, as you say, find and fix them within the IDE rather than having to resort to runtime debugging. What he (?) is saying is that, up until the point where you encounter the error at runtime, the fact that you can statically detect it shouldn't prevent you from running your code.

This philosophy is obviously a tradeoff. It's good for prototyping since you don't have to make sure your whole program passes static analysis in order to test a particular code path. On the other hand, if developers get away with leaving such code in a large project (as a work in progress that never gets addressed, for example), this can create a maintenance nightmare. The solution to this is to not let people contribute code to the project which doesn't pass static analysis.

1. Flash sites won't be using the features in question.

2. Flash sites should die a horrible horrible death.

No disagreement here on the fact that flash sites should die a horrible death.

Regardless, many flash developers have been clamoring for true 3D rendering in flash for a long time, and hack it together with libraries like Paper Vision. Perhaps I missed something, but the article seems to suggest that these features will indeed be available in the browser plugin, and thus usable on flash sites.

I was considering their claim that it's easy to turn on but difficult to turn off to be a design flaw.

The H2G2 sent queries over the sub-etha-net.

The Go team has actually reacted to a lot of feedback. They just haven't made sweeping changes to the language willy nilly at request.

I'd like to point out that Go also started as a personal project (a 20% time project at Google) that later got picked up by the company, so your statement that the same is the case for Rust isn't really a distinction, but a similarity.