> I don't see how they would benefit from being rewritten in go. Go versions of base Plan 9 tools would be very useful to me for a number of reasons. Unfortunately, none of them have to do anything with Plan 9 (but then almost nothing posted on 9fans does) and probably my reasons don't apply to many other people, but here they are nevertheless.
Sometimes I need to deploy something written in rc(1) over a heterogenous Linux cluster, and a statically compiled rc(1) would be a blessing. I don't want to deal with deploying all plan9port/9base and "modern" distributions make building plan9port statically very hard and annoying. A Go version of rc(1) would also make it easier to be be embedded in Go programs. I'd also want a static version of sam to run on servers by copying it through ssh without having to install it first. I avoid the distribution craze as much as possible, I netboot nodes with just a kernel and busybox in an initrd. I would love to have Plan 9 tools in that initrd instead of busybox. A static Go binary that contains all the tools would be a blessing. Now one can argue that building rc(1) and sam(1) statically can be done, albeit it requires tinkering, embedding rc(1) in Go is not that useful, and plan9port can be made into a single busybox-like binary with some effort and you'd be right. It's not much work, but it's work I have to do, and since it's only myself who is interested in what I written above it would be me that would have to maintain all this stuff. A Go version of the tools would be more interesting for many people, so there would be more people who would use and maintain it (including myself), and this version would support my use cases out of the box without any effort. -- Aram Hăvărneanu
