People who have posted the original video, if you are reading this, please fix the speaker's name in the youtube video title. His name is Russ Cox, not Rob Cox. It pains me to see wrong names, it almost feels to me like miscrediting :P
Yes, but he made it sound like it was a legit use of the goto statement, which makes it more intriguing what it can be if it doesn't fall under any of the other descriptions.
This presentation is about using an automated program to convert the existing Plan 9-based Go compiler suite from C to Go, it's not a "rewriting infrastructure in Go" story.
I assume you are talking about the user-space utilities. Having them in Go on Plan 9 would not be the best idea at the moment, Go binaries are big, and while on Unix this is a non-issue, in Plan 9, where every binary has to travel over the network this is not the greatest idea. Perhaps Go binaries will become smaller in the future, but Go only exists on 386/amd64/arm at the moment, and on Plan 9 only the 386 port works. Plan 9 also works on MIPS and POWER, and it worked on SPARC and ALPHA and many others too, and you can still compile all the binaries for those architectures, in case you decide to write a new POWER8 or SPARC64 kernel. Plus there's an impedance mismatch between how Go does things and how Plan 9 does things, for example in the area of networking. I'm very happy with Go's networking on Unix, it's so easy to use and makes things so much nicer. It's very different than the Plan 9 model though, and on Plan 9 Go network programs don't fit right.
Having plan9port utilities in Go would also not be the best thing. I run plan9port on Irix. I ported Go to Solaris because I had plan9port working on Solaris. If plan9port depended on Go, I probably wouldn't have started the port.
All my arguments so far ignored the fact that the few people interested in Plan 9 are already very familiar with the C sources, and many of them don't even care about Go that much.
I really wish Go would fit better in Plan 9. I really miss Go when I have to write C.
For me, the point would be having an OS that was really easy to study, extend and modify, due to how easy to read Go is. No more ifdefs, no preprocessor macros, just clean code.
Plan 9 and Inferno are very related, but I wouldn't say Inferno is "Plan 9 rewritten in Limbo", nor is Limbo equivalent enough to Go for the comparison to make sense.
First, the Inferno kernel is written in C, not Limbo, and is somewhat similar to the Plan 9 kernel to the point that is moderately feasible to port drivers from Plan 9 to Inferno.
Second, you could say acme was rewritten from alef (not C) to Limbo, and maybe you can say cat, tail, mk and yacc were "rewritten in Limbo", but soon after the list ends. Most utilities are genuinely new utilities that make use of the different abstractions provided by the operating system. Of course there are lots of high-level similarities, but they are quite different programs.
This brings me to my next point, the abstractions provided by Plan 9 and Inferno are very different. Different enough that a new set of tools makes sense. For comparison, rewriting C code to Go uses the same underlying abstractions, so it doesn't make as much sense.
Another point I want to make is that compiled Limbo programs are extremely small, and Limbo is dynamically loaded, unlike Go.
Yet another point is that Limbo programs use reference counting plus a real-time garbage collector for cycles, which is made easier by Limbo and Inferno constraints. Go uses neither and the language is different enough to prevent a real time garbage collector.
There are OSes out there that are easy to study, extend and modify even in C. Some are even specially designed for such purposes, like, say, Minix.
Go is not that simpler compared to C -- and the parts where it IS simpler (e.g GC) make it less good for an OS. It would have been a slow, proof-of-concept thing, of little value.
