Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go

talks.golang.org

Post reply on HN
Print view View original

121–130 of 271 posts

Re: The State of Go

#121

Post by enneff »

ak217 wrote: post #107

Can only view diffs on a single page (can be very slow). I've seen GitHub take five seconds to render a 100K line diff. In my experience all of the other tools I've used, including some of the ones listed, can take longer to render individual file sections of such a diff. It's fast enough. Comments are sent as they are written; you cannot "draft" comments. I'm a bit puzzled as to why you would need to draft comments…

> I'm a bit puzzled as to why you would need to draft comments inside the PR interface, especially in light of the fact that they can be edited.

This scenario happens often: I read through a change, making comments as I go. Then I reach some part of the change and realise "Oh, that explains why they did that in that other file!" So I go back and delete or alter my comments.

In Gerrit or Rietveld, the reviewee never sees those earlier comments.

On GitHub, the reviewee has already received the comment notifications and started responding before I have a chance to make the changes. The reviewee wastes time responding to questions to which I already know the answer. It's clunky, inefficient, and unnecessary.

It seems like you haven't used a tool like Gerrit or Rietveld. You should check them out.

Re: The State of Go

#122

Post by twotwotwo »

tylertreat wrote: post #60
enneff wrote: post #37

Earlier quoted context omitted.

> if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land. I don't think that's necessarily true. Go does a much better job than Java at letting you manage your allocations and re-use memory. You can write tight, performance-critical code in Go without resorting to 'unsafe'; it just requires care, as it does in any language.

I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.

I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). CloudFlare has it sitting in the middle of every request for some sites (in the form of Railgun, their delta compression for pages). I'm not exactly a perf ninja and got some Go code packing Wikipedia history dumps at >100 MB/s. Dropbox uses Go for, their words, "our performance-critical backends" (https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-...). So folks manage to heavy lifting with it.

