Hacker News new | past | comments | ask | show | jobs | submit login
Go is moving to GitHub (groups.google.com)
686 points by davecheney on Nov 14, 2014 | hide | past | favorite | 236 comments

I think this is Google quietly admitting that Google Code is all but dead. They will not completely get rid of it, but I would not be surprised if they switch it to read only mode sometime soon.

This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long time.

Kudos to the Github team for well and truly making it as the premier code hosting and collaboration tool for developers and lovers of open source. It only goes up from here.

Admitting Code is going nowhere, and seemingly for the first time in living memory, playing geek marketing catch-up with Microsoft :) I really love the new MS.

As someone has already mentioned Google already has stuff on Github.

Dart: https://github.com/dart-lang

And lots of other stuff:


Yeah - AFAICT, Go is only taking this long because custom import path checking [1] needs to land in Go 1.4 first to make sure that users get rid of their pointers to code.google.com.

[1] https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7v...

Not limited to Google's main account, there is also Angular.js, Polymer, and CCA, to name a few others.


So does Microsoft.

https://github.com/microsoft/ and https://github.com/azure/ to name two.

> I think this is Google quietly admitting that Google Code is all but dead.

Well, I doubt that Google Code engineers or project managers had much, if anything, to do with the decision to move the Go project.

How many google code (project hosting, that is) engineers and project managers can there possibly be? The what's new wiki[1] has no activity in 2014 and only two entries from 2013, both of which are removing functionality (code search and downloads).

[1] https://code.google.com/p/support/wiki/WhatsNew

That they didn't have a say in this matter though, speaks volumes...

It would if the whole idea wasn't based on an assumption with no evidence.

You mean we need evidence to know that moving Go to GitHub would be against the interests of the Google Code people, and that they would protest such a move?

Being cautious is one thing, being a sucker for being too cautious is another.

There are things like obvious conclusions.

Some might say the same about Blogger and then it gets a minor update.

If they were smart about Google Code they would update it significantly and make it a competitor to Github with full GAE and Google Compute integration.

I'd be happy if they'd just let you turn off syntax highlighting for code blocks in the wiki. The default sh highlighter looks like crap if you display code in any unsupported language like assembly or Tcl. <pre> tags can be used but then you lose the gray background. That something so simple isn't implemented is the biggest sign of how abandoned Google Code has become.

> I think this is Google quietly admitting that Google Code is all but dead.

Go was on Mercurial before so it was already away from any Google own source control system.

> Go was on Mercurial before so it was already away from any Google own source control system.

