I recall one guy at the labs(!) who would ruthlessly avoid printf because it dragged in too much stuff. I think he ran out of people to argue with 30 years ago. On 24 Mar 2013 10:47, "andrey mirtchovski" <mirtchov...@gmail.com> wrote:
> > If you want real programs which are bigger that I (we) actually use that > will > > be (much) bigger in go: > > > > ls, cp rm mv cat acid, I can go on. > > > > Small programs are useful and important. > > here's a representative set. the programs are identical in behaviour > and arguments to the Plan 9 set. the size is as reported by du, in > kilobytes: > > 1456 ./date/date > 1460 ./cat/cat > 1564 ./cleanname/cleanname > 1564 ./tee/tee > 1736 ./echo/echo > 1764 ./cp/cp > 1772 ./uniq/uniq > 1780 ./cmp/cmp > 1780 ./freq/freq > 1780 ./wc/wc > 1792 ./comm/comm > > > binaries are bigger and for example replacing the minimal sets of > commands of > > the system, this can make the > > minimal system at least 5 times bigger easy. > > if that was a real issue you were trying to solve there are things you > can do to help yourself. most notably sticking everything in a single > binary and invoking the right function based on your argv0. it took me > less than 15 minutes to convert the above code to work as a single > binary and most of that was in handling clashing flags (it would've > been a non-issue if I had used flagsets when writing the original > programs). size at the very end: > > $ date > test.txt > $ ln -s $GOPATH/bin/all cat > $ ln -s $GOPATH/bin/all wc > $ ./cat test.txt > Sat Mar 23 17:32:42 MDT 2013 > $ ./wc test.txt > 1 6 29 test.txt > $ du -k $GOPATH/bin/all > 1888 /Users/andrey/bin/all > > the size of the original binaries on plan9 is 588k. what was a factor > of 30 is now a factor of 3. all tests still pass and it took less time > to complete than writing this email. > > there's an even better solution, but it won't work on plan9 because > the go tool is slow there :) > >
