4 ms·

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.

by karissa 12y ago

innoying 12y ago
Or like any compiled language they can just grab a binary: https://github.com/github/hub/releases https://github.com/github/hub/releases
- james2vegas 12y ago
  And like any binary releases, there are platforms that are missed/forgotten/not cared enough about.
  - bsg75 12y ago
    Yes, binary releases are a convenience for users of common platforms, and not a catch all for every version of every relevant platform. This is why the source is available. Implementation in Ruby, or any other interpreted language, does not guarantee compatibility. Not all systems have current interpreters or dependencies.
    - lmm 12y ago
      If I'm on a semi-obscure platform like Solaris or GNU/kFreeBSD I'd rate my odds much more highly with Ruby than with something that builds binaries.
      - bsg75 12y ago
        Why? If you are using a platform like that, would you not be adept at building packages from source? I agree that Ruby is likely already installed on those, but having watched co-workers fight version dependency problems with Ruby Gems on OSX, I tend to believe nothing is a universal solution.
        lmm 12y ago
        Adept at building C programs that use standard autoconf? Yes. Adept at building go programs? Not so much, and I probably don't even have the tools installed (unlike with ruby). We'll probably reach a point where go is as much a part of the standard unix install as ruby is, but we're not there yet.
        bsg75 12y ago
        > I probably don't even have the tools installed (unlike with ruby) Provided correct versions are in place. In my aforementioned observations, Gem installation was complicated when the parent app relied on gem versions below the code currently in GitHub. This is of course a problem not unique to Ruby (see: Default Python version on CentOS), based on the number of versioning utilities for Go. I have also had plenty of problems with autoconf's that don't work.
        heavenlyhash 12y ago
        The go toolchain bootstraps a small kernel of itself from normal gcc and I have yet to encounter any outrageous configuration issues. It should be at least as simple as building C programs that use standard autoconf, if not simpler. I've done some work cross-compiling golang on platforms that are not yet officially supported. I think you'll find the support is really remarkably good.
        kaoD 12y ago
        > and I probably don't even have the tools installed (unlike with ruby) So your arguments is basically "I'm a Ruby user" ? I'm neither a Go nor a Ruby user, but I have Go installed on more machines than Ruby... and Ruby is a requisite for running unlike Go!
      - webRat 12y ago
        It takes 2 minutes to google for Go support on all of these platforms. Did you even bother? Go is supported on Solaris and kfreebsd platforms.
        lmm 12y ago
        I have ruby installed on those servers right now. Not so much go. I'm not saying go would be impossible, just that it would be harder.
        webRat 12y ago
        Ok? I bet you can figure this out and I bet it's just as easy as Ruby. http://golang.org/doc/install http://golang.org/doc/install
        lmm 12y ago
        Given that getting Ruby installed on those servers involves doing literally nothing, no, it isn't as easy.
        burntsushi 12y ago
        You're basically arguing a technicality at this point. How important is it that it takes N time to do X and N+epsilon time to do Y? And how much should this affect one's decision for choosing which programming language to use?
        bdcravens 12y ago
        brew install go, apt-get install golang, etc
      - mtrpcic 12y ago
        Like C?
        lmm 12y ago
        Yes. I bet it would take less effort to get a random ruby program running on those machines than a random C program.
        Gigablah 12y ago
        You could've installed Go on all your machines with a provisioning script in the amount of time you've wasted being deliberately obtuse in this thread.
james2vegas 12y ago
But.. Go is Awesome!™
kornish 12y ago
It may be worth noting that there's only a dependency on Go if you want to build from source. The tool is usable on its own after compilation to a standalone binary. See the Readme's "Standalone" section.
deleted 12y ago
[deleted]
nilved 12y ago
No, you can just download a binary. It's necessary because the Ruby version was unbearably slow.
tgkokk 12y ago
Most users can just download a binary from [1], they don't have to compile hub itself. [1]: https://github.com/github/hub/releases https://github.com/github/hub/releases
xanadohnt 12y ago
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 12y ago
  > 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.
bsg75 12y ago
Was Ruby a dependency of the prior version?
- tacticus 12y ago
  Yes.
Sean-Der 12y ago
It was written in Ruby before, requiring the Ruby runtime to be installed. With Go you have actual binaries. They also aren't linked to anything Go specific, so you can easily distribute them without installing anything Go specific on those machines. So in the end the removal of the Ruby dependency should clean up your local machine ;)
sp332 12y ago
Bigger than Ruby?
- JoshTheGeek 12y ago
  No, smaller, because you don't need the Go compiler to run it, just to build it. Therefore, you won't need the compiler at all, just the binary.
MetaCosm 12y ago
"users" will grab the binary and be done.

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.

