Text file
talks/2012/go1.slide
1 The Path to Go 1
2
3 Rob Pike
4 Google
5 https://go.dev
6
7 Andrew Gerrand
8 Google
9 http://andrewgerrand.com
10 @go_nuts
11 https://go.dev
12
13
14 * Introduction
15
16 Go is a concurrent open source programming language developed at Google.
17
18 Combines native compilation and static types with a lightweight dynamic feel.
19
20 Fast, fun, and productive.
21
22
23 * What is Go?
24
25 Features:
26
27 - Native code generation (compiled)
28 - Statically typed
29 - Composition via interfaces
30 - Memory safe
31 - Garbage collected
32 - Native concurrency support
33 - Excellent standard library
34 - Great tools
35
36
37 * History
38
39
40 * History
41
42 Began as a Google 20% project in late 2007.
43
44 Released as an open source project in November 2009.
45
46 Go 1 released in March 2012.
47
48
49 * The Go project
50
51 Planned from the start as an open source project.
52
53 Publicly released under a BSD license.
54
55 To date: 28 committers from Google and elsewhere.
56
57 More than 200 other people have contributed to the project.
58
59 9735 changes committed since release.
60
61
62 * Development process
63
64 Mercurial version control system with plugin for code review.
65
66 No branches; linear history.
67
68 Code review central to the project. All changes reviewed on golang-dev list using Rietveld (codereview.appspot.com).
69
70 Custom continuous build system tests across all supported platforms.
71
72 Contributions accepted on a "Discuss first, code later" basis.
73
74
75 * Contributions over time
76
77 The project moves fast:
78
79 .image go1/changes.png
80
81 Windows, FreeBSD, OpenBSD, NetBSD, and Plan 9 ports are community-driven.
82
83
84 * Managing the project
85
86 * Development cycle
87
88 Changes are made continuously.
89
90 Things break. Things get fixed.
91 Some days are better than others.
92
93 Continuous builders help, but don't reveal all issues.
94
95 We needed to provide some stability for our users.
96
97
98 * Weekly snapshots
99
100 Attempt to keep everyone in sync.
101
102 - Apply a Mercurial tag to a specific, stable revision.
103 - Announce to user mailing list with detailed changelog.
104
105 Great for early adopters and core developers.
106
107
108 * Problems with weeklies
109
110 Contributors work at tip; users sync to weeklies.
111
112 Burden on users:
113
114 - annoying to update weekly,
115 - painful to update less often.
116
117 Version skew results because users are at different weeklies.
118
119 Skew fragments the community and slows adoption.
120
121
122 * Formal release process
123
124 March 2011: introduced releases every 1-2 months.
125
126 - Pick the most stable of the past few snapshots and tag it.
127 - Announce with abridged "must read" release notes.
128
129 Keeps the community more in sync. Reduces churn.
130
131 Popular with users.
132
133
134 * Problem with releases
135
136 Easy to make a few small changes once a week...
137
138 \...but hard to make many small changes once a month.
139
140 Skew still prevalent: adventurers and core devs still use weeklies (or tip!).
141
142
143 * Introducing Gofix
144
145 A tool to mechanically update code to accommodate language and library changes.
146
147 gofix prog.go
148
149 Announced in May 2011.
150 Gofix automates updates for backward-incompatible changes.
151 Eases the burden of staying current.
152
153 Release notes now mostly say "run gofix."
154
155 Not a sed script. Works on the AST.
156
157
158 * Gofix
159
160 Gofix enables sweeping changes without fear of breaking the code base.
161
162 Gofix gave us the freedom to make widespread changes that would have been too daunting otherwise.
163
164 Can even update foreign code:
165
166 "Yesterday I gofixed some third-party packages without even reading their code and without waiting for the authors to update them." - Dmitry Chestnykh
167
168
169 * Versioning issues persist
170
171 Gofix is no panacea.
172
173 As the root of the dependency graph, a programming language can suffer acutely from version skew.
174
175 The fundamental issue remains:
176 Code you write today may not compile tomorrow.
177
178 Some companies unwilling to bet on Go as they saw it as unstable.
179
180
181 * A need for stability
182
183 Gofix makes changes very easy, and also makes it easy to experiment.
184 But it can't do everything.
185
186 Priorities: If change is easy, what change is important?
187
188 Wanted to make major changes to the language and libraries but, even with gofix, some things are too disruptive without proper planning.
189
190 Decision: design and implement a stable version of Go, its libraries, and its tools.
191
192
193 * Go 1
194
195 * What is Go 1?
196
197 A specification of the language and libraries that will be supported for years.
198
199 Available as downloadable binary packages.
200
201 An opportunity to:
202
203 - fix minor language irritations,
204 - fix inconsistencies in the standard library,
205 - focus on bug fixing and cleaning up TODOs,
206 - design and build a strong build tool set (get rid of make),
207 - bring Windows support up to par.
208
209 Polish and refine, not redesign.
210
211
212 * Planning Go 1
213
214 Wrote a detailed proposal document.
215
216 Implemented (but not committed) many of the proposed changes.
217
218 Core team met for a week to discuss and refine the document (October 2011).
219
220 Presented the document to the community for discussion.
221
222 Community feedback essential in refining the proposal.
223
224
225 * Preparing Go 1
226
227
228 Create many new issues on the tracker.
229
230 Categorize new and existing issues as either "Go 1" or "after Go 1".
231
232 Contributors nominate themselves to address specific issues.
233
234 Stop developing new features; prioritize stability.
235
236
237 * Rolling it out
238
239 Daily number of lines changed in the months leading up to Go 1:
240
241 .image go1/go1lines.png
242
243
244 * Gofix and Go 1
245
246 The largest Go 1 edits were performed by gofix.
247
248 Gofix made it easy to try out a change and refine it incrementally.
249
250 Some significant changes were tried and abandoned.
251
252
253 * Gofix work flow
254
255 Scripted work flow allowed us to avoid branches and merging nightmares.
256 #Total automation of edits makes it easy to do large changes without branching.
257
258 Process:
259
260 while !satisfied {
261 in tree 1:
262 refine gofix module in tree 1, build binary
263 in tree 2:
264 revert to tip (note: tip)
265 apply gofix binary from tree 2
266 build and test
267 }
268 commit tree 1
269 commit tree 2
270
271 Even as other changes are happening, this leads to no branching or skew.
272
273 * Sample change
274
275 .image go1/errordiff1.png
276 .image go1/errordiff2.png
277
278 * Go 1 release process
279
280 Releases paused from r60 (August 2011).
281 Weeklies continued as normal.
282
283 Issued release candidates in the weeks leading up to launch.
284
285 Release candidates included binary distributions for the supported operating systems (FreeBSD, Linux, Mac OS X, and Windows).
286
287
288 * What is in Go 1?
289
290 * Go 1
291
292 Specification of the language.
293
294 Specification of the libraries.
295
296 Promise of long term compatibility.
297
298 Windows as a first class citizen.
299
300 New tool chain centered around the `go` tool.
301
302 "Phase change" in the way the project runs.
303
304
305 * Language changes
306
307 A new `rune` type to represent a Unicode code point.
308 (Important step in making `int` either 32 or 64 bits; currently just 32.)
309
310 A new built-in `error` type to replace `os.Error`.
311 This affected almost all Go code in existence.
312
313 Equality defined on structs.
314
315 Cleaned up some clumsy operations.
316
317
318 * API changes
319
320 A re-designed `time` package with a clean, simple interface.
321
322 Regularization of `strconv`, breaking away from the old C-style API.
323
324 Widespread package re-organization. Put things in more appropriate places.
325
326 Dozens of lesser changes.
327
328
329 * Time
330
331 Old time package was based on the Unix epoch. Limited range, poor features,
332 no type safety (just integer nanoseconds).
333
334 Substantial redesign creates separate Time and Duration types.
335 Time can represent huge range of times with nanosecond precision.
336
337 Duration specifies intervals. Example:
338
339 time.Sleep(2) // Old API, unsafe: How long is this?
340 time.Sleep(2*time.Second) // New API: type-safe, readable.
341
342 fmt.Println(time.Now().Add(1e6*time.Hour))
343
344 Also a new flag type!
345
346 $ command -timeout 1m30s
347
348 * Re-organization
349
350 Rearranged the organically constructed tree to group related things together.
351 Examples:
352
353 Old New
354
355 "asn1" "encoding/asn1"
356 "csv" "encoding/csv"
357 "gob" "encoding/gob"
358 "json" "encoding/json"
359 "xml" "encoding/xml"
360
361 "unicode" "unicode"
362 "utf8" "unicode/utf8"
363 "utf16" "unicode/utf16"
364
365 All updated by gofix, of course.
366
367 * Demoting immature packages and commands
368
369 Parts of the tree deemed unready should not be part of Go 1.
370
371 Working but immature packages were moved to sub-repositories of the main Go repository. (They remain installable.)
372
373 Unfinished and old packages and tools were left out.
374
375
376 * How to build
377
378 Before Go 1, Go programs were built with make, but Makefiles are annoying to write and, for Go, redundant.
379
380 From the beginning, a goal of Go was good dependency management.
381
382 By design, Go source code contains all the information necessary to build.
383
384 Go 1 includes a new "go tool" that eliminates the need for make.
385
386 Given a Go tree (including remote dependencies), can build and install directly:
387
388 $ go build file.go
389
390 * The go tool
391
392 A complete build, test, and install tool for Go programs.
393
394 Some realistic examples:
395
396 $ go run hello.go # Compile-and-go. (Ha!).
397 $ go build package # Build everything in directory (and deps).
398 $ go install # Install everything in dir and (and deps).
399 $ go test archive/zip # Compile and run unit tests for package.
400
401 The go tool also wraps `gofmt`, `gofix`, etc.:
402
403 $ go fmt # Run gofmt on package in current dir.
404 $ go fix # Run gofix on package in current dir.
405
406 * The go tool and remote repositories
407
408 The go tool automates installation of remote packages.
409
410 Packages are addressed by import strings.
411 Import strings are just source repository URLs.
412 Go tool downloads and installs all dependencies, transitively.
413
414 $ go get code.google.com/p/myrepo/mypackage
415
416 Installs my package, plus any remote dependencies it may have.
417 And to use the package in Go source:
418
419 import "code.google.com/p/myrepo/mypackage"
420
421 The tool can even run gofix as it installs:
422
423 $ go get -fix code.google.com/p/myrepo/mypackage
424
425
426 * Documentation
427
428 Complete reworking:
429
430 - updated,
431 - unified,
432 - added new documents,
433 - added new (executable) examples,
434 - redesigned web site.
435
436
437 * API compatibility tool
438
439 Scans the entire standard library and checks it against a master list (`go1.txt`).
440
441 Helps guarantee compatibility as development continues.
442
443 Part of our build process in the lead up to Go 1 (and continues today).
444
445
446 * Today and tomorrow
447
448 * What are we working on?
449
450 The goal for Go 1 was a stable, productive environment.
451
452 Now that Go 1 is out, we are shifting our focus to using Go more than just developing it.
453
454 Only through using Go extensively can we learn what might be needed in a future version, say Go 2.
455
456 * There is still active development
457
458 The design is locked down but work continues.
459
460 Stability: bug fixes.
461
462 Efficiency:
463
464 - code generation,
465 - garbage collection,
466 - scheduling,
467 - hot spots in standard libraries.
468
469 Portability: NetBSD, OpenBSD, and Plan 9 ports in progress.
470
471 New libraries: HTML parsing and Unicode collation packages, for example.
472
473 * Releases after Go 1
474
475 Two minor point releases (`go1.0.1` and `go1.0.2`) have been issued to fix bugs.
476
477 The next major point release (`go1.1`) is planned for the end of 2012.
478 It will include:
479
480 - code generation improvements to the `gc` compiler,
481 - performance and accuracy improvements to the garbage collector,
482 - (possibly) an improved scheduler,
483 - a slew of bug fixes.
484
485 Go 2 is likely years away.
486
487
488 * Learn more
489
490 The Go web site has a huge amount of documentation:
491
492 .link / go.dev
493
494 Learn Go from a web browser:
495
496 .link /tour/ go.dev/tour
497
498 "Meet the Go team" panel from Google I/O 2012:
499
500 .link /s/meet-the-go-team go.dev/s/meet-the-go-team
501
502 Google Code project:
503
504 .link http://code.google.com/p/go
505
506
View as plain text