3 ms·

Reasoning behind porting it to Go: https://github.com/github/hub/issues/475 https://github.com/github/hub/issues/475 "My Ruby implementation of context.rb is g

by shawnps 12y ago

Reasoning behind porting it to Go: https://github.com/github/hub/issues/475 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."

JoshTheGeek 12y ago
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.
tinco 12y ago
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.
- shawnps 12y ago
  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 :)
- stormbrew 12y ago
  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.
  - Timothee 12y ago
    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?
    - stormbrew 12y ago
      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/ http://stedolan.github.io/jq/
    - motter 12y ago
      It's certainly worth looking at the standard flag package (http://golang.org/pkg/flag/ http://golang.org/pkg/flag/) if you just need flag parsing. I've also heard good things about https://github.com/spf13/cobra https://github.com/spf13/cobra and https://github.com/codegangsta/cli https://github.com/codegangsta/cli.
    - xkarga00 12y ago
      Read this as well: http://blog.golang.org/json-and-go http://blog.golang.org/json-and-go
- NateDad 12y ago
  >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.
- deleted 12y ago
  [deleted]
- jingweno 12y ago
  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-written-in-go.html http://owenou.com/2013/12/22/fast-github-command-line-client...

by shawnps 12y ago

JoshTheGeek 12y ago

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.

tinco 12y ago

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.

shawnps 12y ago
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 :)
stormbrew 12y ago
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.
- Timothee 12y ago
  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?
  - stormbrew 12y ago
    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/ http://stedolan.github.io/jq/
  - motter 12y ago
    It's certainly worth looking at the standard flag package (http://golang.org/pkg/flag/ http://golang.org/pkg/flag/) if you just need flag parsing. I've also heard good things about https://github.com/spf13/cobra https://github.com/spf13/cobra and https://github.com/codegangsta/cli https://github.com/codegangsta/cli.
  - xkarga00 12y ago
    Read this as well: http://blog.golang.org/json-and-go http://blog.golang.org/json-and-go
NateDad 12y ago
>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.
deleted 12y ago
[deleted]
jingweno 12y ago
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-written-in-go.html http://owenou.com/2013/12/22/fast-github-command-line-client...