>>32
[citation needed]
This comes from the Go team. It's strange, the Android angle is the one I thought I'd have to argue over if anything. When Go was presented it was on the heels of the edict against using Python at Google. The Go team had presented Go, explicitly, as an alternative to Python and it was the only actual concrete justification made of Go's existence that I am aware of. What they hadn't detailed was an Android strategy, but supporting ARM on day 1 makes it a bit obvious, not to mention no one ever being contradicted by the Go team when they considered this aspect in conversations the team participated in.
Anyway, if you want a citation I believe it was mentioned in the webcasts. If not, I would search the mailing list or maybe see if there are FreeNode/#go irc logs somewhere. There's also this from the Go blog (
http://blog.golang.org/2010/05/go-at-io-frequently-asked-questions.html), which doesn't mention Python, but does mention that they're actually using it:
Go is ready and stable now. We are pleased to report that Google is using Go for some production systems, and they are performing well.
As for your questions about the unsuitability of Python, I would direct you to the Go mailing list. There is a lot of substance there on the matter, especially in the older posts. I don't remember most of it, but your objections sound all too familiar.
I don't think Go's concurrency is all that great either, by the way, Go does not avoid any of the gotchas present in the use of standard coroutines, nor does it provide any power beyond them (the use of channels notwithstanding.) Go does do a great job of making the gotchas
seem like they're not there, which is very astonishing to the person who learns concurrency from Go.
[Stuff about GC.]
I appreciate your pessimism, but you have a habit of saying "can't" when you seem to mean "won't." Most of the problems are solved in one way or another, but like you say, not in Go--even when suitable implementations are right there.
The optimist would point out that they're researching a new collector, based on an existing collector which is covered by patents.
Bleh. I did not want to derail this thread into a discussion about Go.
It's no worse than the thread's premise: bitch about C++. It's more interesting to bitch about Go. Besides, by not taking C++ seriously enough we're giving it an even harder time.
If you want a serious thread which is on topic I challenge you to present a suitable replacement systems language, or a description thereof. Anything else is just complaining that C or C++ sucks, or is good enough or bitching about how slow Python is(n't). The Go aspect is at least a conversation that hasn't already been had (and done to death) years ago, unlike all of the others you will find in this thread.