Hacker News Reader

Comment by shawnps | Hacker News Reader

Reasoning behind porting it to Go: https://github.com/github/hub/issues/475

"My Ruby implementation of context.rb is getting unwieldy and in hub v1.11 I feel I've reached the limit of how much I can speed up hub exection. I can't make it much faster than 50 ms due to Ruby interpreter slowness. Go port can execute in under 10 ms, and it's not even specially optimized yet. Go port can also be distributed as a pre-compiled binary, skipping the need to install Ruby, which can be especially tricky and error-prone for Windows users."

View on HN

Somebody rewrote hub in Go a while ago and called it gh. The team behind hub only decided recently to merge in gh and make it the new, GitHub-approved version of hub.

I don't really get what hub does, it's just a wrapper around some git commands + a CLI to github right? What is this 'context.rb' doing that somehow can be sped up by moving to Go?

I have the feeling that the sort of thing Hub is what Ruby's supposed to be good at, and Go not particularly. So the move sounds a bit strange to me.

Anyway, super convenient for them that a Go port already existed, obviously the move makes sense when the source is already there and it has the features and performance characteristics they desire, not to mention dropping the dependency on Ruby.

Yeah, it gives you the ability on the command line to interact with GitHub functionality, like browsing issues, opening a pull request, and so on.

I'm not familiar with their Ruby implementation either, but hey if it works the same way, is faster than it was before, and some developers enjoyed working on it then I guess it's a net positive :)

Quite the opposite, to me this sort of thing is go's killer app. Simple command line tools written in go are considerably easier to both build and use than ones written in ruby, python, or node.js in my experience. I'd much rather have the dependency hell happen at build time than run time. Keeping up a virtualenv/rvm/etc. setup to use some command line tool, or worse having their entire dep tree come bundled with them ala vagrant in a custom ruby install prefix, is a complete pain in the ass.

I've recently been writing command lines tool (for internal use mostly) and wrote them in bash because running other command line tools and checking their exit codes is simpler in bash than in Python for example. Problems start to come up when I have to deal with APIs that return or expect JSON.

From what you're writing it seems that it might be worth checking Go out for that. Would you happen to have pointers for using Go for that purpose?

It's certainly worth looking at the standard flag package (http://golang.org/pkg/flag/) if you just need flag parsing.

I've also heard good things about https://github.com/spf13/cobra and https://github.com/codegangsta/cli.

Read this as well: http://blog.golang.org/json-and-go

Interestingly, the tool that turned me on to using go as a commandline tool builder was a little thing called jq [1] that's a huge huge help in dealing with json from bash scripts. I have no specific pointers, though, so I'm glad some other people jumped in.

[1] http://stedolan.github.io/jq/

>I have the feeling that the sort of thing Hub is what Ruby's supposed to be good at, and Go not particularly.

Actually go is very good at command line applications. The fast at start up time and easy concurrency make CLI applications in go very nice.

I have a blog post talking about the intention of building gh which ends up being hub 2.2.0: http://owenou.com/2013/12/22/fast-github-command-line-client...

Reply on news.ycombinator.com