Go: cmd/go: go get extremely slow with no feedback by default
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.
Miserlou
All 3 comments
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.
bradfitz
on 17 Nov 2016
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/
└─┬ [email protected]
└── [email protected]
(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".
Miserlou
on 17 Nov 2016
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.
dominikh
on 18 Nov 2016
Related issues
enoodle
·
3Comments
gopherbot
·
3Comments
dominikh
·
3Comments
OneOfOne
·
3Comments
longzhizhi
·
3Comments
Most helpful comment
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.
(
npmhas a--silentflag for this feature)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".