Design by consensus generally produces inferior results. The first version of the most noteworthy innovations are often the result of a single person's effort. But it's also evident big projects are the results of teams. You can't produce something big without a team.
So what makes me uncomfortable is that I don't see one of the inventors of Go having produced a rough version one before pulling other people in (but to be fair, I simply don't know).
I'm more suspicious about the first Go program. Was computing a prime sieve the number one problem the Go creators had? Doubtful. When C was being written, the authors were also writing an application they deeply needed: UNIX.
Finally, the thought of making something "serious" spoils the general hack flavor of innovative solutions. It's like a beacon that ideas are about to start being policed, which sounds like the opposite effect consensus intends to produce. It may be a good idea to keep a project non-serious as long as possible instead of optimizing it prematurely.
Thanks for elaborating. The interpretations you're using are not what came across in the talk. The notes are just notes, so some of the nuance is lost. I'm told there will be videos in two weeks.
Design by consensus is different than design by committee. In the latter, there is horse-trading and the like, so that basically everyone's ideas go in. In contrast, design by consensus means that nothing went into Go until all three - Rob, Robert, and Ken - agreed it was right. That's actually a higher bar than design by just one person.
The Go spec came before the Go implementation. That's actually important too - it's not an implementation-defined language - and the prime sieve was written as a complete example program for the spec. It's still a decent example of what you can do with just plain Go, without any libraries. Go was meant for networked servers, but a complete HTTP server would have been way too large (remember, there were no libraries yet!).
Go certainly had a target: the kinds of networked servers that Google builds. The first real Go programs were exactly those servers. But it takes a lot of code to build up to that. For much the same reason, you can bet that UNIX was not the very first C program; something like hello world (or maybe just 'exit 0') probably was. Judging Go by the prime sieve is like judging C by "hello world". Obviously greeting the world was not the number one problem the C creators had.
In the context of the talk, "serious" does not mean what you are saying. Around July 2008 the first draft of the current compiler and runtime started working on both Linux and OS X, but nearly all of the standard library, many key language features, and much reworking of the existing things were yet to come. Serious does not mean frozen here. It means that Go started being a focus of active development for more than just the original three authors. (In particular, Ian Taylor and I joined the team, and development accelerated quite a bit.)
Stepping back, the focus of Andrew's talk was how changes to Go were proposed and made, and how that process has changed over time. For more about the actual design, see Robert's talk, the Evolution of Go (https://sourcegraph.com/blog/live/gophercon2015/123645585015). And again the video will contain more nuance than the notes.
Actually, he adapted BCPL by changing a bit the syntax and taking a few things out to fit into the PDP, but even the manuals were almost a copy from the BCPL ones.
"The decision process was consensus driven."
"The first Go program was the prime sieve."
"In July 2008, the project became more serious."