Live data from Hacker News

Go version 1 is released

blog.golang.org

161–168 of 168 posts

Re: Go version 1 is released

#161

Earlier quoted context omitted.

Essential question: what makes it fun?

For me it is probably this. It works - easy as pie. No problems building, linking or worrying about dependencies. (it should be noted that this is a common property of hobby projects) It's fast, which is nice for the small boy (or girl) in all of us. It is gratifying to make software that can run like blazes. I get the control over memory layout that I really want. By day I am a Java dev, by night I used to hack Erla…

I too like Go. But I disagree with some of your analysis.

Java annotations aren't magical; at least no more magical than functions/methods. They're part of packages/libraries and should be documented. You can even write your own annotations.

I'm still not convinced that the lack of exceptions is a benefit of Go. The verbosity of error handling is problematic and seems indicative of a need for a better abstraction. And with respect to your issue of Java exceptions -- I don't know what you mean by "somewhere inside". Did you examine the stack trace?

[Edited: added "of error handling"]

Re: Go version 1 is released

#162
post #90

Earlier quoted context omitted.

Chrome could not be written in Go, due to the stop-the-world GC. 200ms GC pauses are completely unacceptable for a web browser.

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.

I'm quoting the numbers that Vitess observed.

Re: Go version 1 is released

#163

Earlier quoted context omitted.

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…

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.

Re: Go version 1 is released

#164

Earlier quoted context omitted.

Why would you move from Haskell to Go? There's a night-and-day difference between them. I don't understand why you'd switch to a language because of the features it's lacking, unless you think those features are a bad thing (and I have yet to see a reason why generics and TCO are a bad thing).

Of course they are not a bad thing. It's just that Go has character. It doesn't have generics or C++-style classes just because every other language has them. I respect that.

Go has C++-style classes. Anonymous fields are just C++ multiple inheritance with a different name (and without virtual functions or downcasts).

Re: Go version 1 is released

#165

Earlier quoted context omitted.

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…

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…

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.

Re: Go version 1 is released

#166

Earlier quoted context omitted.

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…

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 i…

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.

Re: Go version 1 is released

#167

Earlier quoted context omitted.

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 i…

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…

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.

Re: Go version 1 is released

#168

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN