Text file
talks/2015/gophercon-goevolution.slide
1 The Evolution of Go
2 GopherCon 2015 Keynote - July 9, 2015
3
4 Robert Griesemer
5 Google, Inc.
6 gri@golang.org
7
8
9 * Video
10
11 A video of this talk was recorded at GopherCon in Denver.
12
13 .link https://www.youtube.com/watch?v=0ReKdcpNyQg Watch the talk on YouTube
14
15
16 *
17
18 .image gophercon-goevolution/GopherEvolution.svg
19
20
21 * Personal background
22
23 - Personal interest in programming languages.
24
25 - After grad school, programming in industry felt like a huge step backwards.
26
27 - Over the years, spent a lot of time thinking about programming languages.
28
29 - Good language design is *hard*.
30
31 - After 15 years of using C++, only two ways forward: *sell*out*or*bail*out*!
32
33 - Lucky to be on board with Rob and Ken.
34
35
36 * Starting points
37
38 - Clear goal in mind: We needed a better language for what we do at Google.
39
40 - Personal motivation: Wanted a clean, small, compiled language with modern features.
41
42 - Clear about what was wrong: Complexity, missing concurrency support, lack of scalability, insane build times.
43
44 - Good ideas about how to address issues.
45
46 - Unpolished thoughts about the rest.
47
48 - Three experienced people's insights on how not to do it.
49
50 - Lure: Designing a new language is easy.
51
52 What could possibly go wrong?
53
54
55 * Guiding principles
56
57 - Simplicity, safety, and readability are paramount.
58
59 - Striving for orthogonality in design.
60
61 - Minimal: One way to write a piece of code.
62
63 - It's about *expressing*algorithms*, not the type system.
64
65 - Collective unconscious history of programming languages.
66
67 Things of interest should be easy; even if that means not everything is possible.
68
69
70 * Literature on good language design is sparse
71
72 .image gophercon-goevolution/HoaresPLHints.JPG 400 600
73
74 - "Hints on Programming Language Design" (C.A.R. Hoare, 1973)
75 - "Everything you always wanted to know about programming languages but were afraid to ask" (C.A.R. Hoare, 1978)
76
77
78 * First design notes
79
80 Date: Sun, 23 Sep 2007 23:33:41 -0700
81 From: "Robert Griesemer" <gri@google.com>
82 To: "Rob 'Commander' Pike" <r@google.com>, ken@google.com
83 Subject: prog lang discussion
84 ...
85 *** General:
86 Starting point: C, fix some obvious flaws, remove crud, add a few missing features
87 - no includes, instead: import
88 - no macros (do we need something instead?)
89 - ideally only one file instead of a .h and .c file, module interface
90 should be extracted automatically
91 - statements: like in C, though should fix 'switch' statement
92 - expressions: like in C, though with caveats (do we need ',' expressions?)
93 - essentially strongly typed, but probably w/ support for runtime types
94 - want arrays with bounds checking on always (except perhaps in 'unsafe mode'-see section on GC)
95 - mechanism to hook up GC (I think that most code can live w/ GC, but for a true systems
96 programming language there should be mode w/ full control over memory allocation)
97 - support for interfaces (differentiate between concrete, or implementation types, and abstract,
98 or interface types)
99 - support for nested and anonymous functions/closures (don't pay if not used)
100 - a simple compiler should be able to generate decent code
101 - the various language mechanisms should result in predictable code
102 ...
103
104
105 * Looking back
106
107 Many Day One ideas made it into Go:
108
109 - Syntax: Leading keyword notation (const, var, type, etc), many cleanups.
110 - Expressions: 5 binary precedence levels maximum.
111 - Explicitly sized basic types, rune type, no implicit conversions.
112
113 - Packages and imports.
114 - Methods with explicit receiver parameter.
115 - Interfaces.
116 - Understanding that we would somehow add concurrency support based on Rob's previous work.
117
118 Many concepts were missing, and even more ideas didn't make it.
119
120 However, we were off to a good start. This was not at all obvious at the time!
121
122
123 * Most ideas come from previous ideas.
124 (Alan Kay)
125
126 Or, as some critics would say: There's nothing new in Go!
127
128
129 They are missing the point:
130
131 The task of the programming language designer *"*is*consolidation*not*innovation*"*.
132 (Hoare, 1973).
133
134
135 * The Algol family
136
137
138 * Algol60
139
140
141 (John Backus, John McCarthy, Alan Perlis, et al, 1958-1960)
142
143 => Block structure, nested and recursive functions and procedures, type declarations and static typing, "for" statement, "return" statement, semicolon separated statements, "begin"-"end" blocks, "call by name", etc.
144
145 "Here is a language [Algol60] so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors." (C.A.R. Hoare)
146
147 Coincidentally, a few years before:
148 - Backus Naur Normal Form (John Backus, Peter Naur, 1958)
149
150
151 * Algol successors
152
153 - *Pascal* (N. Wirth, ETH Zürich, 1968-1970)
154 => BEGIN/END for blocks, semicolons as separators, left-to-right declarations,
155 principled structured data types, notion of predeclared ("standard") functions, designed for teaching.
156
157 - *C* (Dennis Ritchie, Bell Labs, 1969-1973)
158 => Curly braces for blocks, semicolons as terminators, declarations mimic use,
159 duality between arrays and pointers, static typing but weak enforcement, designed to write Unix kernel.
160
161
162 * Pascal successors
163
164 - *Modula*, *Modula-2* (N. Wirth, 1978, 1980)
165 => Modules separate compilation and encapsulation, coroutines and monitors, support for low-level programming.
166
167 - *Oberon* (N. Wirth, 1986)
168 => Simplified modules, dynamic type extension and type tests, streamlined syntax.
169
170 Philosophy: "Make it as simple as possible, but not simpler." (A. Einstein)
171
172 - *Object*Oberon* (J. Templ, H.P. Moessenboeck, 1989)
173 => Experimental Oberon dialect with classes and methods.
174
175 - *Oberon-2* (J. Templ, H.P Moessenboeck, N. Wirth, 1991)
176 => Oberon with methods on records (== structs), replaces Object Oberon.
177
178
179 * Tree node lookup in Oberon-2
180
181
182 MODULE Trees;
183
184 IMPORT Texts, Oberon;
185
186 TYPE
187 Tree* = POINTER TO Node; (* star denotes export, not pointer! *)
188 Node* = RECORD
189 name-: POINTER TO ARRAY OF CHAR; (* minus denotes read-only export *)
190 left, right: Tree
191 END;
192
193 PROCEDURE (t: Tree) Lookup* (name: ARRAY OF CHAR): Tree;
194 VAR p: Tree;
195 BEGIN p := t;
196 WHILE (p # NIL) & (name # p.name^) DO
197 IF name < p.name^ THEN p := p.left ELSE p := p.right END
198 END;
199 RETURN p
200 END Lookup;
201
202 ...
203
204
205 * Analogous code in Go
206
207
208 package trees
209
210 import ( "fmt"; "runtime" )
211
212 type (
213 Tree *Node
214 Node struct {
215 name string
216 left, right Tree
217 }
218 )
219
220 func (t *Node) Lookup(name string) Tree {
221 var p Tree
222 p = t
223 for p != nil && name != p.name {
224 if name < p.name { p = p.left } else { p = p.right }
225 }
226 return p
227 }
228
229 ...
230
231
232 * Observations
233
234 - Syntax details are different but structure is the same.
235 => C tokens, Oberon structure.
236
237 - Same concepts (packages, imports, types, functions/methods, etc).
238 => Go concepts further distilled (e.g.; just one loop construct).
239
240 Go's heritage is at least as much Oberon as it is C!
241 (packages, imports, strict memory safety, garbage collection, dynamic type checks, etc.)
242
243
244 * Object orientation and generics
245
246 Around 1990: OO and type-system "craze" taking its toll on programming languages.
247 - C++, Java, others
248 - complex OO type systems
249 - complex generic type systems
250
251 Proliferation of dynamically typed interpreted languages:
252 - Erlang, Perl, Python, Lua, Javascript, Ruby, etc.
253
254 1990s, 2000s: Backlash.
255 - Complex OO code is modern analog to unstructured "spaghetti code" of 1970.
256 - Realization that large programs in dynamically typed languages become unmaintainable.
257 - Cluttered notation: “Public Static Void” (Rob Pike, OSCON 2010).
258
259
260 * Object orientation in Go: Interfaces
261
262 Inspiration: Smalltalk (Alan Kay, Dan Ingalls, Adele Goldberg, 1972-1980)
263 - Everything is an object.
264 - Any message can be sent to any object.
265
266 Want: Similar power in (mostly) statically typed language without the type-system fuss.
267 - Notion of interfaces for static typing.
268 - Usually objects carry type information => restricts object types to "classes".
269
270 *Crucial*insight*: Can attach methods to any type if interfaces carry type info rather than objects.
271
272 Methods and interfaces are the only additional mechanisms needed for object-oriented programming.
273
274
275 * Concurrency
276
277 - Good concurrency support was considered essential from day one.
278
279 - Rob Pike’s work on NewSqueak turned out to fit really well into Go.
280
281 Origins:
282
283 - “Newsqueak: A Language for Communicating with Mice”, Rob Pike, 1994.
284
285 - “Communicating Sequential Processes”, CACM, C.A.R. Hoare, 1978.
286
287
288 * Generics
289
290 - Single biggest language feature (what exactly is it?) absent in Go.
291
292 - Often missed by newcomers to Go.
293
294 - Type-system mechanism; unclear if essential language feature.
295
296 - Incredibly complex in both semantics and implementation.
297
298 - Significant trade-offs: Larger binary, slower binary, or larger source code.
299
300 - Not-orthogonal: Affects many other language features as well as how library is written.
301
302 - For now: Hold off and keep thinking about it.
303
304
305 * Putting it all together
306
307 Luxury to spend two years to hammer out basics (thanks, Google!).
308
309 Crucial: *Added*one*feature*at*a*time.*
310
311 Initially: Team of three very different people.
312 - Intensive discussions, emotional.
313 - Humbling experience.
314
315 Having multiple people illuminating each new feature from different angles
316 made language much stronger.
317
318 Later:
319 - Russ Cox's razor cutting through the crud, making it work well.
320 - Ian Lance Taylor providing a 2nd implementation (validation of design).
321 - go/types (now in 1.5!) provides a 3rd frontend (validation of compilers and spec).
322
323 Having 3 frontends proved tremendously useful.
324
325
326 * Evolving Go
327
328 Original design went through many (syntactic and semantic) transitions:
329
330 - Parallel library development ensured we didn't design "into the blue".
331
332 - gofmt (for language changes) and gofix (for API changes) for existing code.
333
334 Features that came in much later:
335
336 - Optional semicolons, optional types for composite literals, optional bounds in slice expressions, recover, etc.
337
338 - Semantic clarifications (maps, channel ops, etc.).
339
340 - Small backward-compatible adjustments still happening at very low rate.
341
342
343 * The future of Go
344
345
346 * What makes a programming language successful?
347
348 - Clear target
349
350 - Solid implementation: *language*, *libraries*, and *tools*!
351
352 - Market readiness
353
354 - Technological breakthrough
355
356 - Language features without competitors
357
358 - Rarely: Marketing
359
360
361 * How about Go?
362
363 - Clear target behind design
364 - Multi-paradigm (imperative, functional, object-oriented)
365 - Syntactically light-weight
366 - Language features without competition: goroutines, interfaces, defer
367 - Tools without competition: fast compiler, gofmt, go build
368 - Strong standard libraries
369 - Solid implementation
370 - Excellent documentation, online tools (playground, tour)
371 - But: No corporate marketing to speak of
372
373
374 * Will Go become mainstream?
375
376 - Need to cross the chasm from early adopters to early mainstream. Are we there yet?
377 - Go community must remain unified behind this goal.
378 - Don't make too many mistakes going forward.
379
380 It takes about 10 years for a programming language to become "established".
381
382
383 * Pitfalls
384
385 The language is frozen, but these are a form of "language design":
386
387 - +build tags and other specialized comments
388 - special interpretation of import paths and canonical import path comments
389 - internal packages
390 - vendoring descriptions
391
392 These mechanisms are not part of the language spec and thus may diverge
393 over time or have different semantics on different platforms.
394
395 Need to be watchful of this development.
396
397
398 * Closing thoughts
399
400 - In 1960, language experts from America and Europe teamed up to create Algol 60.
401 - In 1970, the Algol tree split into the C and the Pascal branch.
402 - ~40 years later, the two branches join again in Go.
403 - Let's see if Go can enjoy an equally long run as its predecessors!
404
View as plain text