14 ms·

The State of Go

231 points by xkarga00 12y ago

bdcravens 12y ago
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)
- enneff 12y ago
  I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?) To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.
  - leereeves 12y ago
    I think bdcravens means that to install Go from source on, say, a new Linux box, we will have to download a binary version of Go first, even though we probably already have gcc. What happens if this catches on, and PyPy replaces CPython, and other languages do the same? Hassles for those who prefer to install from source, and potentially a lot of duplication of effort writing compiler backends in every language.
    - EugeneOZ 12y ago
      So you think all compilers should be written in C exclusively?
      - leereeves 12y ago
        No, I was just pointing out a drawback. Of course there are advantages too. In this particular case, though, I wonder why the Go team is planning to spend a lot of effort rewriting an already existing compiler. Rewriting a popular project from scratch can be a dangerous temptation.
        pkroll 12y ago
        They explain why in detail here: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Also, you don't have to download a binary of Go to compile the latest Go. You can download the Go source back when it was compiled by C, compile it, and then compile the later, Go-sourced versions, if for any reason you need to go that far.
        4ad 12y ago
        The compiler is not rewritten, it is automatically translated from C, to Go: http://golang.org/s/go13compiler http://golang.org/s/go13compiler http://talks.golang.org/2014/c2go.slide#1 http://talks.golang.org/2014/c2go.slide#1 https://www.youtube.com/watch?v=QIE5nV5fDwA https://www.youtube.com/watch?v=QIE5nV5fDwA
    - nosefrog 12y ago
      > What happens if this catches on I don't understand your comment, because we already live in your nightmare scenario: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#List_of_languages_having_self-hosting_compilers http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#L... In practice, it isn't a big deal. When was the last time you worried about the language your compiler was written in? > potentially a lot of duplication of effort writing compiler backends in every language. That's also the state of things for every compiler that doesn't use LLVM or compiles to another language.
      - leereeves 12y ago
        I agree the installation issues are fairly trivial; they were just a response to the original comment. But the duplication of effort (which won't end when the "GoGo" compiler is ready to replace cgo), and a potential freeze in Go while "GoGo" catches up, are more serious drawbacks. Yes, that is a trade-off other compiler teams have made, and it may be the right choice for Go as well, but it should be (and no doubt has been) considered.
- andrewchambers 12y ago
  They want things in c unless they are tools for a language other than c. In which case it can be in that language.
- andrewchambers 12y ago
  They want things in c unless they are tools for a language other than c. In which case it can be in that language.
justinsb 12y ago
> Better bindings for calling Go from Java. 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.
- eternalban 12y ago
  You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
  - enneff 12y ago
    > 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.
    - tylertreat 12y ago
      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.
      - enneff 12y ago
        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.
krenoten 12y ago
> Now running Linux, FreeBSD, OpenBSD, and Plan 9 builders on Google Compute Engine. (OS X, Windows coming soon.) What purpose does putting work into Plan 9 support serve other than wastefully gratifying Rob Pike? Most Googlers I've spoken to despise this guy's reactionary lordship over the project, and seeing stuff like this lends evidence to the idea of it being a North Korean situation.
- asiekierka 12y ago
  The Plan 9 support was contributed by other people. I'm sure that if there was nobody left to maintain it, it would have been dropped long ago.
- zellyn 12y ago
  > Most Googlers I've spoken to despise this guy's reactionary lordship over the project Wat‽ Talk to more of us. From where I sit (ie. not related in any way, just an observer who happens to be a Googler) the go team is fantastic.
  - crawshaw 12y ago
    That's really nice of you to say. Thank you.
    - pacala 12y ago
      As a Xoogler with some exposure to Go, let me second: * Go is an excellent tool for getting things done. * Go is great for reading large amounts of other people's code. * Go team is truly impressive. I expect Go to only get better.
- enneff 12y ago
  Rob Pike has nothing to do with the Plan 9 port of Go. It has been entirely driven by the outside community. I don't think Rob has used Plan 9 in years. > Most Googlers I've spoken to despise this guy's reactionary lordship over the project, This is pure nonsense.
omni 12y ago
Breaking the mouse entirely probably isn't the greatest of frontend design patterns.
- icedog 12y ago
  Besides the arrow keys, you can move forwards or backwards by clicking on the left or right edges of a slide.
  - zellyn 12y ago
    You can also click on the vertical area between slides to go forward/back.
    - integraton 12y ago
      Also known as "easter egg navigation."
      - enneff 12y ago
        It's a tool for giving presentations, not necessarily for reading them. But I've just sent a change to add some help text to these pages: https://go-review.googlesource.com/4910 https://go-review.googlesource.com/4910 edit: The change is now live. No more easter egg navigation. Yay!
  - sdenton4 12y ago
    The left and right buttons also do the trick.
- simoncion 12y ago
  How is the mouse broken? I can * See my mouse pointer * Right-click and bring up the right-click menu * Click on the link in the second slide * Drag to select text Chromium 40 on Linux
deleted 12y ago
[deleted]
frabcus 12y ago
There were some great new tools mentioned on there - like "callgraph" for plotting the callgraph. I can't however find any instructions how to download and install them. Anyone able to help me?
- enneff 12y ago
  go get golang.org/x/tools/cmd/callgraph Or similar for any of these commands: http://godoc.org/golang.org/x/tools/cmd http://godoc.org/golang.org/x/tools/cmd
arsv 12y ago
> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.
- enneff 12y ago
  http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.
  - arsv 12y ago
    > A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind?
    - enneff 12y ago
      > "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope. https://github.com/golang/go/issues/6853 https://github.com/golang/go/issues/6853
wereHamster 12y ago
> In general, pull request culture is not about code review. 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).
- mapleoin 12y ago
  Agreed. What I like most about GitHub pull requests is that they encourage splitting commits into smaller ones. Gerrit is focused on doing a change in one big commit.
  - enneff 12y ago
    Actually, the Gerrit workflow is pretty agnostic about whether you use one or many commits. In general, it's poor form to send massive commits anyway. Those poor reviewers!
