Edit: This commit was written to the original submission: <a href="https://talks.golang.org/2015/state-of-go.slide#7" rel="nofollow">https://talks.golang.org/2015/state-of-go.slide#7</a><p>--------------<p>It seems like these people simply don't understand Github very well.<p><pre><code> 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).
</code></pre>
Don't use the merge button, just add the requester's repo as a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR.<p><pre><code> Comments are sent as they are written; you cannot "draft" comments.
</code></pre>
How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.)<p><pre><code> To create a patch one must fork the repository publicly
(weird and unnecessary).
</code></pre>
What exactly is weird about that? It makes it possible for the requestor to craft their changes with full control, without requiring upstream to give them write access. This point is just entirely nonsensical.<p><pre><code> In general, pull request culture is not about code review.
</code></pre>
A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible.<p>Edit:<p>In light of their complaints about the need to fork, i have to say that their current contribution process can in its entirety be described as weird, unnecessary <i>and</i> baroque:<p><a href="https://golang.org/doc/contribute.html" rel="nofollow">https://golang.org/doc/contribute.html</a>
The comments here represent one of the best examples of bikeshedding I've ever seen. The deep details of go are too complex for some people to really have an opinion on but god damn does everyone want to get their voices heard about github!
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.<p>Drafting comments... if you want to draft comments, can't you do that in a separate editor? Better than relying on the browser as an editor.<p>I agree, though, the public repository requirement for making a PR is a bit awkward.
What is the better alternative Go is using?<p>"Can only view diffs on a single page"<p>You don't need to use GitHub to view diffs.<p>"To create a patch one must fork the repository publicly (weird and unnecessary)."<p>I don't think it's weird.<p>"Accepting a patch creates a "merge commit" (ugly repo history)."<p>You don't need to have a merge commit, although I don't think that creates an ugly repo history.<p>"In general, pull request culture is not about code review."<p>I have no idea what this means.
<i>Can only view diffs on a single page (can be very slow).</i><p>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.<p><i>Comments are sent as they are written; you cannot "draft" comments.</i><p>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.<p><i>Cannot compare differences between patch sets.</i><p>You most certainly can. Just use branch/revision compare.<p><i>To create a patch one must fork the repository publicly (weird and unnecessary).</i><p>Also immaterial.<p><i>Accepting a patch creates a "merge commit" (ugly repo history).</i><p>This comes closest to being a legitimate complaint. Because GitHub emphasizes recognition of contributors, it doesn't let you rewrite the commits in the PR as you merge them with the merge button, but there are multiple ways to merge on the command line that avoid the merge commit and play nice with the PR.<p><i>In general, pull request culture is not about code review.</i><p>WTF?<p>Sounds like a strong case of NIH.
> Better bindings for calling Go from Java.<p>If that is available for general Java code (i.e. uses JNI) and not just for Android, that could be really huge for Go. Writing performance-sensitive low-level code in Java is still fairly painful, wheras Go still isn't great for writing big programs. I can imagine (for example) Hadoop, Lucene/Elasticsearch and PrestoDB all using this.
Yeah, I dunno, the github PR 'culture' I've engaged in has often in fact been about code review. I don't see any problems with forking a repo publicaly to make a PR (what is there to hide?), am not really bothered by merge commits (and in some cases they are actually quite useful, some people prefer them, it's a point of some contention), and I don't really understand what they mean by 'Comments are sent as they are written; you cannot "draft" comment'<p>But to each their own -- I'm curious what alternative system (if any) of accepting patches they have. If it's emailed git patches on a listserv, then I would definitely find it a barrier to submitting patches, myself, compared to github PR's.<p>I think in general, github PR's have proven succesful at soliciting code contributions from a wider field, which seems to be the goal of their UI (over command line git itself). Of course, this can seem a downside too, as committers have to spend time dealing with those submissions.
> In general, pull request culture is not about code review.<p>This is not true. There are many projects on GitHub which do extensive code reviews on pull requests. It may not be as nice as Gerrit for the type of project like Go (where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient (and arguably more efficient than Gerrit).
I'm late to the hate-parade but I did want to chime in to say how much I appreciate all the work the go team has put into the language, and tools. Go is a wonderful tool to get things done with. I recently rewrote a cross platform `enterprise` app from java (25k LOC) to go (8k LOC) and saw improvements in readability, memory footprint, and overall quality. Some notes on my experiences so far:<p>Go binary size is a non-issue for most software. The java-rewrite I mentioned above went from a 80MB or so binary, to a 8MB executable. That said, there's been a few occasions when I've really wanted to use go for an embedded project, but couldn't due to it's size.<p>I read somewhere, someone said of go, "you'll come for the concurrency, but you'll stay for the interfaces. This is very true for me.<p>Generics. Go's red herring. Sure, there's been a handful of occasions where generics would have saved me some boiler-plate, but it's not been a pain point for me.<p>Tooling, from fmt, vet, to unit testing are all first rate. However, I wish there was a better debugger option for go. I know that gdb works with go (and with a great deal of difficulty if you develop with OSX) but I'm probably not alone when I say I really dislike GDB.<p>Overall, I've found the community to be friendly both online and in person.<p>As an aside, I've noticed much of the recent vitriol towards Go seems to come from the Rust crowd which I think is too bad. I enjoy both. Languages are not a zero-sum game. Who knows, the hate means Go has finally arrived.
There were some great new tools mentioned on there - like "callgraph" for plotting the callgraph.<p>I can't however find any instructions how to download and install them. Anyone able to help me?
This presentation looks horrible on the iPhone screen. I wonder if they couldn't spend a few minutes to point phone users to a working version or at least not lock the viewport size so mobile users could pinch-zoom out.
I tried to mitigate some of the pains with GitHub code review UI by writing a helper userscript to track the progress of big code reviews. Some of the items listed in the link can be fixed in this way.<p>The idea is to expand/collapse files, store progress of the review and collapse status of the files in local storage of the browser, so you can stop and resume at any time (I also have in mind serializing this stuff into a hash in the URL so you can forward it to the other machine for instance, and recreate the progress there).<p>I work on it every now and then and have a number of items in the backlog. If someone is interested to contribute I'll be happy to accept pull requests (sic!) :)<p><a href="https://github.com/jakub-g/gh-code-review-assistant" rel="nofollow">https://github.com/jakub-g/gh-code-review-assistant</a>
> In general, pull request culture is not about code review.<p>A lot of people seem to here insist that this is somewhat even remotely true. This is not. Look through Docker's pull requests on Github, look at their CI hooks.
Gerrit still produces merge commits unless they have it configured to cherry-pick onto master, which is insane because you are changing the commit sha at that point.
Does GitHub still not support "fast-forward only" commits? The "ugly merge" thing is easily avoided with a rebase before committing.
> To create a patch one must fork the repository publicly (weird and unnecessary).<p>I think it's very fair to demand from a contributor to sync and build the entire app before they're allowed to submit a patch.<p>Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.
> Where we're at in February 2015<p>Still producing 1.3M hello world executables.<p>I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.
Most of career has been spent doing web programming, so maybe I'm ignorant, but if you have to build Go with a Go binary, instead of C, doesn't this break OSS's value proposition? (obviously I'd have to start with a C compiler, but that feels a bit purer in my mind, as I can start with a pretty bare-bones OS)
I think go is failed, compare to rust.
1. not memory safe on multi-thread
2. no generic support
3. error handle is full of pain compare to rust's Result<T>, Option<T> and try!
4. gc can't be disable
5. no RAII support, defer can be forgot
light-weight thread (spawn) and channel (thread safe FIFO) already exist in rust that make golang more meanless.
If you think still any advantage of go please tell me.