3 ms·

Good question. Design by consensus generally produces inferior results. The first version of the most noteworthy innovations are often the result of a single p

by gull 11y ago

Good question. 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.

Artemis2 11y ago
> I don't see one of the inventors of Go having produced a rough version one before pulling other people in Well, Ken Thompson did create B...
- pjmlp 11y ago
  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. https://vimeo.com/132192250 https://vimeo.com/132192250
ansible 11y ago
Design by consensus generally produces inferior results. Why is it necessary to speculate about the design of Go? You can read this and decide directly what you think of its design. http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article Better yet, look at some existing projects and see how they are structured. Then make a judgment. Or just walk away... There are plenty of other good programming languages out there.
not_with_retard 11y ago
1) They have a team. 2) You seem to ignore the multiple years of development before coming out publicly about it, then waiting another five for the first version to be released. 3) You rarely actually hear about the first application ever built in a new language. Computing a prime sieve is a wonderful way to test a brand new language. 4) You seem to have your own definition about the word "serious". What if they said they were going to keep the language development "relaxed"?
rsc 11y ago
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 https://sourcegraph.com/blog/live/gophercon2015/123645585015). And again the video will contain more nuance than the notes.

by gull 11y ago

Artemis2 11y ago

> I don't see one of the inventors of Go having produced a rough version one before pulling other people in Well, Ken Thompson did create B...

pjmlp 11y ago
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. https://vimeo.com/132192250 https://vimeo.com/132192250

ansible 11y ago

Design by consensus generally produces inferior results. Why is it necessary to speculate about the design of Go? You can read this and decide directly what you think of its design. http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article Better yet, look at some existing projects and see how they are structured. Then make a judgment. Or just walk away... There are plenty of other good programming languages out there.

not_with_retard 11y ago

1) They have a team. 2) You seem to ignore the multiple years of development before coming out publicly about it, then waiting another five for the first version to be released. 3) You rarely actually hear about the first application ever built in a new language. Computing a prime sieve is a wonderful way to test a brand new language. 4) You seem to have your own definition about the word "serious". What if they said they were going to keep the language development "relaxed"?

rsc 11y ago

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 https://sourcegraph.com/blog/live/gophercon2015/123645585015). And again the video will contain more nuance than the notes.