I’ve been an engineer for quite some time now, and one of the things that’s grown to be a powerful part of my mindset is that making things involves tradeoffs. As Wikipedia says:
If multiple options exist, engineers weigh different design choices on their merits and choose the solution that best matches the requirements. The crucial and unique task of the engineer is to identify, understand, and interpret the constraints on a design in order to produce a successful result. It is usually not enough to build a technically successful product; it must also meet further requirements.
For example, we could build indestructible bridges out of carbon fiber, but then we’d be making one bridge every 10 years[1]. Now, I don’t necessarily expect someone pitching something to me to do this; however, if they do, my trust in what they’re saying increases greatly. It tells me they aren’t just reciting a list of bullet points that were prepared by someone else, but actually know the product. While I haven’t actually tried it, I doubt many of the people at electronics stores could intelligently answer e.g. “Why wouldn’t I want this phone?”.
But so what inspired me to make this post is two things; I was recently during free time looking lightly into both Unhosted and Google Go. Neither for any specific purpose; just to learn.
In particular in the case of Unhosted it was hard to get my head around how the whole thing would work, and while I think I see some potential tradeoffs, it would have saved me a lot of time to see those written down from the perspective of someone who had some experience with the system. I guess I’ll have to read the discussion archives.
[1] I know nothing about civil engineering and made this up.
Colin Walters 
LWN has a link to a lengthy review of Go (http://www.syntax-k.de/projekte/go-review). I haven’t finished it but thus far it seems very thorough.
But this reinforces my point; his “review” isn’t written by the authors of the system who presumably have the most real-world experience with it.
I suppose your point was a bit opaque to me, for I believed you were most interested in learning more about those topics.
Certainly it would be most authoritative for the Go developers to do this but, failing that, some data from a long time engineer is certainly better than nothing since he seems to share your perspective (that of saying what he wants from a language while showing how others don’t provide everything he needs).
Very true!
Hi, I’m part of the Go team at Google. Let me know if you have any questions about Go.
As for tradeoffs, Go has certainly made some. It is a garbage collected language; that isn’t free (although you have much greater control over memory layout than e.g. Java, and can stack-allocate structs). It is a safe language (e.g. pointers but no pointer arithmetic); that means that we don’t expect to beat hand-optimized C in microbenchmark contests. It has fewer language features than C++; that has both plusses and minuses.
It simply aims to be a productive language. Its original purpose was for writing the sort of concurrent servers that we have plenty of at Google, but more recently, there is increasing adoption as a general purpose language.