How being on Mercurial implies that it was "away from Google code" ? It is in fact hosted on Google code currently (https://code.google.com/p/go/)

PS: Google code supports: subversion, mercurial and even git (https://code.google.com/p/support/wiki/GettingStarted#Workin...)

I think he meant that it wasn't on their internal source control system, which is one massive repo.

Google hosting Go on GitHub. Microsoft hosting .NET on GitHub. It must feel like an accomplishment to be implicitly endorsed by these companies.

Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.

I'm impressed.

They've really made it easier to collaborate.

Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across.

It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.

You must have dealt with a completely different company and product. The public github is a lot better than the enterprise version at least in terms of stability. Still, both lack a lot of basic issue tracker and code review features.

Github enterprise was a disaster with just a couple hundred users.

Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had to reboot the servers constantly.

We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement.

They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view.

We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.

    > Still, both lack a lot of basic issue tracker and code 
    > review features.
I strongly disagree. What you might consider "basic features" I'd consider antifeatures. The bare simplicity of the issue tracker is precisely why I use it for my (large) projects. The PR model of code review scales elegantly to hundreds of contributors. I'd be devastated to see GitHub's collaboration tools move even a step toward the hellscape that is JIRA.

At least for code review, the problem isn't pull requests as-such. The features that drive me to use other tools (on top of guthub hosting, often) are things like:

* The ability to mark which commits/files have been reviewed and so track progress.

* The ability to distinguish resolved and unresolved issues

* The ability to assign a reviewer based on which code is being altered in the PR.

* Useful handling of history rewriting during review.

I also think that the PR model could be implemented in a way that would make for better collaboration. At the moment, if someone submits a PR that has some issues and you want to help them fix those issues it's a huge pain because the commits typically live in their fork to which others usually don't have push access. It would be a considerable improvement if PR branches were set up in such a way that both the original submitter and the people with commit access to upstream could push to the review branch.

Beanstalk - private repo hosting for business - just released a brand new code review tool that we've been beta testing for a while now. It's rather nice and addresses many of the rough edges of pull requests. It's definitely for same-company teams as opposed to large open-source collaborative projects, though.


We host all of our private repos with Beanstalk, and use GH for our open source repos.

So, I'm no Jira fan either, but the code review side of github is definitely it's weakest point. They only just rolled out side by side reviews, something that I would have said was essential from day 1.

The fact that every comment on a review turns into a separate email is insanity, and just fills up your inbox with crap (one email for all of one person's comments on a review makes a ton more sense).

I hope they make it better, it definitely seems like a place where some TLC can go a long way.

Again, that's the idea with competition in the market. What one group wants may not be what everyone else wants. If enough people really want a specific set of features it would be nice if a vendor/Open Source solutions implemented that feature. There might for exmple be big differences in how enterprises use a tool and how (big) open source project use the same kind of tool.

I agree with that, but just to be clear, Stash is independent of Jira (though they do integrate) and has a simple pull request model. It's actually very nice to use (pretty much just like BitBucket).

Github Enterprise has supported disabling force pushes for at least a year.

Am I the only one who thinks some more competition would be nice? I would like to see more code move into BitBucket or similar. New version of Kiln will make it possible to use Git and Mercurial against the same repository which sounds like a great feature (not sure if there is a free plan on Kiln yet).

You are not the only one. We finally have decentralized tools only to... put all the eggs back into one basket!

Sorta. The eggs you're placing into github's basket are different from the eggs you've decentralized. I'd argue those eggs (merge requests, issue tracking, discussions) have never really been successfully decentralized.

Gitlab is gaining some traction, and should be considered indirect competition, and direct vs. github enterprise

Kiln is dead slow, and it's review tool is even worse than github.

I agree. I almost think the name GitHub is unfortunate at this point: they're doing something so right they could nearly invent their own VCS, use ESR's new tool, or even switch to hg/darcs/etc, and still gain momentum. The Go community seems to be hopping onto a fairly heavy pendulum.

The best-engineered technology rarely becomes the most popular. I think git has some huge problems, but now it's ubiquitous. Everyone has at least a basic knowledge of it, and that makes it the best technology. Switching to something else would be a step backward.

What are gits huge problems and what other technology solves those?

Not trying to put you on the spot, just curious.

IMO the main problem is that the command vocabulary is a mess. Do I need a soft, mixed or hard reset? Can I use "reset" to revert a single file, or do I need "checkout" for that? After years of using and loving git, this still confuses me. It's all logical in terms of git internals, but I'm not thinking in those terms when I want to revert something.

And this will never get fixed so long as people keep denying there's a problem. Even when people want to fix stuff like this it's hard to transition well from where you are to where you want to be, but at the moment people seem to be able to use this poorly evolved interface daily without noticing these ridiculous and uneccesary inconsistancies.

The "plumbing" is beautiful and the "porcelain" is a hideous mess.

There are countless git frontends (easygit and git legit) that come to mind, and yet they all see negligible use.

I think the cognitive load of using git is overrated. Yes, it could probably be simpler. No, you probably can't make simple and intuitive for everyone while retaining all the features.

Given that it's also easy to work with e.g. subversion or mercurial and a git bridge, so you can use the client of your choice with a git server, and yet no one seems to do that is an indication that git is sufficiently simple to use.

The git CLI is a mess. It's inconsistent even within its own commands. For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch".

It even uses different words for the same thing - sometimes remove, sometimes rm sometimes -d.

Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".

The reason people don't use other git frontends is that a vast majority of the help topics already out there only reference git itself. So if you want help for rebase, for example, if you're using some frontend that re-kajiggers the command line, all that help is now useless, or even worse, potentially downright incorrect.

> For example, sometimes specifying remote and branch is done as "remote/branch" and sometimes as "remote branch".

AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository.

git merge, on the other hand, is simply "git merge ref"; when ref is of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network.

So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git.

> Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".

Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".

> those usages are semantically different, and consistently so

They're very close to the same syntax, and the fact that they're significantly different just shows again that the CLI is a mess. If they're so different, they should have significantly different syntax. "space versus slash" is not significantly different. I'm sure I'm not the first person to create a new branch called "upstream/master" :P

The problem with git branch versus git checkout -b is that 99% of the time, what people want to do is create a branch and switch to it. The "create a branch and don't switch to it" could just be a flag on git branch. It DEFINITELY should not be two completely different commands.

> it's pretty obvious if you've taken half an hour to understand the underlying data model of Git

This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.

> This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.

This speaks to a fundamental misunderstanding of the nature of Git. You need to know the model of anything to be able to use it properly- you've mixed up Git's model with its "implementation" (probably because Git's model is so lightweight and exposes a lot of its fundamental workings, [as is right for proper usability][1]). This is like saying you shouldn't have to know what files and folders are to open a document in Word, Yes, you should.

[1]: http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as...

I have a good grasp of git CLI but bugger all understanding of it's internals, so you certainly don't need to know.

It seems fairly likely that what is considered a reasonable interface or a bad interface has a high level of subjectivity. Why bother getting bogged down with such debate? If you dislike git, use something else. If git is forced upon you, write some simple wrappers which provide the interface you want for your top few most used operations, or ask for help to do so from the people forcing you to use it.

Or just hang around hacker news and complain without anything changing. It's certainly my favourite method of avoiding work :)

I can't understand why they haven't tried to fix their CLI syntax. Besides having to remember when to do origin <space> branch and origin/branch, there is also how do you set the upstream branch, there's a couple of ways there.

And then creating a branch and switching to it. Is it 'git branch -c foobar' or 'git checkout -c foobar'. Was it -c for create? why not allow it on both? And its so easy to fix these things.

> yet they all see negligible use.

Evidence? Using my own anecdotal evidence, I strongly disagree.

I checked volume for GUI-related keywords[1] against CLI-related keywords[2].

The GUI-related keywords get ~34,000 searches per month. The CLI-related keywords get ~4,500. My methodology and data aren't perfect, but it's something at least.

Your premises are:

    - People use tools that are sufficiently simple.
    - People use git CLI instead of git GUIs.
And your argument is:

    - Git CLI is sufficiently simple.
Your first premise is just wrong. People use complicated things all the time because they don't know about simpler things. People also often think things are simple and then use them wrong. In my experience, a LOT of people use git wrong/dangerously.

I've addressed your second premise above. There isn't (and may never be) good data there, though.

[1] git gui; smartgit; git client; git tower; github gui; git frontend

[2] git command; git "command line"; git cli

You misread me, and it is my fault. I wrote "front ends" meaning CLI front ends, and gave two examples. You read that as "GUI front ends" and replied accordingly.

So, let me restate my argument (which I suspect you may still disagree with - but hopefully this time you'll disagree with what I actually meant to claim...)

The main complaint that I have heard about git is that its command line is an incoherent inconsistent unusable mess. My opinion is that is true, it perceived to be a much bigger problem than in really is - there are lots of CLI alternatives to working with git, and their use is negligible compared to actual git CLI use. Therefore, I suspect, a perfect git CLI would not have made a big difference in adoption.

The other thing is git is incredibly flexible. Almost no one uses all the options, but much like Microsoft Word, everyone uses a different 20%. And I suspect any system with this level of flexibility is likely to be complex. Which is not to say git is at an optimum; only to say that there's a reason there's not an accepted "perfect" CLI (for git or another VCS) - inherent complexity associated with flexibility.

The format that git stores it's data in is great, the tool most commonly used to access that data is a bit of a mess. So there's no reason not to use git with a different UI and there are a lot of UIs for git.

github is great largely because git is the best (d)vcs. Github was the first and the best so they got (and deserve) the lion's share of the market.

Also they got a lot of clients that would have otherwise chosen code.google because Google put up barriers in terms of licences.

Another monopoly in the making: "github cuz everyone is on github".

"facebook 'cause everyone is on facebook."

It's the same effect.

There are only two things that are going to fix it - either something amazingly better comes along (facebook vs myspace) or the incumbent royally screws up (reddit vs digg).

To be fair, it's not entirely the same sort of thing. Git is an open protocol. Github just happens to be one of many sites hosting git repositories. Moving a repository to another host is trivial; you already have all the data in your local tree.

Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperating with other social networks.

This isn't about the technology, it's about the people using it and how they choose to interact with each other.

Many good things were probably enabled by their decision to put a not-too-small price tag for private repositories.

The money from private side has allowed them to run excellent public service without ads. And the good public service has certainly fuelled the growth on the private side.

Now we just need Apple's Objective C / Swift to move to github. :) Sorry, not going to happen. :(

Don't they have a mirror of the compiler on github?


Swift hasn't been included but objective c is there.

Naked Objective-C is not much interesting or useful without accompanying frameworks (Foundation, Cocoa, AppKit etc). Just like publishing only C# compiler without all of .Net framework would be.

Apple has stated that they're going to open source Swift in the future, who cares if they choose to host it on their own platform.

I'll believe it when I see it; I'm still waiting for the promised open-source release of the Facetime protocol.

That was canceled due to a patent lawsuit. It would have cost apple a ton of money to pay a patent troll to be able to open source FaceTime.


To clarify. Because of this lawsuit, Apple moved facetime away from being peer-to-peer to now being routed through Apple's servers. Since they have to use the centralized model, opening up the protocol for others to use would also require using Apple's servers to play nicely. So Apple would be footing the bill.

Thanks; it's just a present irritant because the Hangouts client for iPad is presently broken (no video), and Skype doesn't support video conference calls in their tablet clients, so I don't have a free cross-platform multi-way tablet-based video-chat protocol that works, and another entry in that space would be convenient.

I haven't heard that they have announced a decision. Do you have a source for that?

Let me second this question. I have heard the equivalent of, "It's too early to be talking yet about whether we will or won't open source Swift; let's talk about that later," but I didn't interpret that to mean, "We're going to open source Swift later."

Of course, maybe I missed the memo.

When I asked Chris Lattner a week and a half account at the LLVM dev summit, there was still no decision yet, ...

It's a really great collaboration tool. I think git itself could use some work in certain ways, but Github really makes it hard to go to any other web-based version control + pull request type tools.

Use go for a few month, loving it. but I miss not having exception compare to Python.

Is the golang spec still tightly controlled by 3 wisemen in Google and no feature is allowed to add to the language without all three in total agreement?

BTW, I like 98% of their language decide choices and absolutely LOVE the compilation speed of the program.

No, it's not controlled by them anymore. Possibly in the early days it was, but now it's much more community controlled.

You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types).

You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.

> You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions

If by exception you mean Java's implementation, yes. If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no.

I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.

> think most of this could be solved easily by either a compiler option or golint rule

You mean like errcheck? https://github.com/kisielk/errcheck

I'm not sure if it can find spots where people intentionally throw away an error like in

    val, _ := foo()
Usually people are more concerned with places where people accidentally fail to realize there's an error returned at all, like this:

    func foo() error { ... }

    foo() // errcheck finds this
However, it should be possible to find errors assigned to underscores, and thus detect that case.

Ideally that'd move into the standard suite and you'd have to do something like compile with --repeat-the-mistakes-of-c to skip it.

I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).

Anyone who intentionally throws away errors because they "got tired" of checking errors, isn't someone I'd want on my team, and their code is not something I'd want to depend on, regardless of the language. Hopefully it would get caught in code review. But yes, it would be nice if go vet or go lint caught this syuff. Luckily, someone else wrote errcheck, and that's good enough.

Sum types and monads are very useful if you believe that errors as values are far superior, you should check them out.

Emacs moved to GitHub as well :)

Emacs recently switched to git. Emacs did not move to GitHub. There is a mirror repo but Emacs itself is not on GitHub.

Thank you for your clarification

This is a huge compliment to GitHub, for Google to be moving one of its premier open source projects off of Google Code and onto GitHub.

More importantly, though, this is a significant compliment to the Go community, for Go to uproot itself and move to where the majority of its users are.

They moved many of their popular Java projects recently: guava, guice, closure tools, gson.

The writing's on the wall for Google Code. I don't think I've seen a new feature in several years.

I hope they at least keep it in read-only mode. Oh god, all those dead links.

I'd love for them to just go read only, a TON of academic work lives on there, but its awful to use.

I much prefer Google code defect tracker to the GitHub one. But that's about the only plus of Google code.

(Though, a small part of me wants mercurial to live on, but it doesn't seem like that will happen)

That defect tracker is nice. I've never used mercurial so I can't comment on that. Github keeps getting better, I'll bet if people asked for improvements to defect tracking we might get them.

I think Google stopped bothering with Google Code when Github came to popularity.

Google Code doesn't really fill Google's mission, so it's not absurd for them not to bother once someone who's truly focused on the space has created a superior competitor.

Google Code was created mainly to combat the monoculture of Sourceforge, which was slowly growing crappier.

Google wanted to create a place open source people actually wanted to be, and had reliable hosting, instead of a place people had to sadly live with that was pretty unreliable (no offense meant to my friends at sourceforge).

Doing so jump started some competition in this space.

While github is slowly becoming a monoculture again, it doesn't appear to slowly be growing crappier or less reliable.

I'm sure in 5-10 years something like Google Code will be necessary again.

(Google code was the first engineering project I worked on at Google, for a few years starting in 2006).

Hi Dan! Remember when I DDOSed Google Code on Super Tuesday 2008, when I thought it would be a good idea to host my election map result tiles there, and then I forgot to turn off the cachebuster in my tile URLs? Good times... :-)

I remember We actually served election data ourselves there for a bit, but not with cache busting :)

If they wanted to they could turn Google Code into a real competitor for Github with full GAE and Compute integration. That would make it an amazing platform.

Who says they won't? :)

Seriously though, yes, that would be really cool, but probably not something you could directly transform google code into. Google Code is a pretty legacy codebase in a lot of ways. It would likely require making a new platform to do such a thing.

Oh no doubt the codebase would likely need a massive refactoring (if not even a rewrite) but the name could stay the same.

Google Code = Google Video

GitHub = YouTube

Uh, no. Google Code took over the space in a way Google Video never did.

    SourceForge -> Friendster
    Google Code -> MySpace
    GitHub -> Facebook

Pretty much :)

