Go from C to Go [video] | Hacker News Reader

Go from C to Go [video]

confreaks.com

68 pointscespare22 comments

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

Man, if Rob Pike and Russ Cox would do the fusion dance, they would be unstoppable!

Name fixed, thank you for pointing it out.

Thank you very much for fixing this!

Youtube link for anyone else who likes to download for sped-up viewing: http://www.youtube.com/watch?v=QIE5nV5fDwA

So who else is extremely curious about the "difficult to explain" goto statement? (about 17 minutes in)

I think he just meant it was hard to capture what it was doing in a brief statement like the others were.

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.

Nice to see this going on.

I think compilers should be bootstraped, after the basic language is in place.

I'm more interested to hear `from C++ to Go` stories :)

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.

Part of me dreams that they'd be able to convert the whole Plan 9 OS into Go one day, but that's probably hoping for too much.

What would be the point? (serious question).

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 has no #ifdefs ano no preprocessor macros.

Seems like a rather pointless dream. What would be the benefit? A slower OS with GC pauses?

Plan9 was already largely rewritten in a precursor to Go called Limbo. It's garbage collected and runs on a virtual machine. http://en.wikipedia.org/wiki/Inferno_(operating_system)

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.

If we've learned anything in the last two decades it's that speed matters more than memory safety.

Right guys?

Actually yes.

Users don't give a rats ass about memory safety (as long as it decent enough), but they'll switch to a speedier app in a heartbeat.

An OS that was really easy to study, extend and modify, due to the simplicity of Go.

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.

Reply on news.ycombinator.com