I see "I couldn't possibly use X for performance reasons" here a lot, as an almost immediate response about a wide range of different tools, and two things come up in my mind: 1) you can always set the standard arbitrarily high. If you're doing AAA shoot-'em-up games or something, yes, use something else. 2) you're often not as good at tools that're new or different. It's possible you could go further with just a few more tricks about profiling or using free pools or whatever, or a little more info about how your code executes or what the runtime does. FWIW, if you hit a specific wall that's a problem for your app, folks on golang-nuts (or StackOverflow, where I've hung out sometimes) are often happy to try and help.

Hope this is more helpful than fussy. Mostly just don't want folks to be discouraged into thinking certain things are impossible when in some cases they're really being done in production out there.

Re: The State of Go

#123

Post by forgottenpass »

falcolas wrote: post #75

Personal opinion here, but I much prefer merge commits as opposed to fast forwarded commits. With a merge commit, there's one commit to revoke if something breaks, and there's one commit per PR to step through with git bisect, and more importantly it maintains history, which to my eyes is more useful than a "pretty" repository. Drafting comments... if you want to draft comments, can't you do that in a separate editor…

I much prefer merge commits as opposed to fast forwarded commits

That's cool, but it's still constraining a flexible system away from someone else's preferences. I prefer "--no-ff" myself too, but think that's irrelevant.

Re: The State of Go

#124

Post by eternalban »

enneff wrote: post #64
tylertreat wrote: post #60

Earlier quoted context omitted.

I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.

I disagree with "channels are slow". They may be faster than you think. Defers needn't add as much overhead as they do today; this can be fixed. I think it really depends on your definition of "performance-critical". I agree Go isn't suitable for all performance-critical tasks, but it covers a vast swathe of them quite comfortably.

> this can be fixed.

I believe this and am counting on it. Go2.0 and beyond should be a solid choice.

You should also note that it is entirely understood that more mature tech e.g. JVM have had the benefit of multibillion Dollar investment by SUN, IBM, Oracle, etc.

I feel it is regrettable that (imo valid and reasonable) criticism of what is currently not up to par with this tech always seemingly requires a disclaimer that "I love Go". I have been using this language since the day it was released. I know it fairly well. I like it. But excessive hype and sensitivity around it is frankly somewhat irritating.

peace out and happy v. day Go <3

Re: The State of Go

#125

Post by enneff »

Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

Half your post is saying we should just use different tools, but we are. We're using Gerrit, that lets us work the way we want.

On the contributor instructions: note that if you just want to use plain git (and not our git-codereview tool) then you can stop at "Register with Gerrit."

We created the tool to provide a more familiar review process for the people that used our previous system.

If we took your advice and used offline diff tools, etc, we would need a similar page explaining how to do all of that. None of this convenience comes without an up front cost.

Re: The State of Go

#126

Post by MaulingMonkey »

Mithaldu wrote: post #66
lmm wrote: post #62

Earlier quoted context omitted.

Linearized histories are much harder to find bugs in. You end up looking through revisions that never existed; in SVN you merge the remote history into your local history without it ever showing up as a merge. The explicit git approach tells you something much closer to the truth. Your condescension is only hurting yourself.

Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you put a rebase of a branch on master without verifying the rebase, then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason. Frankly, i find your style of argument through implication, and through trying to disregard som…

> "Revisions that never existed" do exist

"Revision that were never built nor tested" is probably closer to the truth. Do you rewind through all your history and rebuild and retest every commit in a branch every time you rebase? Sure, they're similar, and you probably didn't mess up the merges. There's likely no subtle lingering bugs that QA's only going to catch weeks down the line. Probably.

> then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason.

Sure. But I've missed so many things in code reviews, had so many things in my own code missed in code reviews, and generally make mistakes and messes.

I do agree that simpler branch topology tend to be easier to reason about. But branches do have their advantages... and I've also found that preserving the original branch topology has helped me untangle merge mistakes that were missed, committed, and then only discovered a year or more later.

Re: The State of Go

#127

Post by eropple »

enneff wrote: post #104
eropple wrote: post #96

Earlier quoted context omitted.

I don't believe that this is true. You use the exact same patterns and tricks in both for perf-critical code: off-GC primitives and object pools rule the day. What are you considering a "much better" option available in Go? (I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing; it may be slightly more terse, but fundamentally the same behavior.)

Values ("off-GC primitives?") are first class-citizens in Go. Stack-allocated structs have much more value than you think.

More value than I think? I'm pretty sure that I know exactly their value. I'll maintain that stack-allocated structs are a nice-to-have on top of the sort of stack-allocated primitives that Java provides; I'd like to have those structs as a convenience when I write Java, which is why I alluded to terseness in my prior post. But there's very little (or should be, I suppose, depending on implementation) performance difference to speak of between a struct and parallel declaration of the same values.

Re: The State of Go

#128

Post by ptio »

nawitus wrote: post #31

What is the better alternative Go is using? "Can only view diffs on a single page" You don't need to use GitHub to view diffs. "To create a patch one must fork the repository publicly (weird and unnecessary)." I don't think it's weird. "Accepting a patch creates a "merge commit" (ugly repo history)." You don't need to have a merge commit, although I don't think that creates an ugly repo history. "In general, pull req…

> "In general, pull request culture is not about code review."

Companies/organizations have different requirements for code reviews. Yes you can review code in pull requests, but in my opinion, it was not built for code reviews. In my previous company, we had a very rigorous code review process, which includes pre and post commit code reviews. We used Collaborator[1] and ReviewBoard[2] for code reviews and I totally understand why the Go team would use Gerrit over pull requests for code review.

[1] http://smartbear.com/product/collaborator/overview/ [2] https://www.reviewboard.org/

Re: The State of Go

#129

Post by xkarga00 »

enneff wrote: post #117
wereHamster wrote: post #115

Earlier quoted context omitted.

If you said "GitHub pull requests don't fit our culture" or "The GitHub pull request UI is insufficient for our needs" then it'd accept that. Both are perfectly valid reasons for preferring Gerrit. But placing this blanket statement about the whole "pull request culture" is just wrong.

We've spoken to GitHub about this. They're not happy with how PRs work, either. I stand by my statements.

I hope they are going to do something about it and someday see all the Go development happening on GitHub :)

Re: The State of Go

#130

Post by enneff »

eropple wrote: post #127
enneff wrote: post #104

Earlier quoted context omitted.

Values ("off-GC primitives?") are first class-citizens in Go. Stack-allocated structs have much more value than you think.

More value than I think? I'm pretty sure that I know exactly their value. I'll maintain that stack-allocated structs are a nice-to-have on top of the sort of stack-allocated primitives that Java provides; I'd like to have those structs as a convenience when I write Java, which is why I alluded to terseness in my prior post. But there's very little (or should be, I suppose, depending on implementation) performance dif…

You said:

> I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing;

But for me they're one of the major ways in which I control memory use in Go programs. So, yeah, I think you underestimate them. No condescension implied. Apologies if it came across that way.

I think we probably agree more than we disagree.

Post reply on HN