I think these are two separate issues:

  1) Go is moving from Google Code to Github
  2) Go is moving from Mercurial to Git
To echo another user in the thread: "am I the only one who prefers Mercurial to Git?" In my view Mercurial is on par or even superior to Git, but lacks "Linus made it" fame. Too bad... I have used both Mercurial and Git and find hg command line interface much more intuitive to use. As for GUIs, there really isn't much difference between the two (too bad GitHub only supports git though).

I spend most of my life in Git, simply because that's where the market is. I've had people ask me Git questions during interviews, which is mind-boggling, but there you go.

Each time I've worked with Mercurial it's like a giant weight is lifted off of my shoulders. I feel great joy instead of dread each time I have to go look on Stack Overflow for "wait, just what magic flag combination do I need to use to avoid destroying all my work?"

I get the impression that people who prefer Mercurial to Git only ever talk about interfaces and not about the underlying model. It seems to me that especially for a tool as important as version control, the underlying model is significantly more important: you can wrap a mediocre interface in a nice one, but if the model isn't very good you're pretty much stuck. That isn't to say that Mercurial's model is bad per se, but it certainly strikes me as significantly less elegant than Git's. (I'd be happy to find out I'm wrong about this - I know Git's model pretty intimately but am only moderately familiar with Mercurial's.)

