4 ms·

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/sta

This is basically a wrapper for 'go install'. See this post / linked blog posts for an explanation why this is faster/useful: https://twitter.com/davecheney/status/697171533215576064 https://twitter.com/davecheney/status/697171533215576064

nickcw 10y ago
Yes, never use go build, always use go install! go build builds everything, whereas go install does an incremental build on the stuff that has changed and installs it (either in GOPATH/bin or GOPATH/pkg).
- jjnoakes 10y ago
  Why does "go build" build more than what is necessary for "go install"? Shouldn't "go build" just do incremental builds and be faster across the board?
- ithkuil 10y ago
  FYI, there is also `go build -i`, which is behaves like `go build` in terms of what executable artefacts it produces and where it puts them (i.e. it doesn't install stuff in $GOPATH/bin) but preserves object files for all the dependent packages like `go install` does
fitzwatermellow 10y ago
"all the go commands operate on packages, the use of files is a degenerate case only to support go run" guilty. typing in "go run" for quick scripts is one hard to conquer habit ;)
- jerf 10y ago
  For quick scripts I don't see how it's wrong. I mean, even wrong is really just "wasting time a bit" here.
peterevans 10y ago
Running `go build` is a lot like running `make clean` before you compile.
- TheHippo 10y ago
  Just use `go build -i` to install everything and compile only packages that have changed.
jerf 10y ago
After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't benchmark two fundamentally different things like that. Incremental builds, regardless of language, are not "3x faster" or "9x faster", they're doing fundamentally less work. It's not quite correct to say they're in a different O() class, but that's at least the right sort of thought. O(n^2) algorithms aren't any number of "x" times faster than a O(n^3) algorithm, they're more fundamentally faster than that metric can capture; similarly here. To the author, I'm not complaining that you have this on github per se, but you may want to make it more clear what's going on here if you're going to submit it to HN. For instance, this is one of those projects where you could literally inline the source into the README.md. And I'd drop the benchmarks, those really aren't useful. Or at least drop the "x times faster" column.
- nemild 10y ago
  I have to echo everything said by @jerf. One additional suggestion is to write a blog post highlighting ways to improve the workflow for go developers and help them to understand why certain things are better than others, as your work here slots in nicely. You could also explain in detail what goes on behind the scenes in an incremental build.
- tptacek 10y ago
  You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.
  - jerf 10y ago
    The "it could create good comments" is not a good metric for not flagging something, because there is no link for which that is not true, or at least someone would argue for it. While I again want to emphasize I'm not really being that critical of the author for creating it, because people are welcome to put whatever they want on github, it's a thin piece of content whose thin content is also somewhat misleading, that was upvoted to the top of HN. I'm still comfortable with this, barring the admin staff disagreeing with me.

nickcw 10y ago

Yes, never use go build, always use go install! go build builds everything, whereas go install does an incremental build on the stuff that has changed and installs it (either in GOPATH/bin or GOPATH/pkg).

jjnoakes 10y ago
Why does "go build" build more than what is necessary for "go install"? Shouldn't "go build" just do incremental builds and be faster across the board?
ithkuil 10y ago
FYI, there is also `go build -i`, which is behaves like `go build` in terms of what executable artefacts it produces and where it puts them (i.e. it doesn't install stuff in $GOPATH/bin) but preserves object files for all the dependent packages like `go install` does

fitzwatermellow 10y ago

"all the go commands operate on packages, the use of files is a degenerate case only to support go run" guilty. typing in "go run" for quick scripts is one hard to conquer habit ;)

jerf 10y ago
For quick scripts I don't see how it's wrong. I mean, even wrong is really just "wasting time a bit" here.

peterevans 10y ago

Running `go build` is a lot like running `make clean` before you compile.

TheHippo 10y ago
Just use `go build -i` to install everything and compile only packages that have changed.

jerf 10y ago

After reading this discussion and the source of the project, I've flagged this. This "compile Go faster" project really is just about 5 lines of modestly useful bash, and even as someone who often complains people tend to overstate the uselessness of benchmarks, those benchmarks are truly useless. Along with being too small to measure anything useful, almost certainly being dominated by startup overhead, you can't benchmark two fundamentally different things like that. Incremental builds, regardless of language, are not "3x faster" or "9x faster", they're doing fundamentally less work. It's not quite correct to say they're in a different O() class, but that's at least the right sort of thought. O(n^2) algorithms aren't any number of "x" times faster than a O(n^3) algorithm, they're more fundamentally faster than that metric can capture; similarly here. To the author, I'm not complaining that you have this on github per se, but you may want to make it more clear what's going on here if you're going to submit it to HN. For instance, this is one of those projects where you could literally inline the source into the README.md. And I'd drop the benchmarks, those really aren't useful. Or at least drop the "x times faster" column.

nemild 10y ago
I have to echo everything said by @jerf. One additional suggestion is to write a blog post highlighting ways to improve the workflow for go developers and help them to understand why certain things are better than others, as your work here slots in nicely. You could also explain in detail what goes on behind the scenes in an incremental build.
tptacek 10y ago
You flagged _the story_, on HN? Don't do that. It's valuable if only as a hook for comments like yours.
- jerf 10y ago
  The "it could create good comments" is not a good metric for not flagging something, because there is no link for which that is not true, or at least someone would argue for it. While I again want to emphasize I'm not really being that critical of the author for creating it, because people are welcome to put whatever they want on github, it's a thin piece of content whose thin content is also somewhat misleading, that was upvoted to the top of HN. I'm still comfortable with this, barring the admin staff disagreeing with me.