- justinmk 12y ago
  > where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests) Yes, we try to keep PRs small. But they also need to be meaningful, and sometimes they require (many) more reworks than expected. [1] https://github.com/neovim/neovim/pull/1820 https://github.com/neovim/neovim/pull/1820
  - falcolas 12y ago
    Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository. https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742
boulos 12y ago
Does GitHub still not support "fast-forward only" commits? The "ugly merge" thing is easily avoided with a rebase before committing.
- sytse 12y ago
  GitLab CEO here. Both GitHub and GitLab normally always create a merge commit when accepting a merge request in the web UI. GitLab EE has a rebase feature where you can accept merge requests by automatically rebasing them just before merging, for more information see https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-released/ https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...
  - sytse 12y ago
    I see this is down-voted (after being up-voted initially). I thought it was interesting that GitLab allows you to accept pull/merge requests without creating a merge commit. Should I not have included the url? Edit: Thanks for re-upvoting it
- geofft 12y ago
  From the web interface, no, but you can close PRs with `git push` just fine.
  - boulos 12y ago
    I mean the option to explicitly block any changes that generate a merge (that isn't a simple fast forward). You can set this on a git repo you fully control, but IIRC you can't do this on GitHub. So yes, it works fine until someone accidentally hits the big green button and generates a "real" merge.
nawitus 12y ago
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 request culture is not about code review." I have no idea what this means.
- admax88q 12y ago
  They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.
  - notnowlewis 12y ago
    One of the previous slides says they are using Gerrit.
  - sytse 12y ago
    GitLab CEO here, I completely agree with your observation that people coming from SVN have a hard time adjusting to non-linear history. At GitLab we recommend embracing it https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/ But we also believe in the freedom to do what you want, see there is a version of GitLab with automatic rebasing to allow a clean linear history without having to rebase by hand https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-released/ https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...
  - Mithaldu 12y ago
    > I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge is an octopus merge, the complexity of the code necessitating inspection to find the root cause of a bug straight-up explodes. Meanwhile with a linear history it's not only easy, but automatable to find a commit that breaks a thing. I do realize that you may not have had the displeasure yet to be in the situation to learn these things. Please feel free to consider yourself fortunate, but please also do try to understand that the things i just wrote are in fact simple observation of realities.
inglor 12y ago
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.
- boulos 12y ago
  Each slide was okay when viewed horizontally, but then advancing then shows the damn address bar. I had to annoyingly advance, rotate, rotate back, and then read. After a while I just gave up on the titles...
- scrollaway 12y ago
  It's hijacking Alt+Left/Alt+Right (back/forward in the browser) too. Nasty.
Mithaldu 12y ago
Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 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 a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR. Comments are sent as they are written; you cannot "draft" comments. How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.) To create a patch one must fork the repository publicly (weird and unnecessary). 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. In general, pull request culture is not about code review. A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible. Edit: 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 and baroque: https://golang.org/doc/contribute.html https://golang.org/doc/contribute.html
- kasey_junk 12y ago
  > What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version control system we are talking about after all. As for their claim about pull request culture, again I'm not sure what they specifically mean, but I find the github code review tools to be very rudimentary and suspect that lots of other people with experience with more sophisticated code review workflows feel the same way. Github is a great service for some things but it certainly is not centrally about code review.
  - Mithaldu 12y ago