This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.

> This seems quite bad, but I have no idea how to fix it.

Most people, when interacting with their database, use SQL (or whatever native command language it provides), and don't need to worry about the underpinnings.

Most people, when interacting with their source code repository tool, use the command set provided by the tool and don't worry about the underpinnings.

I've had problems with my databases before that forced me to learn about the horrid can of worms underneath. Until I had these problems, I didn't care because it was entirely irrelevant to the thing I was trying to do.

I've thankfully never had enough of a problem with any of the repo tools I've used (cvs, svn, hg, git) that I needed to go diving into the data structure itself to figure out or fix a problem. I hope I never have to, because that's not the job I'm trying to do.

You shouldn't need to care how the tool works in order to use it, unless using it is your primary job. My primary job is writing code for my application, not writing code for my database or repo tool.

If going distributed, hg provides a much more sane initial set of commands that make more sense to people with experience using anything that isn't git. This matters a lot, because those commands are the only things most users ever really care about.

The underlying model is really not that different. There are some details that give rise to implementation differences, but Git and Mercurial have converged on a very similar approach.

The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools.

There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability.

How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.

Not sure if it's better or not, but Mercurial has a concept called the RevLog[0]. A basic overview of it is here[1]. It sounds like the revlog format can become corrupted from time-to-time, but it's pretty rare now adays.

[0] http://mercurial.selenic.com/wiki/RevlogNG

[1] http://ericsink.com/vcbe/html/repository_structure.html

EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...

hg has a very elegant underlying data model, which you wind up not having to care about at all (a nice property of a good abstraction), unlike git.


I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.

You're not the only one. If you prefer the Mercurial interface, I highly recommend trying out hg-git. It's an extension that does transparent bi-directional conversion between git and mercurial. I've been using it for the past 3 years to interact with GitHub and colleagues in different companies and I have yet to run into significant problems.

There are some minor nits: occasionally I manually need to forward the "master" tag to the latest revision to push it to git and since git doesn't log file moves you can run into "broken" history for a file, where Mercurial doesn't know a file was moved. But in day-to-day use I don't really have any issues.

It is great to see so many projects moving to git and GitHub in particular. GitHub is incredibly helpful for quickly taking a look at a project and figuring out what areas of a project are still evolving and being actively developed.

You could also say that everyone moving to GitHub is leading to a dangerous centralized monoculture that evaluates software quality based on how well it fits GitHub's conventions.

git is still git - people don't even need a github account to have full functionality.

How many Github projects accept git format-patch submissions? There's functionality beyond the basic DVCS commands.

In Go's case, we will be using Gerrit (elsewhere) for accepting submissions. GitHub will only be used as a source code mirror, wiki and issue tracker.

Wait wait wait... no pull requests? There's no way you could just hook up PR's to gerrit? Using github just as a mirror seems to defeat the entire purpose of github, which is to encourage more community members to contribute.

Having migrated projects from GitHub to/from Bitbucket and internal git servers - which is a 10 minute job at most - I'm not terribly worried about this.

Moving to git is great, moving to github can be terrible for some projects that are more collaborative, as if you want to change someones PR you cannot..

You can makes changes to a PR that you didn't open.

If you want to change the title, edit/delete comments, close the PR, assign a person or labels then you'll need the proper permissions.

If you want to make changes to the code you'll need to have push access to the same repo (which is usually the case if you're on the same team because then you don't need to use forks). Otherwise you can always amend the commit(s) before merging them into master.

Better still you can fork the PR and open a PR to the PR :)

What if the repo is /me/myproject and you are trying to fork /contributor/myproject? What will your fork be named?

They're using Gerrit for code review, where you can modify patches submitted by other people.

Google Code has a really bad user interface. This migration makes sense. I wish they stuck with Mercurial and moved to Bitbucket instead, but Github is still better than Google Code.

Google Code needs web and UX designers STAT, or it will die.

Now all we need is Jeff Bezos to buy Github :-) That would be funny.

But on the story this is a great move, Github is much nicer than Google Code and more actively supported. I had not heard of Gerrit before and that was a really pleasant discovery. Now to figure out how to get that setup at the office.

Gerrit is an absolute treasure of a tool. I shudder everytime I make a pull request in Github because Gerrit's contribution model is so much better for my workflow.

It has some hairy points though. I have never liked it's review per commit model (yes, I know you can circumvent this by using merge commits).

I think the Github style works, assuming you have a sufficiently good CI system that can also receive GitHub web hooks.

Gerrit is very difficult to automate, I am told. You should take a careful look at it before jumping in.

After farting with different SCM managers, I strongly believe that having raw ssh against directories is really the best way to deal with source code. (feel free to email me if you want a longer discussion... I'm at a conference and can't reply in detail now.)

It is so sad that Google Code has not been given some love. Their bug tracker is far, far superior to Github. The review mechanism is also quite, quite good (Gerrit I presume). The UX was too, too Sourceforge-ish and could not compete with Github or (what I think is best of breed) Bitbucket.

Props on the move, it shows that golang is flexible to make moves for what's best for the community rather than stick it out in google code. I hope this results in benefits to the iteration cycle.

