ROB PIKE

We're systems software people ourselves. We wanted a language to make our lives better.

The process of software development doesn't feel any better than it did a generation ago.

Dynamic typing is not necessarily good. You get static errors at run time, which you really should be able to catch at compile time.

Web servers are written in C, and if they're not, they're written in Java or C++, which are C derivatives, or Python or Ruby, which are implemented in C.

You have to make a decision whether it's a new product or you integrate it with an existing product. It takes time to work these things out.

We don't believe we've solved the multicore-programming problem. But we think we've built an environment in which a certain class of problems can take advantage of the multicore architecture.

When Steve Jobs died last week, there was a huge outcry, and that was very moving and justified.

Go is an attempt to combine the safety and performance of statically typed languages with the convenience and fun of dynamically typed interpretative languages.

Pretty much everything on the web uses those two things: C and UNIX. The browsers are written in C. The UNIX kernel - that pretty much the entire Internet runs on - is written in C.

To write a kernel without a data structure and have it be as consistent and graceful as UNIX would have been a much, much harder challenge.

Using Unix is the computing equivalent of listening only to music by David Cassidy.

A smart terminal is not a smartass terminal, but rather a terminal you can educate.

There's no such thing as a simple cache bug.

Such is modern computing: everything simple is made too complicated because it's easy to fiddle with; everything complicated stays complicated because it's hard to fix.

If POSIX threads are a good thing, perhaps I don't want to know what they're better than.

Not only is UNIX dead, it's starting to smell really bad.

Eventually, I decided that thinking was not getting me very far and it was time to try building.

Procedure names should reflect what they do; function names should reflect what they return

Sockets are the X windows of IO interfaces.

Why would you have a language that is not theoretically exciting? Because it's very useful.

Narrowness of experience leads to narrowness of imagination

Productivity is most important by engineering management rules, but enjoyment is most important for engineers. One stems from the other.

Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

When there is no type hierarchy you don't have to manage the type hierarchy.

Languages that try to disallow idiocy become themselves idiotic.