cmd/go: go get extremely slow with no feedback by default

[Miserlou]

What version of Go are you using (go version)?

$ go version
go version go1.7.3 darwin/amd64

What did you do?

go get appears to have no useful feedback by default.

To reproduce:
go get github.com/die-net/dhtproxy
This then appears to freeze for about 10-15 minutes. There is no feedback.

Eventually figured out that I can:
go get -u -v github.com/die-net/dhtproxy
To see the progress, and it appears that because youtube/vitess is absolutely gigantic, this command takes forever.

What did you expect to see?

I expected to see something along the lines of "Fetching project, fetching deps, installing deps, etc", with some kind of progress bar.

What did you see instead?

Nothing. It just sits there for about 10 minutes. I thought it was broken.

The solution is obvious - enable -v by default. It's terrible CLI design to have a process run for 10 minutes with no output by default, it just seems like it's broken.

[bradfitz]

That is the Unix way: be quiet by default, unless verbosity was requested or there's an error.

I don't think this is something we'll be changing. Even more people would be against what they'd consider spam (-v) by default.

[Miserlou]

The Rule of Silence isn't that programs should be absolutely silent unless there is an error or output is specifically requested, it's that programs shouldn't output unnecessarily. Given feedback that a process that takes 15 minutes hasn't hung isn't unnecessary, in fact, it is good CLI design.

For reference, none (0) of the other package managers I have tested are silent by default.

$ pip install test
Collecting test
  Downloading test-2.3.4.5.tar.gz
Building wheels for collected packages: test
  Running setup.py bdist_wheel for test ... done
  Stored in directory: /Users/rjones/Library/Caches/pip/wheels/0e/83/0d/f0f92214b5cce4bcbce4958ddacebf926e1c54c8445f0ba167
Successfully built test
Installing collected packages: test
Successfully installed test-2.3.4.5

$ npm install test
/tmp/
└─┬ test@0.6.0 
  └── ansi-font@0.0.2 

(npm has a --silent flag for this feature)

$ brew install test
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 2 taps (homebrew/core, homebrew/versions).
==> New Formulae
homebrew/versions/postgresql95
==> Updated Formulae
ruby ✔                                                                          tig                                                                             tile38
==> Deleted Formulae
homebrew/versions/postgresql93

Error: No available formula with the name "test" 
==> Searching for similarly named formulae...
These similarly named formulae were found:
cpptest                   cxxtest                   gjstest                   homebrew/science/swetest  memtester                 slowhttptest              testdisk                  unittest                  vttest
cpputest                  git-test                  homebrew/games/minetest   js-test-driver            phoronix-test-suite       speedtest_cli             testssl                   unittest-cpp
To install one of them, run (for example):
  brew install cpptest
==> Searching taps...
These formulae were found in taps:
homebrew/completions/ctest-completion                       Caskroom/cask/aja-system-test                               Caskroom/cask/nsregextester                                 Caskroom/versions/emacs-pretest
homebrew/emacs/test-simple                                  Caskroom/cask/colortester                                   Caskroom/cask/sqlitestudio
To install one of them, run (for example):
  brew install homebrew/completions/ctest-completion

etc.

I think to say "because it's Unix" is a bit disingenuous. It's extremely common for Unix programs with long-running tasks to have progress bars - see rsync, wget, git, etc.

What's the advantage to not having a progress bar here? It seems like the benefits of "not seeming totally broken" vastly outweigh the benefits of "not annoying a small percentage of users who hate feedback and also refuse to use --silent".

[dominikh]

While I don't think that any of the package managers you have mentioned are good examples (they're all far too noisy all of the time), I do agree that some progress indication for go get couldn't hurt. GitHub in particular has stretches of rather slow clone speeds, and the overall runtime depends on the number of dependencies, which isn't obvious or known to the user beforehand, so having to actively decide to use -v isn't really a great solution.

Now, a progress bar isn't really an option -- it's too noisy by default, and not all VCSs support progress bars by default. Enabling -v by default is also too noisy.

Unfortunately I can't really think of a mechanism that is not noisy and at the same time provides enough information when needed.