I was hoping for this transition for a long time! Github is far more accessive and user-friendly than the Google repositories. Great move.

Does anyone know what code review system they are using with github?

"We will use a Google-hosted instance of Gerrit for code reviews."

thank you. Missed that in the article (was skimming >_> )

Me too, my brain is wired to read Gerrit as a common Dutch first name, so I thought he was talking about a person named Gerrit.

It is! Gerrit (our new code review system) is named after Gerrit Rietveld (the designer), as it Rietveld (our old code review system).

Hm, I agree that github CR is not good. Glaf they're using Issues though as Github discussions are a _really nice_ way to build software. I personally find Gerrit painful to use, but has critical features, as enneff described. Hope Github really steps up to the plate.

Also, everyone who uses github whould really check out *Sourcegraph's code review stuff. They show you really useful things like:

- exactly what definitions were added/removed/changed (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)

- a diff with jump-to-definition links (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)

- a list of people and projects impacted by the change (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)

Totally gets rid of the "understanding the PR diff" problem others mentioned

I'm curious what Gerrit gets them that Github doesn't have natively, too.

There are a lot of things lacking about GitHub's code review process (pull requests). Off the top of my head:

- Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history.

- Pull requests require the contributor to create a public fork of the repository they're committing to. I can see how this works for some people, but I find it gross for each contributor to the Go project to have their own public fork. What a mess.

- Comments on pull requests are sent as soon as they are created. Gerrit allows you to make many comments on a change, as drafts, and then send them all in one go, sending just a single email. This is much easier to manage for a large project.

- Gerrit has the notion of multiple 'patch sets' for a particular change, and you can see diffs between patch sets, so it's much easier to progressively review large changes.

And there are many other small issues with the GitHub pull request process that make it untenable for the Go project.

I'm really curious to give Gerrit a try. Is it like the existing Rietveld system used for Go?

- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.

- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.

Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(

- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.

- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.

I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)

We're going to build a bot that replies to pull requests to the Go core. It'll say "Sorry, we don't take pull requests, but here's how to use Gerrit [link]. Thanks!"

FYI if you have a "CONTRIBUTING" or "CONTRIBUTING.md" document at the project root, a neat little info bar "Please read the [contributing] guidelines before proceeding" will show up to anyone filing a bug or a PR.

Not to be flippant, but if you are not going to use pull-requests, what is the benefit of moving to Github? Will you use the issue tracking system?

If not then it just seems like switching to git using the present google code host would suffice from a technical viewpoint.

We will use the GitHub issue tracker, which will allow easy cross references between go issues and other projects on github.

I have to agree that not using pull requests is missing out on the best feature of github. It's the social, low-overhead way to contribute to a repo.

It seems like it must be possible to hook up a bot to github that watches for pull requests and submits them to gerrit... the Juju team has a bot that does that for our Reviewboard integration. It won't work for more complicated workflows that github doesn't support, like dependent branches or whatever, but it lowers the barrier of entry for initial contributors that just want to submit a simple fix. And the more advanced users can just submit directly to our Reviewboard instance if they want the more advanced features.

Also, the public fork on Github is actually a feature - it means others can easily see what you're working on. You need off-site storage for your personal work anyway, right? You're not going to keep it local on your laptop, so you'll need a branch somewhere regardless.

GitHub code review is terrible. I don't blame them for not using pull requests in the least. If not being able to pull is enough to stop people from contributing, how much is their contribution worth?

Why even move to github then?

I think this is a great move. Also, very similar to the setup used for the OpenStack (http://openstack.org/) project. All reviews done in Gerrit, published to Github when merged. OpenStack also has the bot which closes GitHub pull requests and redirecting to Gerrit. More on their Gerrit/Github integration here: http://ci.openstack.org/gerrit.html For those interested in doing the same for their own, private projects, there is http://forj.io (full disclaimer, I work on this project). Finally, Gerrit now has an async / TTY based client which works offline (reviews on the go!) with Gertty - https://github.com/stackforge/gertty


Gerrit is a Rietveld fork, see http://en.wikipedia.org/wiki/Gerrit_(software).

> Pull requests require the contributor to create a public fork of the repository they're committing to.

You can create Pull Requests within a repository. You don't need to fork the repository if you have push access.

Go contributors will not be pushing to the GitHub repository, nor will have direct commit access to the Gerrit hosted git repository.

Nice summary; thank you. I don't know why people put up with the merge commit pollution. Great to see Go taking the best of both worlds.

With git and github you can have the best of both worlds. merge commits (seperate tree), linearized at the end (--no-ff) or rebased commits (pull --rebase).

1 and 3 have their usecases, 3 is esp. useful if the branch contains only 1-2 commits, and 1 is useful if the branch contains > 10. You can add test information into the merge commit.

I hope github will take more gerrit features into their tracker or allow tracker extensions, so that we can live with github alone. gerrit still is a UI and performance nightmare.

The merge history is the true one, it's what you want when browsing backwards to see how particular things changed. Rebase creates fake commits corresponding to a tree that never actually existed anywhere. Your history viewer should be able to linearize the tree for you if you want, but the canonical history in the repository should be the true one.

That's just one workflow.

For Go, we will require that contributors (everyone working on Go) prepare their commit at head (or at least make the commit able to be automatically rebased). It makes no sense to have a merge commit for every single commit. That would add no extra information and double the size of the commit log.

It's not a merge commit for every single commit, only for every, well, merge. I sure hope people are writing new features or bugfixes in several commits, not just doing days of work and committing at the end (though I guess that would be a workflow for people who are worried about the size of the commit log).

What's the purpose of keeping a commit history at all? Really, what are your use cases? For me, the history is for looking around and understanding a particular change, or for bisecting to help understand a bug. Both of these use cases are better supported by seeing the tree as it actually was when someone was working on it, than by seeing an artificial, rebased history. What's your use case where the rebased version makes sense?

This is a fantastic answer on Github's (rare) shortcomings. I hope the Github team is here reading this and taking notes!

Go team member here.

I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot.

Github's review mechanisms barely scratch the surface of what's possible.

Have you ever, by coincidence, used Phabricator? If so, what's your opinion of it? I've used Phabricator full-time for a while and it's been really a joy.

If any of the other ones are public, which did you like best? IIRC, Mondrian was good, but not great.

From best to worse, in my experience:

1) Google's current internal one

