Go Programming talk [OT]

[Andrei Alexandrescu]

On 06/06/2010 05:13 PM, bearophile wrote:
> A recent talk about Go, Google I/O 2010 - Go Programming, the real
> talk stops at about 33 minutes:
> http://www.youtube.com/user/GoogleDevelopers#p/u/9/jgVhBThJdXc
>
> At 9.30 you can see the switch used on a type type :-) You can see a
> similar example here:
> http://golang.org/src/pkg/exp/datafmt/datafmt.go Look for the line
> switch t := fexpr.(type) {
>
>
> Originally Go was looking almost like a toy language, I thought
> Google was thinking of it as a toy, but I now think Google is getting
> more serious about it, and I can see Go has developed some serious
> features to solve/do the basic things.
>
> So maybe Andrei was wrong, you can design a good flexible language
> that doesn't need templates.

Which part of the talk conveyed to you that information?

> Compared to Go D2 is way more complex. I don't know if people today
> want to learn a language as complex as D2.
>
> Go target flexibility and performance is not C++-class one (but
> probably it's not too much difficult to build a compiler able to
> produce very efficient Go programs).
>
> In the talk they show some interfaces and more things done with free
> functions, I don't know those things get compiled in assembly.
>
> Bye, bearophile

I'm surprised you found the talk compelling, as I'm sure you know 
better. The talk uses a common technique - cherry-picking examples and 
avoiding to discuss costs and tradeoffs - to make the language look 
good. In addition, the talk put Go in relation with the likes of Java, 
C++, and Python but ignores the fact that Go's choices have been made by 
other languages as well, along with the inherent advantages and 
disadvantages.

The reality is that in programming language design decisions that are 
all-around wins are few and far apart; it's mostly tradeoffs and 
compromises. Structural conformance and implicit, run-time checked 
interfaces are well-known and have advantages but also disadvantages. 
Flat, two-level hierarchies with interfaces and implementations are also 
well-known along with their with advantages and disadvantages. I think 
an honest discussion - as I hope is the tone in TDPL - serves the 
language and its users better than giving half of the story.


Andrei