In my experience Go is probably 5-10x faster than C or C++. I estimate that programs that take me half an hour to write in Go would take me about 2½ hours in C and 5 hours in C++.
The language is interesting, at the very least -- concurrency primitives are nice, and the interface-based type system works for most cases (generic containers notwithstanding).
The major speed problem right now is GC, but that should be improving quickly.
The day Androïd will be written in go, we will see a significant performance boost and battery lifetime extension.
I don't program for Androïd just because I can't bare eclipse. An IDE as simple and efficient as QtCreator would generate a conversion tsunami.
The day when Google supports Android native app development in Golang, will be the day when Golang goes mainstream. But I don't bet on this thing happening.
Chrome will still be (mostly) C++ for a while. Even if they rewrote V8 and the UI; WebKit is still C++ and I doubt Google plans on ditching it without a very good reason.
I see a lot of very good reasons for Google not to lose time rewriting Chrome in Go, even without thinking about webkit, but do you have a reference to support this "200ms" assumption ? I never observed this in my programs (which doesn't have the kind of brutal allocations that a browser must have) so I'm curious.
ootachi does seem to like to pop into discussions about Go, throw around statements about Go's GC as if they were facts, despite never having used Go.
A 200ms GC pause is entirely possible for a busy, unoptimised server. The question you should be asking, though, is whether it's a problem. And if (and only if) it's a problem, whether the programmer has tried to reduce allocations. The easiest way to reduce GC time is to produce less garbage.
Now you've moved the goal posts. You can write free lists manually in Java as well. Doing so is incredibly awkward in Java or Go, compared to C++ where placement new makes it fairly straightforward (and moreover, you can use reference counting without too much trouble either). You can also use a real-time GC for Java, and you don't have that option in Go. This is perhaps uncharitable, but you're basically saying "our GC is bad, but you can work around it so it's okay".
Furthermore, you're implying that I'm saying something false ("as if they were facts"), but acknowledge that it is "possible". So I'm actually not seeing where I was wrong.
And I have used Go. I didn't like it. I realize I'm in the minority, but there are valid reasons for disliking Go.
You wrote "200ms GC pauses are completely unacceptable for a web browser." That's a bald unqualified statement. 200ms GC pauses are possible in some situations, but you say it as if it's inevitable and unfixable. It's not.
A garbage collected environment does not mean that generating garbage is harmless. Even in the presence of a (hypothetical) perfect GC, generating garbage would still be a major overhead. Go's GC is simpler than Java's GC, and has plenty of room for improvement, but you have much greater control over whether your code generates garbage in Go, which means that the suboptimality of Go's GC is much less significant.
I don't really care whether you like Go or not, or whether you use it. But you keep saying stuff about it that is either untrue or at least misleading. It's almost as if you have an axe to grind.
How do you have greater control over whether your code generates garbage in Go? The only difference between Java's memory model and Go's memory model is that, in Go, you can put structs inside other structs (and unsafe code I guess, and note that you can get some of the "structs inside other structs" benefit from inheritance in Java). That's it. The stack/heap distinction is no different between Go and Java.
The idea that "the suboptimality of Go's GC is much less significant" is just wrong -- Go has the exact same memory model as Java, only it's less well equipped to deal with it than Java is because its GC is so suboptimal. I'm just countering the oft-quoted statement that Go's memory model is somehow closer to the metal than that of Java -- it isn't.
To optimize allocations in Java, you use free lists and make fewer variables escape so they can be stack allocated. To optimize allocations in Go, you use free lists and make fewer variables escape so they can be stack allocated. Java has a wealth of allocation profiling tools available at its disposal. Go has some too. Go doesn't provide anything over Java here.
For me it's OK. I hadn't see this before and I feel that a discussion without those who don't like Go would be dangerously poor. Thanks for your contribution.
Can we now say that Google Chrome can be written in Go and it will be faster and/or stable ? ( not saying it is not already. ).
Congrats to the team, just started using go yesterday and loving it.