2) Gerrit (open source, to be used by Go)

3) Google's old one (Mondrian)

4) Rietveld (open source, but run for free at codereview.appspot.com)

5) Github

I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.

In case you do want to try out another one at some point, I built https://reviewable.io to take some of my favorite features from Google's internal tool but integrate seamlessly with GitHub.

Review Board isn't as good as it could be. Sometimes it's diffing tool provides far too much noise to be useful.

Mondrian is the best code review tool I've ever used, but I'll admit that could be damning with faint praise... I'm very curious to hear what the better options are, because we use Github at my current company and I would go back to Mondrian in a heartbeat.

I used to work at a company that did 100% of code reviews on gerrit, and by 100% I mean we had a requirement all commits be approved so I spent a lot of time in gerrit.

then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit.

gerrit makes it so clear what commits need reviews. in github it's just a list of pull requests. did I comment already? does this need approval? is this already approved by someone else? who? all of these are difficult to see in github but instantly obvious in gerrit.

then at the code level, gerrit uses my whole browser window so on a 30in I can side by side diff any file. GitHub has a tiny viewport and I'm constantly scrolling. it's not streamlined for reading at all and once 5+ comments are there you can give up on reading the code. gerrit has an upper limit on comments too before the ui overwhelms the code but it's way higher.

I think gerrits tools for viewing more lines are better, although phabricators are good. gerrit gives me a copy and paste link to check out exactly the code I am looking at.

and I really enjoy the patch set system over additional commits. it's a lot clearer in a back and forth setting to see code evolve over time and digging patches without making entirely new commits.

gerrit has built in support for automated and human reviews to leave separate scores. aka, you have to pass the tests and get approval. this doesn't exist in GitHub.

extending gerrit with hooks was crucial to our workflow. luckily github delivers there, but as gerrit is open source you can do more to extend it. especially on the ui side.

I have to admit at first I was blown away how weak github is compared to gerrit. I could not understand why it's so popular. now after about a year on github I get it, I get why it's popular, but is still years behind gerrit.

Github is simple and good enough for vast majority of users. Gerrit UI sucks. I really cannot express how much I hate it, and how broken and counter-intuitive it is, after working with github. For new users its just unusable. If github would try to impose it on its users, they'd loose 99% of contributions.

The key features for me are:

1) The ability to have multiple reviewers, who can provide both human-readable input ("fix this") and machine-readable input ("Code Review +2"). This becomes powerful when you require a couple things to submit, code review and verification that the change works. A TryBot or something can automatically +1 the Verified bit when the tests pass, and the reviewer can +2 the Code Review bit on the assumption that the code compiles and the tests pass. Requiring both makes review easier and the repository less likely to break. Sounds like extra bureaucracy, but it's actually really wonderful.

2) Pushing the onus of merging and submitting to the author, instead of the reviewer. I can say "looks good, fix the merge conflicts" and be done with the review. With Github, the repository owner has to do the merge (or push back and re-review; I pick doing it myself).

Github's code review tool is really aimed at accepting or rejecting; not improving. At least how I use it, anyway.

- GitHub doesn't show you what changed in a PR from the last time you looked at it. You can look through the individual commits, but this can be painful if there's a lot of them, and can easily become impossible if the code was merged, rebased, or squashed.

- GitHub sends each comment individually, encouraging "shotgun commenting" instead of a coherent set on the sender side, and leaving the receiver to deal with dozens of individual emails.

- GitHub attaches line comments to the deltas, which makes the comments disappear if the underlying code changes. This makes it easy to "lose" a comment during a review, and forget to check that something was fixed properly. Even if a comment survives, GitHub doesn't track (non-) resolution in any way, so it's still easy to forget to take care of stuff.

- You can't customize things: can't pick your favorite source code font, the wrapping margin, syntax highlighting colors (as it doesn't have syntax highlighting at all), links that open your editor directly on the correct line, etc.

As it happens, https://reviewable.io fixes all these, and has a much lighter-weight integration with GitHub than Gerrit does, not to mention a much friendlier UI. And yeah, it's my own project so I'm obviously biased, but check it out if you're annoyed with GitHub's code reviews but Gerrit/Phabricator are too heavy for your needs.

GitHub has the network effect of so many existing repos, but I personally think the issues & code review tools are mediocre at best.

Gerrit works well for a project that has many different repositories, as you can do code review all in one screen.

I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)

They say it's Gerrit

I think this move is great for 2 big reasons:

1. This fits better with the workflows I know and are common for Go programmers. I use Github and Git regularly for a variety of things, and I only ever use Google Code and Mercurial for things dealing with the Go source or tool repositories. Along with the change of the much of the compiler source code from C to Go, this will make it a lot easier to get involved with the core of Go.

2. Simplifies using import paths for Go's tools. There's a bunch of different repositories in Google Code's Go project, and using them is slightly more painful because Go Get then requires mercurial to work. Reducing developer friction is a good thing, especially in odd places such as when a github repository uses a Google code repository and suddenly you need mecurial to import something using git.

As someone who uses Ruby as my primary language; I'm totally jealous of this move. While there is a github mirror, it sucks having to use Subversion for the "one true repo" when everything else I work with these days is on git.

I contributed to Ruby once by issueing a pull request to the GitHub mirror, it went fine. Is it less handy if you're a regular contributor?

You can do pull requests through github, but Subversion is still preferred. Things aren't integrated; so for example if you look at https://github.com/ruby/ruby you will notice Issues is not enabled; instead you have to go to a separate issue tracker over at https://bugs.ruby-lang.org/projects/ruby-trunk/issues.

I still contribute, but the barrier to entry is higher; people have to hunt the ruby home page to find this information which is not ideal.

> The world today is quite different from the world then.

Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.

"5 years ago too"

No, they didn't.

Github only started in April of 2008, or 6 years ago. Your implication is that they took over the world in a year. They didn't. I actually have seen the growth graphs of both before, and what you say is not even close to true.

Well, at the time of Go's open source announcement, Github was 1.5 years old. Go existed before that too, looking at the dates the first whiteboard doodles about what would become the Go programming language were done about a month before Github development started. Yes, Github was starting to thrive when Go was announced, but you could hardly say it had proven itself as much as it has now.

Hi Go team,

if you want an alternative for Gerrit code review, you can also use http://review.ninja. It's also open source, so you are welcome to contribute.

