
GitHub's “hub” tool rewritten in Golang - akerl_
https://github.com/github/hub#2x
======
shawnps
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."

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

~~~
stormbrew
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
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?

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

------
bdcravens
Not uncommon. Cloud 66, a platform for hosting Rails apps, rewrote their
toolchain in Go after it was originally written in Ruby.

[https://github.com/cloud66/c66toolbelt](https://github.com/cloud66/c66toolbelt)
[https://github.com/cloud66/cx](https://github.com/cloud66/cx)

Mike Perham, of Sidekiq fame, built his latest product in Go. Ditto for
Mitchell Hashimoto: Vagrant is one of the most popular Ruby products out
there, but most of the other tools his company builds are written in Go.

~~~
twic
Cloud Foundry is also being progressively rewritten from Ruby to Go. As with
GitHub and Cloud 66, the command line client is a prominent example:

[http://blog.cloudfoundry.org/2013/11/09/announcing-cloud-
fou...](http://blog.cloudfoundry.org/2013/11/09/announcing-cloud-foundry-
cf-v6/)

I'd be interested to see a transition matrix for rewrites (or comparable
writing-the-next-thing efforts) between various languages. Here we have Ruby
projects moving to Go. I've seen Java projects move to Scala. Twitter moved a
bunch of stuff from Ruby to Scala, and i think they moved at least one thing
from Scala to Java. Puppet Labs are moving from Ruby to Clojure. But i've
never seen anyone move from Java to Go, and i have no idea if there's a
popular transition from Python or Node.

It would be really, really interesting if there was a lot of flux to Go from
Ruby, but not from Python and Node.

~~~
alexatkeplar
At Snowplow we are steadily rewriting 3 Ruby apps, one each into Go, JRuby
(not really a rewrite) and Scala, choice driven by a few domain-specific
factors.

Go, JRuby and Scala all meet our new criteria for ops-friendliness, which are:
1) the app must be user-installable by a single wget from BinTray 2) the app
must have 0 or 1 [the JVM] external dependencies 3) the app must not require
any special environment to run in. From a packaging perspective, we're using
`godep go build`, `warble` and `sbt assembly` respectively.

I've never worked with anything as install&run-hostile as Ruby.

~~~
twic
Random tangent: if you're getting the binaries with wget, how are you handling
versions? Do you have a way to say "install version 0.0.72 on this machine"?
Do you have a way to ask "what version is installed on this machine?".

I've worked with (mostly, built!) deployment systems that used rsync, scp,
wget, Maven, and apt-get, and i've come to be strongly in favour of systems
which bake versioning in right at the bottom, in such a way that you can issue
commands and make queries in terms of versions right there on the box, without
having to refer to some external ledger. Both for convenience, and for the
consistency of code and metadata.

~~~
alexatkeplar
We're basically following the HashiCorp way, where each binary is in a zipfile
specifying its version, the binaries don't have version-numbers in them but
all binaries respond to a --version usage flag. [1] We then unzip the binaries
into versioned folders so we can have multiple versions on the same box. This
works pretty neatly with our Ansible playbooks too. [2]

[1] [http://www.consul.io/downloads.html](http://www.consul.io/downloads.html)
[2] [https://github.com/snowplow/ansible-
playbooks](https://github.com/snowplow/ansible-playbooks)

------
aikah
Afaik it was previously in ruby right? I need to check out the source code
,that's definitely an interesting project.

any windows build out there?

~~~
bacongobbler
Yes, it was previously written in Ruby.
[https://github.com/github/hub/releases/tag/v2.2.0-rc1](https://github.com/github/hub/releases/tag/v2.2.0-rc1)
has a standalone binary release for Windows.

------
bentoner
Is there anything like this for gitlab?

~~~
sytse
GitLab B.V. CEO here, thanks for asking, a couple of command line tools for
GitLab are listed on
[https://about.gitlab.com/applications/](https://about.gitlab.com/applications/)

------
taybin
Isn't it more lines of code now?

~~~
lgas
I don't know the answer to your question, but even if we assume it is. Why do
you ask? This is just one of many tradeoffs between the two languages. Do you
think the number of lines of code is particularly important in this case for
some reason?

~~~
lambda
Number of lines of code can be used as a (very) rough metric for complexity;
expressing the same application in more lines of code may mean that the new
implementation is a bit more complex, harder to work with, more to review,
etc.

Of course, this is quite a rough metric; some languages are much denser per
line (like APL/J/K and others in that family), so it's definitely not an
absolute rule. But it can be interesting to compare a direct port of a
reasonably complicated application from one language to another, to see how
the abstractions in each language hold up; just like it can be interesting to
compare the speed when porting from one language to another, even though there
are plenty of caveats there too.

~~~
NateDad
Lines of code is a pretty poor measure of anything except lines of code. More
lines could be more clear or less clear. Unless we're talking an order of
magnitude, which seems unlikely.

------
karissa
Why was this necessary? Since hub is a distributed tool, users will now have
to download Go on my local machine. Pretty big dependency, if you ask me.

~~~
xanadohnt
To build it? Yes. To run it? No. Go apps don't require a runtime. The only
thing necessary is distributing the platform-specific binary.

~~~
chimeracoder
> Go apps don't require a runtime.

Go applications do require a runtime, but the executable is statically linked,
so the binary executable ships with the runtime.

The rest of what you said is correct. The only reason you need the Go
development tools installed is to develop the application or to compile it
from source.

