Hacker News Reader

Comment by drucken | Hacker News Reader

Unfortunately, Go with its mandatory GC is about as appropriate for systems programming as Java, regardless of how its marketed...

View on HN

I don't know. Linus claims he can imagine writing an OS in Go (after they've spent a decade working the bugs out). Which is probably the most positive thing I've heard of him saying about writing kernels in other languages, and I'm inclined to trust his judgement over my own here.

EDIT: My memory was almost correct, he said that (in sharp contrast to C++) he can imagine letting Go into the kernel but not for a long time. http://www.realworldtech.com/beta/forums/index.cfm?action=de...

EDIT2: s/Linux/Linus/

I believe you meant Linus.

You're really misrepresenting that thread. Here[1] Linus says C is pretty readable in patch format, because it doesn't do overloading (unlike C++, which was the thread's conversation topic) and thus doesn't much depend on some outside context. Also, C gives the required level of control for kernel programming, in terms of memory model and concurrency (and those conditions implicitly exclude Go), but higher-level languages have something to offer for other problem domains; and in that context GC or concurrency primitives become interesting again.

In answer to that last paragraph, someone asked about Go, which is where you got Linus's overall noncommittal answer.

[1] http://www.realworldtech.com/beta/forums/index.cfm?action=de...

Go allows the same of control over the memory layout as C, this differentiates it from most other garbage collected languages.

Go is a perfectly fine language for kernel mode development, I am aware of at least three efforts of writing an operating system in Go (one such effort being mine).

I do agree though that Go is not the right language to use in conjunction with the rest of the Linux kernel. While Go used for a kernel is perfectly fine, it forces you towards some design decisions and constraints that do not exist in the Linux kernel as it stands today.

For the more traditional definitions of "systems programming", yes. I would agree with that.

However I don't think anybody is really marketing Go for that niche.

Originally they were targeting "systems programming", and, being roughly the contemporary of the most well-known go authors, "systems programming" used to mean compilers, assemblers, and the like. In this meaning, this would also include browsers, although Mozilla is going for Rust.

Today, "systems programming" is more taken to mean "kernel programming", and I don't get the sense that is what was meant by the senior authors of go.

Originally they were targeting "systems programming"

Choose the greatest impediment and cite it as a primary goal.

I am not quite sure if I follow you. Are you saying that "systems programming" is the greatest impediment?

Targeting systems programming is. The existing languages used there are rather firmly entrenched.

And that's a problem. If you want to do system programming, there's C. And that's pretty much it. I don't think this is a very favorable situation.

Why not? It's the language that was used to write the OS, which is why Perl and shells still hold sway here as well.

I always believed "system programming" meant "programming operating system components or the whole operating system" and Wikipedia seems to agree:

http://en.wikipedia.org/wiki/System_programming

Last time I looked, inside of the Go libraries which had to do some tricky things there was some C code, meaning that even Go authors weren't able to write everything in Go. So Go can't be a substitute for C, and as long as most of the system programming is done in C, no go for Go.

That's like saying C is not a system programming language because if you write a kernel you need to write parts of it in assembly, and you need to write parts of libc in assembly as well!

Parts of the runtime are written in C and assembly, but that's because there is power in breaking abstractions: http://research.swtch.com/goabstract

As it stands today, Go can be used to write operating systems. Yes, you will have assembly, yes you will likely also have C, so what?

That is what "system programming" means these days. It used to exclude operating system kernels, real-time components.

I suspect that it isn't so much that they aren't able to write everything in Go, but more that it isn't a priority for now. It wouldn't surprise me if Go wasn't eventually self-hosting.

I'd rather reply to wglb, but he's gone too deep...

Anyway, "systems" in this case includes daemons and server processes. I'll update with a reference if I can find it in the Go context.

>"Anyway, "systems" in this case includes daemons and server processes."

For that sense of "systems", Go excels and Java enjoys a great deal of popularity.

Me thinks Go's niche is to be an accessible, imperative Erlang.

It is already well equipped to write distributed network servers, web servers, message queue servers and such.

I can, and in fact I do write an OS in Go, it's suitable enough for writing a kernel for me.

Link? :-)

I can't show a link to the work I do now, sorry, but here's a link to a toy operating system written in Go that proved to me it could be done and inspired me to try it myself:

http://code.google.com/p/gofy/

What do you find incompatible between GC and systems programming?

I think people generally assume systems programming requires low latency and that using a GC implies high latency. That's mostly, but not strictly, true. If you're writing a web server, as opposed to a missile guidance system, the occasional GC pause is probably not a dealbreaker.

Here's an article from IBM on their work on real-time Java, where they develop a GC that can provide a bound on latency, and on the amount of time spent doing GC: http://www.ibm.com/developerworks/java/library/j-rtj4/

Based on that, I don't think I'd rule out the feasibility of doing a missile guidance system in a GC language.

Reply on news.ycombinator.com