by karissa 12y ago

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.

innoying 12y ago

Or like any compiled language they can just grab a binary: https://github.com/github/hub/releases https://github.com/github/hub/releases

james2vegas 12y ago
And like any binary releases, there are platforms that are missed/forgotten/not cared enough about.
- bsg75 12y ago
  Yes, binary releases are a convenience for users of common platforms, and not a catch all for every version of every relevant platform. This is why the source is available. Implementation in Ruby, or any other interpreted language, does not guarantee compatibility. Not all systems have current interpreters or dependencies.
  - lmm 12y ago
    If I'm on a semi-obscure platform like Solaris or GNU/kFreeBSD I'd rate my odds much more highly with Ruby than with something that builds binaries.
    - bsg75 12y ago
      Why? If you are using a platform like that, would you not be adept at building packages from source? I agree that Ruby is likely already installed on those, but having watched co-workers fight version dependency problems with Ruby Gems on OSX, I tend to believe nothing is a universal solution.
      - lmm 12y ago
        Adept at building C programs that use standard autoconf? Yes. Adept at building go programs? Not so much, and I probably don't even have the tools installed (unlike with ruby). We'll probably reach a point where go is as much a part of the standard unix install as ruby is, but we're not there yet.
        bsg75 12y ago
        > I probably don't even have the tools installed (unlike with ruby) Provided correct versions are in place. In my aforementioned observations, Gem installation was complicated when the parent app relied on gem versions below the code currently in GitHub. This is of course a problem not unique to Ruby (see: Default Python version on CentOS), based on the number of versioning utilities for Go. I have also had plenty of problems with autoconf's that don't work.
        heavenlyhash 12y ago
        The go toolchain bootstraps a small kernel of itself from normal gcc and I have yet to encounter any outrageous configuration issues. It should be at least as simple as building C programs that use standard autoconf, if not simpler. I've done some work cross-compiling golang on platforms that are not yet officially supported. I think you'll find the support is really remarkably good.
        kaoD 12y ago
        > and I probably don't even have the tools installed (unlike with ruby) So your arguments is basically "I'm a Ruby user" ? I'm neither a Go nor a Ruby user, but I have Go installed on more machines than Ruby... and Ruby is a requisite for running unlike Go!
    - webRat 12y ago
      It takes 2 minutes to google for Go support on all of these platforms. Did you even bother? Go is supported on Solaris and kfreebsd platforms.
      - lmm 12y ago
        I have ruby installed on those servers right now. Not so much go. I'm not saying go would be impossible, just that it would be harder.
        webRat 12y ago
        Ok? I bet you can figure this out and I bet it's just as easy as Ruby. http://golang.org/doc/install http://golang.org/doc/install
        lmm 12y ago
        Given that getting Ruby installed on those servers involves doing literally nothing, no, it isn't as easy.
        burntsushi 12y ago
        You're basically arguing a technicality at this point. How important is it that it takes N time to do X and N+epsilon time to do Y? And how much should this affect one's decision for choosing which programming language to use?
      - bdcravens 12y ago
        brew install go, apt-get install golang, etc
    - mtrpcic 12y ago
      Like C?
      - lmm 12y ago
        Yes. I bet it would take less effort to get a random ruby program running on those machines than a random C program.
        Gigablah 12y ago
        You could've installed Go on all your machines with a provisioning script in the amount of time you've wasted being deliberately obtuse in this thread.

james2vegas 12y ago

But.. Go is Awesome!™

kornish 12y ago

It may be worth noting that there's only a dependency on Go if you want to build from source. The tool is usable on its own after compilation to a standalone binary. See the Readme's "Standalone" section.

deleted 12y ago

[deleted]

nilved 12y ago

No, you can just download a binary. It's necessary because the Ruby version was unbearably slow.

tgkokk 12y ago

Most users can just download a binary from [1], they don't have to compile hub itself. [1]: https://github.com/github/hub/releases https://github.com/github/hub/releases

xanadohnt 12y ago

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 12y ago
> 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.

bsg75 12y ago

Was Ruby a dependency of the prior version?

tacticus 12y ago
Yes.

Sean-Der 12y ago

It was written in Ruby before, requiring the Ruby runtime to be installed. With Go you have actual binaries. They also aren't linked to anything Go specific, so you can easily distribute them without installing anything Go specific on those machines. So in the end the removal of the Ruby dependency should clean up your local machine ;)

sp332 12y ago

Bigger than Ruby?

JoshTheGeek 12y ago
No, smaller, because you don't need the Go compiler to run it, just to build it. Therefore, you won't need the compiler at all, just the binary.

MetaCosm 12y ago

"users" will grab the binary and be done.