I intentionally said most, since, obviously there are serious domain-specific languages. But stating that Go is designed for large code bases, creates a false dichotomy.

Go has the advantage of being designed for the kind of thing Google does - massive concurrency.

So, claims the C fan since there's GCD, so claims the Erlang/Scala fan since it has actors, so claims the Haskell fan since it has green threads, STM, and purity.

Also, is Google interested in massive concurrency or parallelism?

It's also like C, which make it easier to find good programmers who are confortable with it. Actually, you'd be hard pressed to find good programmers who are uncomfortable with a language that's nearly C.

That's a good point. But as a result it provides only a marginally better type system, at the cost of performance compared to C. Why not make it a lot better than C, with the same performance?

It's kind of a domain anti-specific.

I would. I used the gtk-perl bindings for a project and I thought they were very well done. Previously I had only used the C bindings and taking the step to a higher level language (and more importantly, one with closures) was a very nice step. It was a much better experience than doing Cocoa with Objective-C, IMO, but that could have also been related to the specific (smallish) project I was doing.

For many things, GC is a huge productivity boost. I've heard good things about C99, C will probably evolve into a language with a better type system anyway. I don't use C myself, but I don't see why there couldn't be a flag to ensure code only uses a saner subset of the type system.