It was also important that the result be suitable for large systems software development on modern, networked, multicore hardware.

To achieve these goals, we tried to design a language in which the various elements – the type system, the package system, the syntax, concurrency, and so on – were completely “orthogonal”, by which I mean that they never interact in surprising ways, making the language easy to understand but also easy to implement.”

A lot of Go is new, or at least was designed without direct borrowing from existing languages. The idea of interface types is one example – it’s very different from what “interface” usually means. Go was designed from the ground up to solve our problems, not to be a union of our favorite features from other languages.”

We receive a lot of feature requests, of course, and consider them in light of this orthogonality principle. Lots of people in the open source community have written libraries, tools, and packages for the Go project. The entire job of porting to Windows was done by people in the outside community, for instance.”

Graphics is still my favourite area of computing, making pictures happen by writing code.”

There are many interesting languages cropping up these days, Go among them, and the wealth of choices is a welcome change. Also productivity is surely improved over the last generation. Things are getting better but most of the code I see today is still written in languages I find unpleasant.”

The balance is to do what you can in language design to let good programming shine through. Concurrent programming is one area where it’s clear what can be done.

The best-known approach – memory barriers, locks, semaphores, condition variables, threads – works but requires great skill and understanding and many programmers get in trouble because of the difficulty.

Languages can help a lot by providing easier-to-use, easier-to-understand primitives (which are probably implemented under the covers using locks and so on). Programmers unfamiliar with the traditional kind of multithreaded programming have found it easy to write correct concurrent code using Go’s linguistic support for concurrency, for example. The language doesn’t prevent you writing code with, say, memory races, but it encourages you to think about programming in a style in which they don’t arise as often.”

The processes of writing code and prose don’t feel very similar, but in both I care a great deal about parsimony and grace – style. And in both I do a great deal of rereading and rewriting. The first draft, even if correct, is rarely ‘right’.

That need to rewrite is important and often neglected when coding. Modern programming languages, especially object-oriented ones, are interface heavy. This means that before you can make anything happen you need to write down a lot of preliminaries, often making important API decisions before the best design has emerged. Once it does emerge, there’s so much written down already that it feels counterproductive to back up and rework the interfaces. These languages create a penalty for rewriting that encourages working around early design mistakes rather than fixing them.

I believe this dependence on interfaces before code is a major reason for programs being so much bigger than they used to be. Also, as Peter Weinberger has observed, interface design is hard but critical, so it used to be done only by the best programmers on your team. Now it’s done by everyone, with predictable results.”

Programming languages are all about productivity. That’s their purpose: to make people more productive. Jokes aside, and there are some great ones, no one has designed a language to make people less productive. Special-purpose languages are a double hit, since they focus on expression of solutions within a particular problem domain, automating more of the irrelevant and unnecessary and allowing more focus on the important. Features, then, are not what make languages productive; what does is how well the language fits the problem at hand.

Requests for features in programming languages usually fall into one of two camps. The first is “I need this feature because my problem domain needs it;” the second is “I need this feature because I’m used to it from another language.”

A language designer might think, “I need this feature because it will attract users.” These arguments are not compelling (although they can be shrill) and acquiescing to them leads to big messy languages without focus, workable for many problems but rarely just right.

A feature makes a language better either by fitting smoothly into what’s already there or, perhaps paradoxically, by being orthogonal to what’s already there, so it adds power without mixing in complicated ways with the existing design.

In short, a language aids productivity if it allows succinct, precise expression of the solution to a problem by clean combination of its features. A feature doesn’t make the language better on its own, but a feature that works smoothly with the rest of the language, even if it’s hard to show some specific benefit of the feature in isolation, can have a huge effect.

In that light there are a few “features” in Go that aid productivity: – goroutines, which make it efficient and simple to execute concurrent code
– channels, which combine synchronization and communication to make concurrency easy and safe
– interfaces, which make code extensible, composable, and adaptable after the fact [The word “interface” in Go refers to generalized specification of behaviour; they’re a true language feature unrelated to the “I” in “API”.]

The talk Russ Cox and I gave at Google I/O last year covers these topics in detail.”

The only bad bug is one you haven’t found yet.

I rarely use debuggers, a few times a year at most. Sometimes they’re useful but I find they lead too often to false avenues of inquiry. I like stack traces on failure, which Go provides automatically (as do many languages, but nowhere near all). Beyond that, a good debugger – and let’s admit that most of them aren’t that good – will answer questions correctly, but the problem is that you need to know what questions to ask, and that’s the hardest part of debugging.

Since they make it so easy to ask a question and have it answered, debuggers encourage a sort of microphenomenological, depth-first approach to debugging that is too divorced from the actual program. And even when they lead to the right answer, debuggers create a mindset where a local microscopic fix is done rather than the right, global fix.

It’s better to debug from the program itself. When there’s a failure, the one true fact is the failure itself. Don’t get distracted by other things, just focus on the fact. What could have caused that? What assumptions or invariants in the code might lead to that or, if broken, enable that? It’s almost always better to think about the program first. It’s a discipline that’s hard to acquire but in my experience leads quickly to a proper understanding of the problem and the right fix.

As for the mechanics of it: good tests are always helpful; logging is essential; detailed debugging code embedded in the program can be a boon; and beyond that it’s print statements. The only time I depend on debuggers is when seemingly impossible things happen, such as when I suspect a bug in the compiler or operating system.”