[canop_fr]

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.

[dsymonds]

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.

[ootachi]

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.

[dsymonds]

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.

[ootachi]

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.

[ootachi]

I apologize for the above comment. I am being extremely uncharitable to Go and I retract what I have said.

In particular I apologize for bringing this up in every Go discussion.

[canop_fr]

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.

[ootachi]

I'm quoting the numbers that Vitess observed.