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

OpenGL and LockOSThread

[Anonymous Coward]

Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. (see https://github.com/golang/go/wiki/LockOSThread) Are there any plans to fix this?

Re:OpenGL and LockOSThread

[genocitizen]

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).

Re:OpenGL and LockOSThread

[Anonymous Coward]

Instead of linking your app to OpenGL you can instead create a separate process that will do that and communicate to it through a socket. You know, like X11 does. This way you are not putting driver guts in your process space like Win 3.1 used to do. See http://msharov.github.io/gleri... for an example.

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.

Wisdom of naming it "Go"

[ZeroPly]

There's already a game called Go, which has about a gazillion articles on how to program it. Couldn't you come up with a name that would be less ambiguous? Now, when you see a user group for "Go programming", you have no clue which one it is.

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.

Re:Wisdom of naming it "Go"

[OrangeTide]

why couldn't the name have been a SHA-256 hash of the initial specification document or a UUID. So instead of "Go" we could all say "one two three echo four five six seven dash echo eight nine bravo dash one two delta three dash alfa four five six dash four two six six five five four four zero zero zero zero". Then it wouldn't be ambiguous and unlikely to have search collisions if you search as "123e4567-e89b-12d3-a456-426655440000"

Why the hell would anyone use Go?

[xxxJonBoyxxx]

Why the hell would anyone use Go?

(Serious question, since our editors didn't tell us why Go was created, what Go's intended purpose was and whether or not anyone is actually using Go.)

C vs Go

[claude.j.greengrass8]

How does 'The Go Programming Language' compare to 'The C Programming Language'?

Why was package versioning left out?

[genocitizen]

Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...

Re:Why was package versioning left out?

[TopSpin]

I'd be a Go programmer today except for this. Every major programming platform in use today has a module system to manage dependencies except Go. Go gives you "go get" to haul gobs of source into your tree, after which you get to build and maintain the mess.

The Go folks cop-out and say this problem is one "for the community." Well, it has been six years and "the community" is still schlepping around, making messes with "go get" and inventing bad workarounds for the projects.

Got a plan for this? You should.

Re:Why was package versioning left out?

[ewhac]

Because package versioning is not a language issue. It's a build issue, and should be part of your build system.

"But go get ... reaches out and..." Stop. go get isn't part of the Go langauge; it's the default Go build environment. And yes, it lacks many features you'd want in a so-called "professional" build system (whatever that means this week).

I get the impression that Go was perhaps intended to be used with repo, a tool principally used for managing the Android project, but also used elsewhere inside Google to manage large numbers of independent Git repositories. With repo, you establish a common branch or tag name across all the repositories that comprise your project, then "repo sync" to them. Poof! Build and version management. (Sorta.)

Re:Why was package versioning left out?

[NostalgiaForInfinity]

Because package versioning is not a language issue. It's a build issue, and should be part of your build system.

In many languages, building code is a language issue. The fact that Go takes a fairly old-fashioned view of batch compilers and separate build systems is just a choice it makes, not a fundamental part of nature. Furthermore, language issue or not, the question simply becomes why are the commonly used build systems for Go so poor.

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.

Usage

[behrooz0az]

For what scenarios and projects do You recommend it and for which you recommend against using Go?

Why can't you mark a class with an interface?

[bigsexyjoe]

I can understand the convenience of not needing to mark a class as an implementer of an interface. But on the other hand, it would be nice if you at least had the option of marking a class as an implementer of an interface, so your IDE could tell you your class is not complete.

Re:Why can't you mark a class with an interface?

[Fwipp]

I usually use the following method: https://play.golang.org/p/iF_d... - Attempting to run this will give a compile error. Once you implement MyType.Foo(); it will compile and run successfully.

The only added part is line 10.

Gos potential

[Qbertino]

What serious long-term real-world potential do you see for Go?

How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?

Official Go IDE?

[Qbertino]

Is there an official cross-plattform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go?

I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?

Re:Official Go IDE?

[motorsabbath]

Sorry, was late last night. LiteIDE is a go-centric ide with lots of great hooks for that language. I run it on Linux, OSX and Win10.

https://code.google.com/p/liteide/

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.

Do you hate go fanboys as much as I do?

[slashdice]

Come on, be honest!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:I worry about autonomous language activities

[radish]

If your program runs on a machine which is connected to a network then it's an attack vector, even if it doesn't directly offer network services. Look at the huge number of vulnerabilities in things like file viewers or graphics rendering libraries.

Sure, if you're writing an application which you know will only ever be run on airgapped machines with no removable storage then maybe you can not worry about security. Those applications are few and far between.

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!

Re:I worry about autonomous language activities

[bobbied]

Java is LICENSED by Oracle who doesn't give out the source code... Go is BSD licensed and has source code so you can build your own copy.

Check with Oracle about the terms they use if you want to distribute their Java Virtual Machine in a commercial product. I can assure you it involves you providing them with cash before they will let you even distribute Java, unmodified, as part of your product. I know this from experience. I'll warn you, Java from Oracle does NOT come cheap if you wish to distribute it. Sure they will let you and your customer download it for free, but they want their cut if you download and distribute Java to a customer.

With Go, there will be no such restriction. You can build and distribute Go to your hearts content w/o paying anybody even if you charge for it. You can embed Go in a project, modify it and sell it without having to give up your source code (as I read the license) as long as you leave the BSD license alone.

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.

The future of Go

[Serious Callers Only]

Now that Go has been in the wild for some time, which parts of the language would you change, and which bits have been an unexpected success?

Are there any plans for Golang version 2, and what might that include?

Re:Runtime

[Serious Callers Only]

Sure, here's one from Russ Cox: https://news.ycombinator.com/i... Ultimately, those criticisms are not very interesting, because as a Go programmer these are tools you use as an end-user, not something which dictates how you program, and can and will be improved behind the scenes.