The Go ‘builder’ for Plan 9 386 is on the chopping block: https://groups.google.com/forum/#!topic/golang-dev/QW4zUbMHMBM https://code.google.com/p/go-wiki/wiki/PortingPolicy
Lucio, there is no symbiotic relationship between Plan 9 and Go. Go is its own language, and maybe eventually platform, that does share some history with Plan 9 and various other spin offs. But though it started with a few people who happened to have worked on Plan 9 in the past to hone their ideas, the minimal stubs used in Go that are similar to core Plan 9 libraries are just that, mechanisms to bootstrap the language. Taking libc and libbio and the initial C toolchain is a great way to start. I do think they’ve done a very nice job at getting the language off the ground on several platforms. And it’s great to see the Go talks and references back to CSP. But at the end of the day, Go is a very different research platform that doesn’t really map onto what draws many of us to Plan 9. It’s a great tool to have in the shop, but like any combo-tool, sometimes you just have to put it on the bench so you can really use the kW CO2 laser without being distracted. On Dec 4, 2013, at 12:19 AM, lu...@proxima.alt.za wrote: >> what would we recover from? divergence? go never left the building >> as it wasn't in the building to begin with. i think this is likely what >> you may be missing. > > Are you suggesting that any efforts to keep Go and Plan 9 in sync > should be measured purely against short term gain? To me, that makes > Plan 9 a superfluous platform for Go: the cost of maintaining the > port(s) would never be recoverable in deployment of Go applications to > any Plan 9 platform. > > On the other hand, if Go and Plan 9 continue to influence each other's > development and philosophy, I think both will benefit, as well as > their respective communities. The discussion here, superficial as it > is, is a case in point. > > ++L > > > >