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
