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.
> 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 :)