hueving 12y ago
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.
- enneff 12y ago
  That's exactly what we do, and we need to change the commit hash because we want to include the review information in the commit message. Not sure why this is "insane."
  - hueving 12y ago
    It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes. Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point? Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say patch c depends on b, which depends on a. Now say that patch c requires a change that merged into master. Because you can't merge into your development branch, you have to rebase c AND b AND a. This really pissed of the owners of b and a because it shows up as a new changset and wipes out votes. God forbid you depend on two different patches that each have separate dependencies. You can use the merge commit to add the review information if you want. Then you don't have to molest the code change commit.
    - enneff 12y ago
      One nice thing about Git is it lets you choose your workflow. Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit. We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.
      - hueving 12y ago
didyoucheckthe 12y ago
I'm sorry, but the Go Gopher's eyes[1] will always remind me of boobs. [1]: https://talks.golang.org/2015/state-of-go.slide#21 https://talks.golang.org/2015/state-of-go.slide#21
- enneff 12y ago
  This probably reveals more about you than anything else.
- nutate 12y ago
  MFW I read this: http://makeitthentelleverybody.com/wp-content/uploads/2014/07/coasterdogteeth.jpg http://makeitthentelleverybody.com/wp-content/uploads/2014/0...
  - nutate 12y ago
    It would seem no one got the joke that this is a pencil drawing by Renee French illustrator of the Go Gopher.
    - enneff 12y ago
      I got it, and laughed :-)
- GFK_of_xmaspast 12y ago
  Grow up.
- AwesomeTogether 12y ago
  Thank you, I agree
falcolas 12y ago
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? Better than relying on the browser as an editor. I agree, though, the public repository requirement for making a PR is a bit awkward.
- scrollaway 12y ago
  > which to my eyes is more useful than a "pretty" repository. A pretty history is extremely important when you need to attract new contributors to your repository. I've maintained extremely clean git logs and extremely nasty ones too. New contributors are immediately turned off in the latter case, because a good developer will generally git log extremely early when discovering a new project.
  - rdtsc 12y ago
    It is a false dichotomy. You can have a dirty repository history with fast forward merges as well. And you can have a clean repository history with explicit merges. As I wrote in a sibling comment, feature branch commits should be rebased to looks clean and meaningful (squashed in some cases if needed) but then merged into main/master branch using --no-ff flag in order to generate a merge commit.
    - Mithaldu 12y ago
      Here's my specific issue with that: Even in such a merge it would be possible for someone to hide a change in the merge commit, and due to the nature of git it is quite difficult to figure out with confidence whether a merge commit contains additional changes or not. I much prefer the rebase/merge no ff approach over the common "just merge whatever the fuck whenever", but due to the possibility of hidden details in merge commits, i prefer a linear history.
jakub_g 12y ago
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. 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). 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!) :) https://github.com/jakub-g/gh-code-review-assistant https://github.com/jakub-g/gh-code-review-assistant
pg_is_a_butt 12y ago
this post has to be a joke, right? none of the things on the first page are universally true.
ak217 12y ago
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 inside the PR interface, especially in light of the fact that they can be edited. Cannot compare differences between patch sets. You most certainly can. Just use branch/revision compare. To create a patch one must fork the repository publicly (weird and unnecessary). Also immaterial. Accepting a patch creates a "merge commit" (ugly repo history). 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. In general, pull request culture is not about code review. WTF? Sounds like a strong case of NIH.
- enneff 12y ago
  > 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.
  - jaimeyap 12y ago
    A lot of people commenting here probably haven't had the experience of working with mature pre-submit code review tools. It's funny how much of an opinion people seem to have about things they don't know about. I'm shocked at how bad Githubs PR review UI is given how much funding they have had for so many years. Even abandoned side projects like Rietveld have vastly better review UIs and workflows for larger patch sets.