Cheers, Mitch

Took a brief look at the front page.

- No side-by-side diffs? Didn't see any in screen shots.

- The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a deal... In any case, the scary scope list prevented me from experimenting.

Hi skj!

- What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit.

- Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permissions in the first place.

Thank you for the feedback!

Here's a screenshot of some side-by-side diff action: https://fr.atlassian.com/wac/software/fisheye/overview/scree...

Basically, it let's you look at the old code, or look at the new code, or see how they're different, all at the same time.

Inline diffs (github-style) require you to keep a context as you scan through code, and it makes it harder to keep everything in your head.

Review Ninja is beautiful, but at it's core, it's just slightly more nice stuff on top of pull requests. It can't address the issues such as being able to edit someone else's pull request as part of a code review, can it?

Hi pridkett!

Anything pushed to the branch of a pull request is an edit on the pull request. Once something new is pushed on to the pull request, the voting in ReviewNinja needs to be repeated.

Furthermore, Issues linked to a commit will be linked to all new commits by Review.Ninja automatically, as long as the issue isn't solve. You only merge, once all issues are solved / it is save to merge.

Cheers, Mitch

How much do we have to bribe you for Bitbucket integration?

We will work for cookies! :) jk

We are very open for cool new ideas, features and also contributions on our GitHub repo: https://github.com/reviewninja/review.ninja

ReviewNinja comes from the GitHub Enterprise context (as we use GitHub Enterprise in our company) and we want to offer an open source code review tool for both GitHub.com and GitHub Enterprise.

Bitbucket is awesome! But I think if we want to support on premise installations with Review.Ninja, BitBucket support would be overkill.

Cheers, Mitch


Really? You've managed to mention the lack of generics on a thread announcing moving go to github? Is this a parody comment or are you serious?

Seriously. Why does every single thread about Go have to have at least 1 guy talking about lack of Generics?

Why does hacker news not have a reddit style 'below threshold' to display none subthreads? :/

I feel your pain. This is coming. In the meantime, we've detached this subthread from its parent so we can mark it off-topic.

All: predictable flamewars add no new information, therefore have a signal/noise ratio of zero, and therefore are off topic for Hacker News.

If this area is going to be marked off, then I would appreciate my mod points being restored as well. If you look at my original response, it was pointing out the fallacy in a very particular claim (and nothing resembling a 'flame war').

You got downvoted (presumably; I don't have such powers) because you took this off-topic (Go's type system has nothing to do with what version control system is used for its development). What's the point of HN karma if you can get those points back?

Totally serious. And, it's not just the lack of generics-- that's just the tip of the iceberg.

What problems have the lack of generics caused you in development?

Last time I used a language without generics I had to cast web form values (we used a library with a general-purpose representation of "form control backed by object"). Sometimes these were incorrect, and had to be debugged. More than that, when working on the form code I had to constantly keep track of the types of things in my head, because there was no way to have the computer do it for me (we did try Hungarian notation for a bit but that was a disaster). Is it the end of the world? No. Does it slow development? Absolutely.

"a language" means it presumably was not Go, and is therefore irrelevant. All languages are different.

The fact that we can talk about "generics" at all means you're wrong. Any general-purpose programming language has to solve the same set of problems and the ways different languages solve them are often recognizably the same approach. And Go is very, very similar to Java 1.4.

> Go is very, very similar to Java 1.4

Except for multiple return values, easy concurrency, implicit interfaces, real value types, pointers, functions as first class types, closures, no inheritance, no exceptions.... but yeah, other than that, they're totally similar languages.

In JavaScript, none at all.. ;-)

In C#, before generics, wiring up a typed collection/enumerable was seriously painful.

I think the right way to think about that is: "what solutions has lack of generics prevented me from writing?". From the expressive end of the power continuum, Go is way down there (somewhere below Blub probably).


What solutions have lack of generics (in Go) prevented you from writing?

Type-safe json decoding.

I think you mean s/ignorance/rejection/.

Probably a combination of both really. I get the sense that the 'Commander' hasn't done the requisite reading.

I just asked him in person. He has.

Anyone that knows Rob will tell you that you're simply wrong about this.

Only if you are inside the cult could you possibly have that opinion. Do you also think that Jim Jones was an expert on the New Testament teachings? If you take his word for it, of course he was.

We (the Go team) regularly have conversations about all kinds of programming paradigms, because we're into that kind of stuff. Some of us really like functional programming languages. But Go is not that kind of language, so those primitives do not belong there. Go is not everything to everyone, and it would be a mistake to try to make it that way. That doesn't mean that we don't see those things as generally valuable, just not in this context.

A bit OT, but probably the biggest roadblock for me switching over to Go is the wonky syntax. Are there any plans to make Go more accessible to someone coming from more traditional languages? (i.e. like "do" notation in Haskell) I've done the Go tutorial about 5 times last I checked (seriously), and I just can't stomach the syntax. I may be tainted by my years of C, though.

What?! If anything, your use of C should make Go's syntax really familiar (aside from putting the name before the type, which doesn't take long to get used to). It's exactly like any other C-like imperative language. C, C++, Java, C#, even Javascript. Those are pretty traditional langauges. Haskell is not what I think most people would call a "traditional language".

What exactly is your problem with the syntax?

My point about Haskell was not to say that it was more intuitive for imperative programmers, rather, it was to demonstrate a syntactic sugar construct that eases programmers in. Because Go's syntax is so similar to C, it is confusing because as a coder, I can only context switch a finite amount of times.

You appear to know both Haskell and C, but find Go's syntax hard to deal with? This is one of the weirdest Go complaints I've read, for sure. Syntactically, it's just one of the many Algol/pascal-style imperative languages of the last 40 years. Most people get used to it quickly.

At least it's nice and unambiguous.

> I just can't stomach the syntax. I may be tainted by my years of C, though.

I can't relate to this.

That's exactly my years of C that makes Go quite attractive to me. The way I see Go is that it allows me to code as close to metal as C, but without the pains of C -- headers, make file/dependencies, memory management, and more.

> code as close to metal as C

> without ... memory management

Read again. As said "as close to ... but without", I didn't say "close to". If you are unable to make sense of what I wrote, don't blame me for your shortcomings.

When people disagree with you, that does not mean they are ignorant.

