6 ms·
> one of my favorite parts of Go is the quick build times One of my favourite parts of Go was the quick build times. It used to feel like 'go build' was as fa
by wtbob 11y ago
> one of my favorite parts of Go is the quick build times
One of my favourite parts of Go was the quick build times. It used to feel like 'go build' was as fast as 'python'; sadly, that's no longer the case.
- dilap 11y agoYeah, it got about twice as slow going 1.4 => 1.5, which makes it just slow enough to be annoying. (It's still much faster than something like C++ though, and feels about the same to me as the (snappy) Objective-C.)
- vessenes 11y agoOn the flip side, large programs have gone from multi-second GC pauses to unnoticeable. :) I too miss those fast compile times, though.
- jerf 11y agoDespite the attractive nuisance of "go build", if you're in a fast save-compile-test cycle, you really want "go install". Both do pretty much the same thing (ignoring where the result goes), but install keeps the intermediate package compilations around and does the minimum, whereas build seems to discard them. Put "-v" on both of them and you can see the differences.
- jstarks 11y agoI think go build -i does the same without putting the result in the bin dir.
- vessenes 11y agoI think this is only true if you're building outside your GOPATH. In my case, build -v, build -v -i, and install all have very similar compile times and only show an edited file being compiled when executed from inside my GOPATH. Each of those averaged 3.5s in my codebase, for example, on a freshly changed file. go install's second run is 250ms, but I assume that's because it knows the file hasn't changed. go build -a shows roughly 60 packages and takes 16s, so I would notice if build or install were accidentally recompiling all of them.