Except for the fact that it'll be years before all of the subtle bugs are worked out and you can rely on those apps to be as stable as the ones we've got:
We have years. They're passing whether we like it or not. In the meantime you can choose whichever implementation of the Unix tools that you want. In the future there may be more options that fit the bill, developed in a safe language without the kinds of buffer overflows and things that exist in C tools today.
Yeah, just because Joel said so doesn't mean it's true.
I've been responsible for a bunch of rewrites that were resounding successes and typically reduced the bug load (subtle or not) by orders of magnitude.
What's wrong with doing this for fun's sake or educational value (both for the authors or people who want to study Go)?
If it turns out to be more widely used, at least it's safer than C code.
We really need a busybox in Rust or Go. The existing one has licensing problems and security problems, and is built into too many embedded devices.
Busybox is GPLv2. That's the same license as the linux kernel; it's not a problem. You just have to release your modified version of the busybox source if you distribute it in a product. The only difference is that busybox developers enforce the license against the many companies who can't be bothered and respond to requests with lawyers.
That said, a bsd-licensed re-implementation of busybox (still in c) that's pretty far along and has gotten support from some of those companies (including Sony) is "toybox" http://www.landley.net/toybox/
Also, Toybox will replace Toolbox in Android M.
There is a busybox in Go. https://github.com/surma/gobox
What licensing problems specifically do you mean here?
GNU started as GNU's Not Unix, reimplementing Unix userland for free. The people who are adamant about calling it GNU/Linux are, on some level, remembering that the userspace is historically a reimplementation.
Give me a busybox that I can 'go build' and that becomes really quite interesting.