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

Go is moving to GitHub

groups.google.com

Post reply on HN
Print view View original

201–210 of 244 posts

Re: Go is moving to GitHub

#201

Post by acdha »

NateDad wrote: post #155
srcmap wrote: 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…

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

Re: Go is moving to GitHub

#202

Post by spb »

NateDad wrote: post #176
nhaehnle wrote: post #167

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…

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

Re: Go is moving to GitHub

#203

Post by NateDad »

duaneb wrote: post #164
NateDad wrote: post #158

Earlier quoted context omitted.

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

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?

Re: Go is moving to GitHub

#204

Post by NotSammyHagar »

mnem wrote: post #182
NateDad wrote: post #176

Earlier quoted context omitted.

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

I can't understand why they haven't tried to fix their CLI syntax. Besides having to remember when to do origin 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.

Re: Go is moving to GitHub

#205

Post by wldcordeiro »

DigitalSea wrote: post #69

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…

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.

Re: Go is moving to GitHub

#206

Post by NateDad »

acdha wrote: post #201
NateDad wrote: post #155

Earlier quoted context omitted.

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…

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

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

Re: Go is moving to GitHub

#207

Post by wldcordeiro »

DannyBee wrote: post #84
Navarr wrote: post #68

Earlier quoted context omitted.

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…

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.

Re: Go is moving to GitHub

#208

Post by kyrra »

kyrra wrote: post #98
BruceIV wrote: post #81

Earlier quoted context omitted.

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. http://www.bbc.co.uk/news/technology-20236114

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.

Re: Go is moving to GitHub

#209

Post by acdha »

NateDad wrote: post #206
acdha wrote: post #201

Earlier quoted context omitted.

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

> 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() // e…

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

Re: Go is moving to GitHub

#210

Post by willnorris »

Bahamut wrote: post #83
melling wrote: post #80

Earlier quoted context omitted.

As someone has already mentioned Google already has stuff on Github. Dart: https://github.com/dart-lang And lots of other stuff: https://github.com/google

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

CCA?
Post reply on HN