To the siblings to this post: it seems rather unlikely as the research is being generated at a rate that far exceeds any one person's ability to read it (especially when they are already busy marrying C and CSP [which is easy to build as a library or add-on to any other existing language] & type theory isn't their specialty).

So, you're criticising someone for not doing something that's impossible? Just stop.

It was at least interesting how quickly those goalposts moved.

The portion of that material which is requisite is obviously a strict subset of the entirety of the material. But, for one to flippantly say "I've read it" without even establishing what "it" is, seems a bit dismissive and duplicitous to me. Regardless it is obvious to anyone who is knowledgeable that Rob Pike has not read what most who are in the know would consider "requisite".

Also, if you take a look at the thread I posted, his attitude and approach re: map, filter & reduce doesn't come across as the most academic or well thought out.

Rob didn't really say anything about map, filter, and reduce in that thread. His comments should be taken as being in addition to the earlier comments by Ian Lance Taylor, another member of the Go team.

You should address the gaps in your own knowledge before criticising others. For instance, you're obviously unaware that Rob designed and implemented a whole language based around map/reduce/filter style operations: http://static.googleusercontent.com/external_content/untrust...

I think his obvious implication is that Go doesn't need map, filter and reduce because (if I may summarize) "line feed is just a single character".

That's just really poor (and silly) reasoning honestly. A 12-yr old could look deeper. For instance:

-. Is 'writing' code all that matters?

-. Aren't there in fact 10s or 100s or 1000s more readers to code than writers (including the original author also as a reader)?

-. Do readers like to scroll between various blocks of logic and divine signal from noise by teaching their brain to ignore boilerplate?

-. And what if the brain at first sees something as boilerplate but only upon further examination finds a subtle difference in the pattern for this one rare instance?

-. And what if that happens when the programmer is investigating a long-standing bug that has just resulted in a great loss of human life (and will continue to do so)?


Rob, myself, and others have written tomes on this, on Hacker News, golang-nuts, and elsewhere. If you're trying to have an argument with Rob (he's not reading this, btw) over some pithy statement he made in February, you're wasting your time.

You've written tomes on how wasting vertical space and multiplying syntactic noise is a good idea? Even if so: ideas are not measured by the volume of noise you write in support of them.

You've written tomes on how wasting vertical space and multiplying syntactic noise is a good idea? Even if so: ideas are not measured by the volume of noise you write in support of them.

At the risk of prolonging this insufferable "conversation": my point is that it has been discussed to death, and you're being down voted because nobody is interested in discussing it with you, or even hearing you discuss it.

I’m concerned that it won’t get any stars.

I guess its official, misogyny is ok in our industry.

Have we forgotten about: http://lmgtfy.com/?q=github+misogyny ?

I'm not sure github even experienced a dip in traffic.

There are github alternatives, it took me 30 minutes to remove my github subscription and migrate my repos to bitbucket.

Have you assessed Atlassian's culture and concluded its constituents promote gender equality?


Does boycotting Github for the rest of time over a scandal achieve anything?

Nonetheless, your post has value in that I'm now thinking about gender equality in technology. Thank you.

> Does boycotting Github for the rest of time over a scandal achieve anything?

Boycotting a business for any reason is VERY effective if it affects their profits enough (aka enough people do it). Whether or not it is the right solution, if enough people boycotted Github publicly for not promoting gender equality enough you better believe they'll change their tune.

The problem is that everyone thinks "enough people won't do it" and it becomes a self-fulfilling prophecy. Please don't spread FUD claiming that boycotts don't work. Boycotts which don't garner enough support don't work.

> Have you assessed Atlassian's culture and concluded its constituents promote gender equality?

There is a lot of evidence that Github promotes gender inequality. There is less evidence that Atlassian supports it. Would you rather give a guy who you saw punch his wife in the face $5 or a guy who was rumoured to beat his wife $5?

> Nonetheless, your post has value in that I'm now thinking about gender equality in technology. Thank you.

Awesome! If everyone would put some thought towards it maybe we could come up with the appropriate solutions.

I will bite.

How does using Github even remotely contribute to accepting misogyny in our industry?

There was an ugly affair there.

Github's handling of the affair is difficult to judge from outside. At least it seems that management's handling of this affair did not increase future misogyny at the company.

Github promoted misogyny internally. You give them revenue, allowing them to continue to run their business. Ergo, you are promoting the misogyny Github promotes* internally.

* The burden of proof that Github doesn't promote misogyny is on Github.

EDIT: I personally use Github, but I cancelled my account after what happened. For new projects I use bitbucket. I actually feel bad when I'm using Github precisely because to a degree it means I'm promoting misogyny.

I might be wrong but isn't that a faulty argument. That's the same as saying that you pay tax in the US(or any other counter) and you therefore condone of all the behavior of said country? Or saying that if you use any Google product you promote corporate monopoly? There's quite a way from paying for a service such as Github to promoting misogyny.

I will bite back.

Github's corporate culture appears to be very anti-woman. There is plenty of available evidence to this effect. There is very little apparent diversity (of any sort) in their large team. https://github.com/about/team

Using Github contributes to the success of this monoculture and encourages tech leaders to revere and duplicate this model. It makes tech more difficult for people outside of that group - the white, straight, male group. It makes tech culture worse.

If I'm aware that you host on Github, I will make sure to consider what your competitors are doing before I use your service.

I can see how you could make it a valid argument like that. Thanks for elaborating.

Do you think that not using services from companies with a monoculture is the most effective way of furthering the cause? I'm all for more diversity in the technology and startup sector, but I do believe that the cause should, and eventually will, be solved by dialogue and focus on the issue - not by silently boycutting the companies. Or am I missing some part of the picture?

I can't say if this cause is better solved some other way, but I believe that avoiding Github (not exactly boycotting it) and other big monocultures is the right action for me to take. When I use a service, I give it a piece of my economic power. I don't want to give that to Github.

I do believe a capitalist-based ecosystem can only be healthy with an appropriate level of competition and alternatives for consumers. Github's progress in the market is worrying in the sense that it seems to be driving towards a monopoly.

Github can never be everything to everyone - if there is no meaningful competition, it's guaranteed that some people will be excluded.

> There is very little apparent diversity (of any sort) in their large team.

I'll grant you that they all look the same. Doesn't prove much -- Karl Marx looked a lot like Andrew Carnegie.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact