Interviews: Ask Alan Donovan and Brian Kernighan About Programming and Go

Alan Donovan is a member of Google’s Go team in New York and holds computer science degrees from Cambridge and MIT. Since 2005, he has worked at Google on infrastructure projects and was the co-designer of its proprietary build system, Blaze. Brian Kernighan is a professor in the Computer Science Department at Princeton University. He was a member of technical staff in the Computing Science Research Center at Bell Labs, where he worked on languages and tools for Unix. He is the co-author of several books, including The C Programming Language, and The Practice of Programming. Recently, the pair have co-authored a soon to be released book titled The Go Programming Language. Alan and Brian have agreed to give us some of their time to answer any questions you may have about the upcoming book, Go, and programming in general. Ask as many questions as you'd like, but please keep them to one per post.

Comments

Re:Wisdom of naming it "Go"

[JoshuaZ]

I agree. I saw the headline and thought I was going to see an interesting article about Go and computers, maybe something explaining in detail how Monte Carlo methods have made Go programs much more successful than the older brute force used to be. But nope. Maybe someone should write a program in Go to play Go for maximum confusion.

Error Handling in Go

[JPyObjC Dude]

Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.

C's current place in the world

[MountainLogic]

As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C.
PS: Thanks you for co-authoring the most wonderful, perfect, clear and concise technology document ever.

Re:OpenGL and LockOSThread

[luis_a_espinal]

AC was referring to the fact you need to run all OpenGL code from same thread. Go's goroutines are not guaranteed to run on same thread (unless you do some black magic sorcerery).

A deficiency that's not Go's problem to solve IMO.

Re:I worry about autonomous language activities

[radish]

Why aren't you writing in assembler? Actually scrub that - how's your microcode? What always amuses me about the bare metal brigade is that they're often not actually that close to the metal.

Different levels of abstraction work for different tasks, and it's always a trade off. Security vs Reliability vs Performance vs Resource Usage vs Developer Time vs Maintainability vs ... you get the picture. Anyone who tells me their tool of choice is appropriate for all tasks is telling me they have a very restricted view of the world. I write mainly in Scala these days but there are plenty of things I wouldn't try to use it for, and I sure as hell wouldn't write my services in C!

Go objects

[StealthyRoid]

I'm curious as to the design decisions that led to the way that Go objects are implemented, which feel and seem to operate like C structs w/ function pointers. Yes, all objects are essentially structs with function pointers, but most languages provide a good deal of syntactic and functional candy on top of them to make them more useful. With Go objects, you get sortof-inheritance, sortof-polymorphism, and sortof-encapsulation, which requires re-thinking a lot of design patterns that people learn working with languages like C++, Java, and even PHP. That's not necessarily a bad thing, I can see arguments for forcing people to get out of their comfortable patterns, I'd just like to know why.

Re:I worry about autonomous language activities

[snadrus]

These statements come from experiences in other languages with obnoxious GCs. This is a performance-focussed language with great multiprocess primitives. The GC causes far less latency.
https://talks.golang.org/2015/...
Pauses average 1ms and will be halved again next release to 1/2000 of a second which is plenty workable for games & audio mixers
Further, intelligently-written code can massively reduce GC frequency.

A certain high-throughput web service I've built runs GC roughly once per hour (yet services 1000s of concurrent requests). And this is without any serious effort at tuning. This is because (unlike Java, Python, and JS) GC is avoided if possible for stack space (whenever provably-safe) which is freed when it leaves scope. The proving algorithms are improving too.