jrochkind1 12y ago
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' 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. 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.
- mdwrigh2 12y ago
  They use Gerrit: https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/
- XorNot 12y ago
  Moreover, you can fork a repo, then work on the actual repo in whatever form you want. Most of my forks are just to maintain public branches, and I have any number of private or unfinished stuff on my home machine.
omeid2 12y ago
> In general, pull request culture is not about code review. 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.
Blackthorn 12y ago
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!
- lelf 12y ago
  Yeah, I'd prefer all those comments to be about the bootstrapping and GC (they can even keep the same tone, it'd be funny at least).
- gtirloni 12y ago
  Agreed. However, the original submission called attention to that slide specifically, not the whole State of Go presentation. So people kept on topic :)
- abhinavg 12y ago
  Right? Instead of discussing the rest of the content of the slides, let's all discuss one slide. Out of context these comments read like they're in response to a poorly written article with an inflammatory title like "Why GitHub sucks".
- hueving 12y ago
  What do suspect when someone injects pretty strong opinions into a slide and presents them as factual in a major project like this? What do you think would happen if there was a slide that mentioned that the culture around UTF was mainly about misogyny so they weren't going to support it?
zak_mc_kracken 12y ago
> To create a patch one must fork the repository publicly (weird and unnecessary). 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. Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.
- dsymonds 12y ago
  We expect contributors to sync and run all the tests. The public forking is the weird and unnecessary part. Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.
  - zak_mc_kracken 12y ago
    What is so disturbing about the "public" part that it's worth discarding the whole approach?
    - dsymonds 12y ago
      No-one said "disturbing". It's weird if you've come from an environment where you do your individual work in private, and only show it to people when it's ready to be committed/merged. No-one said that that point alone is worth discarding the whole approach. You're nitpicking a single bullet point from around a half dozen points that stacked up.
rsarsarsa 12y ago
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.
- rsarsarsa 12y ago
  Just downvote if that make you feel good because your poor head can't prove go is better anywhere :P
- Skinney 12y ago
  Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1. Rust cannot guarantee multi-threaded memory safety in all cases. Care, as in Go, must still be taken. 2. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3. Rust and Go's error handling is based on the same principle: force the user to deal with errors, instead of ignoring them. While Go's way of handling things can be a little more verbose, in principle I don't see the big difference. 4. Alot of people will argue that this is a good thing. Using a GC by default makes certain things easier, like writing datastructures (especially immutable ones) without reaching for 'unsafe' code. Having a GC also means you don't have to mind memory fragmentation, as you do with a manually malloc/free based allocation. 5. RAII is great, but loses some of it's use in GC based language. Defer is, IMHO, a much better option than the other solutions I've seen in other GC languages (Javas try-with-resources and C#s using) Just because you can do the same thing in language X, doesn't make language Y obsolete. Advantage of Go, for me, is less verbose code (implicit interfaces for the win) and a fantastic, stable and huge standard library. I also like the strict compiler, and that the language has a GC by default, makes certain things easier, and for most tasks I don't need the predictability that you get with manual memory management.
  - Jweb_Guru 12y ago
    While I do generally agree with what you've written, I do want to take issue with point (1). Rust is actually intended to guarantee multi-threaded memory safety in safe code. Period. If you can get it to behave otherwise, it's a bug in Rust.
CatDevURandom 12y ago
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: 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. 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. 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. 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. Overall, I've found the community to be friendly both online and in person. 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.
drigao_ssj3 12y ago
https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEmhmkx_k-CqBWeA https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEm...

231 points by xkarga00 12y ago

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)

enneff 12y ago
I don't understand the basis of your question. What does the bootstrapping process for a compiler have to do with "OSS's value proposition?" (By OSS I'm assuming you mean "Open Source Software"?) To build gcc, you need a C compiler. To build Go, you need a Go compiler. To compile anything you need to start with some kind of compiler.
- leereeves 12y ago
  I think bdcravens means that to install Go from source on, say, a new Linux box, we will have to download a binary version of Go first, even though we probably already have gcc. What happens if this catches on, and PyPy replaces CPython, and other languages do the same? Hassles for those who prefer to install from source, and potentially a lot of duplication of effort writing compiler backends in every language.
  - EugeneOZ 12y ago
    So you think all compilers should be written in C exclusively?
    - leereeves 12y ago
      No, I was just pointing out a drawback. Of course there are advantages too. In this particular case, though, I wonder why the Go team is planning to spend a lot of effort rewriting an already existing compiler. Rewriting a popular project from scratch can be a dangerous temptation.
      - pkroll 12y ago
        They explain why in detail here: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Also, you don't have to download a binary of Go to compile the latest Go. You can download the Go source back when it was compiled by C, compile it, and then compile the later, Go-sourced versions, if for any reason you need to go that far.
      - 4ad 12y ago
        The compiler is not rewritten, it is automatically translated from C, to Go: http://golang.org/s/go13compiler http://golang.org/s/go13compiler http://talks.golang.org/2014/c2go.slide#1 http://talks.golang.org/2014/c2go.slide#1 https://www.youtube.com/watch?v=QIE5nV5fDwA https://www.youtube.com/watch?v=QIE5nV5fDwA
  - nosefrog 12y ago
    > What happens if this catches on I don't understand your comment, because we already live in your nightmare scenario: http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#List_of_languages_having_self-hosting_compilers http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#L... In practice, it isn't a big deal. When was the last time you worried about the language your compiler was written in? > potentially a lot of duplication of effort writing compiler backends in every language. That's also the state of things for every compiler that doesn't use LLVM or compiles to another language.
    - leereeves 12y ago
      I agree the installation issues are fairly trivial; they were just a response to the original comment. But the duplication of effort (which won't end when the "GoGo" compiler is ready to replace cgo), and a potential freeze in Go while "GoGo" catches up, are more serious drawbacks. Yes, that is a trade-off other compiler teams have made, and it may be the right choice for Go as well, but it should be (and no doubt has been) considered.
andrewchambers 12y ago
They want things in c unless they are tools for a language other than c. In which case it can be in that language.
andrewchambers 12y ago
They want things in c unless they are tools for a language other than c. In which case it can be in that language.

justinsb 12y ago

> Better bindings for calling Go from Java. 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.

eternalban 12y ago
You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.
- enneff 12y ago
  > 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.
  - tylertreat 12y ago
    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.
    - enneff 12y ago
      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.

krenoten 12y ago

> Now running Linux, FreeBSD, OpenBSD, and Plan 9 builders on Google Compute Engine. (OS X, Windows coming soon.) What purpose does putting work into Plan 9 support serve other than wastefully gratifying Rob Pike? Most Googlers I've spoken to despise this guy's reactionary lordship over the project, and seeing stuff like this lends evidence to the idea of it being a North Korean situation.

asiekierka 12y ago
The Plan 9 support was contributed by other people. I'm sure that if there was nobody left to maintain it, it would have been dropped long ago.
zellyn 12y ago
> Most Googlers I've spoken to despise this guy's reactionary lordship over the project Wat‽ Talk to more of us. From where I sit (ie. not related in any way, just an observer who happens to be a Googler) the go team is fantastic.
- crawshaw 12y ago
  That's really nice of you to say. Thank you.
  - pacala 12y ago
    As a Xoogler with some exposure to Go, let me second: * Go is an excellent tool for getting things done. * Go is great for reading large amounts of other people's code. * Go team is truly impressive. I expect Go to only get better.
enneff 12y ago
Rob Pike has nothing to do with the Plan 9 port of Go. It has been entirely driven by the outside community. I don't think Rob has used Plan 9 in years. > Most Googlers I've spoken to despise this guy's reactionary lordship over the project, This is pure nonsense.

omni 12y ago

Breaking the mouse entirely probably isn't the greatest of frontend design patterns.

icedog 12y ago
Besides the arrow keys, you can move forwards or backwards by clicking on the left or right edges of a slide.
- zellyn 12y ago
  You can also click on the vertical area between slides to go forward/back.
  - integraton 12y ago
    Also known as "easter egg navigation."
    - enneff 12y ago
      It's a tool for giving presentations, not necessarily for reading them. But I've just sent a change to add some help text to these pages: https://go-review.googlesource.com/4910 https://go-review.googlesource.com/4910 edit: The change is now live. No more easter egg navigation. Yay!
- sdenton4 12y ago
  The left and right buttons also do the trick.
simoncion 12y ago
How is the mouse broken? I can * See my mouse pointer * Right-click and bring up the right-click menu * Click on the link in the second slide * Drag to select text Chromium 40 on Linux

deleted 12y ago

[deleted]

frabcus 12y ago

There were some great new tools mentioned on there - like "callgraph" for plotting the callgraph. I can't however find any instructions how to download and install them. Anyone able to help me?

enneff 12y ago
go get golang.org/x/tools/cmd/callgraph Or similar for any of these commands: http://godoc.org/golang.org/x/tools/cmd http://godoc.org/golang.org/x/tools/cmd

arsv 12y ago

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

enneff 12y ago
http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.
- arsv 12y ago
  > A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind?
  - enneff 12y ago
    > "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope. https://github.com/golang/go/issues/6853 https://github.com/golang/go/issues/6853

wereHamster 12y ago

> In general, pull request culture is not about code review. 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).

mapleoin 12y ago
Agreed. What I like most about GitHub pull requests is that they encourage splitting commits into smaller ones. Gerrit is focused on doing a change in one big commit.
- enneff 12y ago
  Actually, the Gerrit workflow is pretty agnostic about whether you use one or many commits. In general, it's poor form to send massive commits anyway. Those poor reviewers!
justinmk 12y ago
> where you often have many iterations or the diffs are large). But for many other projects the UI that GitHub provides is sufficient GitHub is painful for non-trivial reviews. Biggest WTFs: - No comment threading (or at least collapsing). On a PR with 100 comments[1] it is unlikely that those revisiting the thread need to see (and download, and render...) the first bazillion comments. - Source "annotations" are lost after a force-push (why not keep around a read-only view of old comments? We have lost some valuable discussions on GH pull requests) Yes, we try to keep PRs small. But they also need to be meaningful, and sometimes they require (many) more reworks than expected. [1] https://github.com/neovim/neovim/pull/1820 https://github.com/neovim/neovim/pull/1820
- falcolas 12y ago
  Wait. Force pushes? That's a terrible habit to get into; force pushes have decimated more than a few a open source project's repository. https://news.ycombinator.com/item?id=6713742 https://news.ycombinator.com/item?id=6713742

boulos 12y ago

Does GitHub still not support "fast-forward only" commits? The "ugly merge" thing is easily avoided with a rebase before committing.

sytse 12y ago
GitLab CEO here. Both GitHub and GitLab normally always create a merge commit when accepting a merge request in the web UI. GitLab EE has a rebase feature where you can accept merge requests by automatically rebasing them just before merging, for more information see https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-released/ https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...
- sytse 12y ago
  I see this is down-voted (after being up-voted initially). I thought it was interesting that GitLab allows you to accept pull/merge requests without creating a merge commit. Should I not have included the url? Edit: Thanks for re-upvoting it
geofft 12y ago
From the web interface, no, but you can close PRs with `git push` just fine.
- boulos 12y ago
  I mean the option to explicitly block any changes that generate a merge (that isn't a simple fast forward). You can set this on a git repo you fully control, but IIRC you can't do this on GitHub. So yes, it works fine until someone accidentally hits the big green button and generates a "real" merge.

nawitus 12y ago

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 request culture is not about code review." I have no idea what this means.

admax88q 12y ago
They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.
- notnowlewis 12y ago
  One of the previous slides says they are using Gerrit.
- sytse 12y ago
  GitLab CEO here, I completely agree with your observation that people coming from SVN have a hard time adjusting to non-linear history. At GitLab we recommend embracing it https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/ But we also believe in the freedom to do what you want, see there is a version of GitLab with automatic rebasing to allow a clean linear history without having to rebase by hand https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-released/ https://about.gitlab.com/2014/12/22/gitlab-7-6-and-ci-5-3-re...
- Mithaldu 12y ago
  > I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge is an octopus merge, the complexity of the code necessitating inspection to find the root cause of a bug straight-up explodes. Meanwhile with a linear history it's not only easy, but automatable to find a commit that breaks a thing. I do realize that you may not have had the displeasure yet to be in the situation to learn these things. Please feel free to consider yourself fortunate, but please also do try to understand that the things i just wrote are in fact simple observation of realities.

inglor 12y ago

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.

boulos 12y ago
Each slide was okay when viewed horizontally, but then advancing then shows the damn address bar. I had to annoyingly advance, rotate, rotate back, and then read. After a while I just gave up on the titles...
scrollaway 12y ago
It's hijacking Alt+Left/Alt+Right (back/forward in the browser) too. Nasty.

Mithaldu 12y ago

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 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 a remote to yours and use your familiar tools. If possible and done, a fast-forward merge + push will also close the PR. Comments are sent as they are written; you cannot "draft" comments. How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.) To create a patch one must fork the repository publicly (weird and unnecessary). 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. In general, pull request culture is not about code review. A strong claim, but one without any justification, and which is, in my experience, as far from the truth as possible. Edit: 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 and baroque: https://golang.org/doc/contribute.html https://golang.org/doc/contribute.html

kasey_junk 12y ago
> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version control system we are talking about after all. As for their claim about pull request culture, again I'm not sure what they specifically mean, but I find the github code review tools to be very rudimentary and suspect that lots of other people with experience with more sophisticated code review workflows feel the same way. Github is a great service for some things but it certainly is not centrally about code review.
- Mithaldu 12y ago

hueving 12y ago

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.

enneff 12y ago
That's exactly what we do, and we need to change the commit hash because we want to include the review information in the commit message. Not sure why this is "insane."
- hueving 12y ago
  It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes. Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point? Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say patch c depends on b, which depends on a. Now say that patch c requires a change that merged into master. Because you can't merge into your development branch, you have to rebase c AND b AND a. This really pissed of the owners of b and a because it shows up as a new changset and wipes out votes. God forbid you depend on two different patches that each have separate dependencies. You can use the merge commit to add the review information if you want. Then you don't have to molest the code change commit.
  - enneff 12y ago
    One nice thing about Git is it lets you choose your workflow. Our general workflow for the Go project is to review single commits, and sometimes do major new work in feature branches. When we submit a single change we cherry-pick. When we merge trees, we create a merge commit. We don't write commits that depend on other pending work. That's overly complicated (IMO) even if you always use merge commits.
    - hueving 12y ago

didyoucheckthe 12y ago

I'm sorry, but the Go Gopher's eyes[1] will always remind me of boobs. [1]: https://talks.golang.org/2015/state-of-go.slide#21 https://talks.golang.org/2015/state-of-go.slide#21

enneff 12y ago
This probably reveals more about you than anything else.
nutate 12y ago
MFW I read this: http://makeitthentelleverybody.com/wp-content/uploads/2014/07/coasterdogteeth.jpg http://makeitthentelleverybody.com/wp-content/uploads/2014/0...
- nutate 12y ago
  It would seem no one got the joke that this is a pencil drawing by Renee French illustrator of the Go Gopher.
  - enneff 12y ago
    I got it, and laughed :-)
GFK_of_xmaspast 12y ago
Grow up.
AwesomeTogether 12y ago
Thank you, I agree

falcolas 12y ago

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? Better than relying on the browser as an editor. I agree, though, the public repository requirement for making a PR is a bit awkward.

scrollaway 12y ago
> which to my eyes is more useful than a "pretty" repository. A pretty history is extremely important when you need to attract new contributors to your repository. I've maintained extremely clean git logs and extremely nasty ones too. New contributors are immediately turned off in the latter case, because a good developer will generally git log extremely early when discovering a new project.
- rdtsc 12y ago
  It is a false dichotomy. You can have a dirty repository history with fast forward merges as well. And you can have a clean repository history with explicit merges. As I wrote in a sibling comment, feature branch commits should be rebased to looks clean and meaningful (squashed in some cases if needed) but then merged into main/master branch using --no-ff flag in order to generate a merge commit.
  - Mithaldu 12y ago
    Here's my specific issue with that: Even in such a merge it would be possible for someone to hide a change in the merge commit, and due to the nature of git it is quite difficult to figure out with confidence whether a merge commit contains additional changes or not. I much prefer the rebase/merge no ff approach over the common "just merge whatever the fuck whenever", but due to the possibility of hidden details in merge commits, i prefer a linear history.

jakub_g 12y ago

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. 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). 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!) :) https://github.com/jakub-g/gh-code-review-assistant https://github.com/jakub-g/gh-code-review-assistant

pg_is_a_butt 12y ago

this post has to be a joke, right? none of the things on the first page are universally true.

ak217 12y ago

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 inside the PR interface, especially in light of the fact that they can be edited. Cannot compare differences between patch sets. You most certainly can. Just use branch/revision compare. To create a patch one must fork the repository publicly (weird and unnecessary). Also immaterial. Accepting a patch creates a "merge commit" (ugly repo history). 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. In general, pull request culture is not about code review. WTF? Sounds like a strong case of NIH.

