Live data from Hacker News

Go is moving to GitHub

groups.google.com

181–190 of 244 posts

Re: Go is moving to GitHub

#181
post #145

Earlier quoted context omitted.

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

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

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.

Re: Go is moving to GitHub

#182

Earlier quoted context omitted.

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

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

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 :)

Re: Go is moving to GitHub

#183
post #139

Earlier quoted context omitted.

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

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

Re: Go is moving to GitHub

#184
post #157

Earlier quoted context omitted.

I will bite. How does using Github even remotely contribute to accepting misogyny in our industry?

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…

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?

Re: Go is moving to GitHub

#185
post #127

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.

Re: Go is moving to GitHub

#186

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…

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

Re: Go is moving to GitHub

#187
> 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.

Re: Go is moving to GitHub

#188
post #75

Earlier quoted context omitted.

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

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

Re: Go is moving to GitHub

#189
post #37

Earlier quoted context omitted.

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) b…

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?

Re: Go is moving to GitHub

#190

Earlier quoted context omitted.

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). http://www.paulgraham.com/avg.html

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

Type-safe json decoding.
Post reply on HN