Go Berkeley CS 294-101 Mar 18, 2015 Rob Pike Google - - PDF document

▶
go
SMART_READER_LITE
LIVE PREVIEW

Go Berkeley CS 294-101 Mar 18, 2015 Rob Pike Google - - PDF document

Oct 25, 2022 387 likes •894 views

Go 3/19/15, 7:18 AM Go Berkeley CS 294-101 Mar 18, 2015 Rob Pike Google http://127.0.0.1:3999/2015/res.slide#47 Page 1 of 49 Go 3/19/15, 7:18 AM What is Go? Go is: designed by Google open source concurrent garbage-collected compiled

slide-1
SLIDE 1

3/19/15, 7:18 AM Go Page 1 of 49 http://127.0.0.1:3999/2015/res.slide#47

Go

Berkeley CS 294-101 Mar 18, 2015 Rob Pike Google

slide-2
SLIDE 2

3/19/15, 7:18 AM Go Page 2 of 49 http://127.0.0.1:3999/2015/res.slide#47

What is Go?

Go is: designed by Google

  • pen source

concurrent garbage-collected compiled scalable simple fun boring (to some) golang.org (http://golang.org)

slide-3
SLIDE 3

3/19/15, 7:18 AM Go Page 3 of 49 http://127.0.0.1:3999/2015/res.slide#47

Adoption

slide-4
SLIDE 4

3/19/15, 7:18 AM Go Page 4 of 49 http://127.0.0.1:3999/2015/res.slide#47

Why?

Go is an answer to problems of scale at Google.

slide-5
SLIDE 5

3/19/15, 7:18 AM Go Page 5 of 49 http://127.0.0.1:3999/2015/res.slide#47

How?

By designing a language for software engineering.

slide-6
SLIDE 6

3/19/15, 7:18 AM Go Page 6 of 49 http://127.0.0.1:3999/2015/res.slide#47

What is important?

slide-7
SLIDE 7

3/19/15, 7:18 AM Go Page 7 of 49 http://127.0.0.1:3999/2015/res.slide#47

Properties

The "abilities": Readability Scalability Suitability Toolability

slide-8
SLIDE 8

3/19/15, 7:18 AM Go Page 8 of 49 http://127.0.0.1:3999/2015/res.slide#47

Readability

slide-9
SLIDE 9

3/19/15, 7:18 AM Go Page 9 of 49 http://127.0.0.1:3999/2015/res.slide#47

Overview

The readability of programs is immeasurably more important than their writeability. Hints on Programming Language Design

  • C. A. R. Hoare 1973
slide-10
SLIDE 10

3/19/15, 7:18 AM Go Page 10 of 49 http://127.0.0.1:3999/2015/res.slide#47

Readability

The purpose of notation: clearly express what we care about

slide-11
SLIDE 11

3/19/15, 7:18 AM Go Page 11 of 49 http://127.0.0.1:3999/2015/res.slide#47

Clarity: Plan for the future

program for someone else, years from now

  • ne-liners not the gold standard

a balance between clarity and redundancy

slide-12
SLIDE 12

3/19/15, 7:18 AM Go Page 12 of 49 http://127.0.0.1:3999/2015/res.slide#47

Too cold

scoped_ptr<goscript::GoScript> goscript(goscript::GoScript::NewGoScript(FLAGS_goscript, goscript::GoScript::kFIFO));

slide-13
SLIDE 13

3/19/15, 7:18 AM Go Page 13 of 49 http://127.0.0.1:3999/2015/res.slide#47

Too hot

(n: Int) => (2 to n) |> (r => r.foldLeft(r.toSet)((ps, x) => if (ps(x)) ps -- (x * x to n by x) else ps))

slide-14
SLIDE 14

3/19/15, 7:18 AM Go Page 14 of 49 http://127.0.0.1:3999/2015/res.slide#47

Just right

t := time.Now() switch { case t.Hour() < 12: return "morning" case t.Hour() < 18: return "afternoon" default: return "evening" }

slide-15
SLIDE 15

3/19/15, 7:18 AM Go Page 15 of 49 http://127.0.0.1:3999/2015/res.slide#47

Naming

How names work in a programming language is critical to readability.

slide-16
SLIDE 16

3/19/15, 7:18 AM Go Page 16 of 49 http://127.0.0.1:3999/2015/res.slide#47

Scope

Go has very simple scope hierarchy: universe package file (for imports only) function block

slide-17
SLIDE 17

3/19/15, 7:18 AM Go Page 17 of 49 http://127.0.0.1:3999/2015/res.slide#47

Locality of names

Nuances: upper case names for visibility: name vs. Name no implicit this in methods (receiver is explicit); always see

rcvr.Field

package qualifier always present for imported names (first component of) every name is always declared in current package

slide-18
SLIDE 18

3/19/15, 7:18 AM Go Page 18 of 49 http://127.0.0.1:3999/2015/res.slide#47

Locality scales

No surprises when importing: adding an exported name to my package cannot break your package! Names do not leak across boundaries. In C, C++, Java the name y could refer to anything. In Go, y (or even Y) is always defined within the package. In Go, x.Y is clear: find x locally, Y belongs to it.

slide-19
SLIDE 19

3/19/15, 7:18 AM Go Page 19 of 49 http://127.0.0.1:3999/2015/res.slide#47

Function and method lookup

Method lookup by name only, not type. A type cannot have two methods with the same name, ever. Easy to identify which function/method is referred to. Simple implementation, simpler program, fewer surprises. Given a method x.M, there's only ever one M associated with x.

slide-20
SLIDE 20

3/19/15, 7:18 AM Go Page 20 of 49 http://127.0.0.1:3999/2015/res.slide#47

Scalability

slide-21
SLIDE 21

3/19/15, 7:18 AM Go Page 21 of 49 http://127.0.0.1:3999/2015/res.slide#47

slide-22
SLIDE 22

3/19/15, 7:18 AM Go Page 22 of 49 http://127.0.0.1:3999/2015/res.slide#47

slide-23
SLIDE 23

3/19/15, 7:18 AM Go Page 23 of 49 http://127.0.0.1:3999/2015/res.slide#47

slide-24
SLIDE 24

3/19/15, 7:18 AM Go Page 24 of 49 http://127.0.0.1:3999/2015/res.slide#47

slide-25
SLIDE 25

3/19/15, 7:18 AM Go Page 25 of 49 http://127.0.0.1:3999/2015/res.slide#47

slide-26
SLIDE 26

3/19/15, 7:18 AM Go Page 26 of 49 http://127.0.0.1:3999/2015/res.slide#47

Scalability

Google means scale in multiple dimensions computers cores data code engineers Plus scaling has a big effect on: speed of compilation speed of testing

slide-27
SLIDE 27

3/19/15, 7:18 AM Go Page 27 of 49 http://127.0.0.1:3999/2015/res.slide#47

System scale

slide-28
SLIDE 28

3/19/15, 7:18 AM Go Page 28 of 49 http://127.0.0.1:3999/2015/res.slide#47

System scale

10⁶⁺ machines (design point) routine to be running on 1000 machines coordinating, interacting with other servers lots going on at once Solution: great support for concurrency

slide-29
SLIDE 29

3/19/15, 7:18 AM Go Page 29 of 49 http://127.0.0.1:3999/2015/res.slide#47

Engineering scale

slide-30
SLIDE 30

3/19/15, 7:18 AM Go Page 30 of 49 http://127.0.0.1:3999/2015/res.slide#47

Engineering scale

In 2011 at Google: single code tree 5000+ developers across 40+ offices 20+ changes per minute 50% of source files change every month 50 million test cases executed per day Solution: engineer language for large code bases

slide-31
SLIDE 31

3/19/15, 7:18 AM Go Page 31 of 49 http://127.0.0.1:3999/2015/res.slide#47

Software scale

slide-32
SLIDE 32

3/19/15, 7:18 AM Go Page 32 of 49 http://127.0.0.1:3999/2015/res.slide#47

Dependencies in C++

Explosive, exponential, almost non-computable. In 2007, instrumented building a large Google web-serving binary: 2000 files 4.2 megabytes 8 gigabytes delivered to compiler 2000 bytes sent to compiler for every C++ source byte it's real work too: <string> for example hours to build

slide-33
SLIDE 33

3/19/15, 7:18 AM Go Page 33 of 49 http://127.0.0.1:3999/2015/res.slide#47

Dependencies in Go

Linguistically defined. Efficient. Computable.

slide-34
SLIDE 34

3/19/15, 7:18 AM Go Page 34 of 49 http://127.0.0.1:3999/2015/res.slide#47

Hoisting dependencies

Consider:

A imports B imports C but A does not directly import C.

The object code for B includes all the information about C needed to import B. Therefore in A the line

import "B"

does not require the compiler to read C when compiling A. Also, the object files are designed so the "export" information comes first; compiler doing import does not need to read whole file. Exponentially less data read than with #include files. With Go in Google, about 40X fanout (recall C++ was 2000x) Plus in C++ it's general code that must be parsed; in Go it's just export data.

slide-35
SLIDE 35

3/19/15, 7:18 AM Go Page 35 of 49 http://127.0.0.1:3999/2015/res.slide#47

Scalability requires readability

For code to grow safely as time passes and staff changes: it must be readable it must be clear it must be adaptable it must be local The themes resonate.

slide-36
SLIDE 36

3/19/15, 7:18 AM Go Page 36 of 49 http://127.0.0.1:3999/2015/res.slide#47

Suitability

slide-37
SLIDE 37

3/19/15, 7:18 AM Go Page 37 of 49 http://127.0.0.1:3999/2015/res.slide#47

Suitability

Can the language do the job? Language is notation for a problem; not all languages are good for all problems. Go was designed for Google to help solve Google's problems.

slide-38
SLIDE 38

3/19/15, 7:18 AM Go Page 38 of 49 http://127.0.0.1:3999/2015/res.slide#47

Concurrency is vital

Linguistic support for concurrent execution makes programming in the Google environment easier, safer, and more productive. A key reason for Go's existence.

slide-39
SLIDE 39

3/19/15, 7:18 AM Go Page 39 of 49 http://127.0.0.1:3999/2015/res.slide#47

Go in production

Several big services are written in Go:

golang.org dl.google.com vitess, part of youtube.com

... Adoption finds issues; they are resolved; adoption easier next time.

slide-40
SLIDE 40

3/19/15, 7:18 AM Go Page 40 of 49 http://127.0.0.1:3999/2015/res.slide#47

SPDY

SPDY proxy for Chrome on mobile devices

slide-41
SLIDE 41

3/19/15, 7:18 AM Go Page 41 of 49 http://127.0.0.1:3999/2015/res.slide#47

Toolability

slide-42
SLIDE 42

3/19/15, 7:18 AM Go Page 42 of 49 http://127.0.0.1:3999/2015/res.slide#47

Toolability

Software engineering requires tools. Go's syntax, package design, naming, etc. make tools easy to write. Library includes lexer, parser and type checker.

slide-43
SLIDE 43

3/19/15, 7:18 AM Go Page 43 of 49 http://127.0.0.1:3999/2015/res.slide#47

Gofmt

Always intended to do automatic code formatting. Eliminates an entire class of argument. Runs as a "presubmit" to the code repositories. Training: The community has always seen gofmt output. Sharing: Uniformity of presentation simplifies sharing. Scaling: Less time spent on formatting, more on content. Often cited as one of Go's best features.

slide-44
SLIDE 44

3/19/15, 7:18 AM Go Page 44 of 49 http://127.0.0.1:3999/2015/res.slide#47

Gofmt and other tools

Surprise: The existence of gofmt enabled semantic tools: Can rewrite the tree; gofmt will clean up output. Examples:

gofmt -r 'a[b:len(a)] -> a[b:]' gofix

And good front-end libraries enable ancillary tools:

godoc go get, go build, go vet, etc. api

slide-45
SLIDE 45

3/19/15, 7:18 AM Go Page 45 of 49 http://127.0.0.1:3999/2015/res.slide#47

Gofix

The gofix tool allowed us to make sweeping changes to APIs and language features leading up to the release of Go 1. changed syntax for deleting from a map new time API many more Also allows us to update code even if the old code still works. More recent example: Changed Go's protocol buffer implementation to use getter functions; used gofix to update all google3 Go code.

slide-46
SLIDE 46

3/19/15, 7:18 AM Go Page 46 of 49 http://127.0.0.1:3999/2015/res.slide#47

Conclusion

Clarity is key. Design for readability, not writeability. Readability creates clarity, improving: productivity scale tooling These effects multiply.

slide-47
SLIDE 47

3/19/15, 7:18 AM Go Page 47 of 49 http://127.0.0.1:3999/2015/res.slide#47

Questions?

Links: golang.org (http://golang.org) talks.golang.org/2012/splash.article (http://talks.golang.org/2012/splash.article)

slide-48
SLIDE 48

3/19/15, 7:18 AM Go Page 48 of 49 http://127.0.0.1:3999/2015/res.slide#47

Thank you

Berkeley CS 294-101 Mar 18, 2015 Rob Pike Google r@golang.org (mailto:r@golang.org) http://golang.org/ (http://golang.org/)

slide-49
SLIDE 49

3/19/15, 7:18 AM Go Page 49 of 49 http://127.0.0.1:3999/2015/res.slide#47