enneff 12y ago
> 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.
- jaimeyap 12y ago
  A lot of people commenting here probably haven't had the experience of working with mature pre-submit code review tools. It's funny how much of an opinion people seem to have about things they don't know about. I'm shocked at how bad Githubs PR review UI is given how much funding they have had for so many years. Even abandoned side projects like Rietveld have vastly better review UIs and workflows for larger patch sets.

jrochkind1 12y ago

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' 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. 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.

mdwrigh2 12y ago
They use Gerrit: https://code.google.com/p/gerrit/ https://code.google.com/p/gerrit/
XorNot 12y ago
Moreover, you can fork a repo, then work on the actual repo in whatever form you want. Most of my forks are just to maintain public branches, and I have any number of private or unfinished stuff on my home machine.

omeid2 12y ago

> In general, pull request culture is not about code review. 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.

Blackthorn 12y ago

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!

lelf 12y ago
Yeah, I'd prefer all those comments to be about the bootstrapping and GC (they can even keep the same tone, it'd be funny at least).
gtirloni 12y ago
Agreed. However, the original submission called attention to that slide specifically, not the whole State of Go presentation. So people kept on topic :)
abhinavg 12y ago
Right? Instead of discussing the rest of the content of the slides, let's all discuss one slide. Out of context these comments read like they're in response to a poorly written article with an inflammatory title like "Why GitHub sucks".
hueving 12y ago
What do suspect when someone injects pretty strong opinions into a slide and presents them as factual in a major project like this? What do you think would happen if there was a slide that mentioned that the culture around UTF was mainly about misogyny so they weren't going to support it?

zak_mc_kracken 12y ago

> To create a patch one must fork the repository publicly (weird and unnecessary). 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. Interestingly, I note the Go team says it's "unnecessary" but doesn't provide their alternative.

dsymonds 12y ago
We expect contributors to sync and run all the tests. The public forking is the weird and unnecessary part. Gerrit is the alternative used, and contributors have a full local clone of the git repo, with their commit, and that's private on their machine until they push it to Gerrit for review.
- zak_mc_kracken 12y ago
  What is so disturbing about the "public" part that it's worth discarding the whole approach?
  - dsymonds 12y ago
    No-one said "disturbing". It's weird if you've come from an environment where you do your individual work in private, and only show it to people when it's ready to be committed/merged. No-one said that that point alone is worth discarding the whole approach. You're nitpicking a single bullet point from around a half dozen points that stacked up.

rsarsarsa 12y ago

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.

rsarsarsa 12y ago
Just downvote if that make you feel good because your poor head can't prove go is better anywhere :P
Skinney 12y ago
Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1. Rust cannot guarantee multi-threaded memory safety in all cases. Care, as in Go, must still be taken. 2. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3. Rust and Go's error handling is based on the same principle: force the user to deal with errors, instead of ignoring them. While Go's way of handling things can be a little more verbose, in principle I don't see the big difference. 4. Alot of people will argue that this is a good thing. Using a GC by default makes certain things easier, like writing datastructures (especially immutable ones) without reaching for 'unsafe' code. Having a GC also means you don't have to mind memory fragmentation, as you do with a manually malloc/free based allocation. 5. RAII is great, but loses some of it's use in GC based language. Defer is, IMHO, a much better option than the other solutions I've seen in other GC languages (Javas try-with-resources and C#s using) Just because you can do the same thing in language X, doesn't make language Y obsolete. Advantage of Go, for me, is less verbose code (implicit interfaces for the win) and a fantastic, stable and huge standard library. I also like the strict compiler, and that the language has a GC by default, makes certain things easier, and for most tasks I don't need the predictability that you get with manual memory management.
- Jweb_Guru 12y ago
  While I do generally agree with what you've written, I do want to take issue with point (1). Rust is actually intended to guarantee multi-threaded memory safety in safe code. Period. If you can get it to behave otherwise, it's a bug in Rust.

CatDevURandom 12y ago

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: 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. 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. 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. 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. Overall, I've found the community to be friendly both online and in person. 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.

drigao_ssj3 12y ago

https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEmhmkx_k-CqBWeA https://www.youtube.com/watch?v=x8wcP-W2pTQ&list=UUysVbKMJEm...