Table of Contents - Version 0.4
Table of Contents - Version 0.4 1
Chapter 1 - Introduction 7
1.1 Reading Code 7
1.2 Legacy Software 8
1.3 Mental Models 8
1.4 Productivity vs Performance 9
1.5 Correctness vs Performance 10
1.6 Rules 11
1.7 Senior vs Junior Developers 11
1.8 Code Reviews 12
1.9 Integrity 12
1.10 Readability 13
1.11 Simplicity 14
1.12 Performance 15
1.13 Micro-Optimizations 16
1.14 Data-Oriented Design 16
1.15 Interface And Composition Design 17
1.16 Concurrent Software Design 18
1.17 Channel Design 20
Chapter 2 - Language Mechanics 22
2.1 Built-in Types 22
2.2 Word Size 22
2.3 Zero Value Concept 22
2.4 Declare and Initialize 23
2.5 Conversion vs Casting 24
2.6 Struct and Construction Mechanics 24
2.7 Padding and Alignment 25
2.8 Assigning Values 27
2.9 Pointers 28
2.10 Pass By Value 29
2.11 Escape Analysis 31
2.12 Stack Growth 33
2.13 Garbage Collection 34
2.14 Constants 34
2.15 IOTA 36
Chapter 3 - Data Structures 38
3.1 CPU Caches 38
3.2 Translation Lookaside Buffer (TLB) 41
3.3 Declaring and Initializing Values 41
3.4 String Assignments 42
3.5 Iterating Over Collections 43
3.6 Value Semantic Iteration 43
3.7 Pointer Semantic Iteration 44
3.8 Data Semantic Guideline For Built-In Types 45
3.9 Different Type Arrays 45
3.10 Contiguous Memory Construction 46
3.11 Constructing Slices 46
3.12 Slice Length vs Capacity 47
3.13 Data Semantic Guideline For Slices 48
3.14 Contiguous Memory Layout 48
3.15 Appending With Slices 49
3.16 Slicing Slices 50
3.17 Mutations To The Backing Array 52
3.18 Copying Slices Manually 56
3.19 Slices Use Pointer Semantic Mutation 57
3.20 Linear Traversal Efficiency 58
3.21 UTF-8 59
3.22 Declaring And Constructing Maps 61
3.23 Lookups and Deleting Map Keys 62
3.24 Key Map Restrictions 63
Chapter 4 - Decoupling 64
4.1 Methods 64
4.2 Method Calls 64
4.3 Data Semantic Guideline For Internal Types 65
4.4 Data Semantic Guideline For Struct Types 66
4.5 Methods Are Just Functions 69
4.6 Know The Behavior of the Code 70
4.7 Escape Analysis Flaw 73
4.8 Interfaces 73
4.9 Interfaces Are Valueless 74
4.10 Implementing Interfaces 74
4.11 Polymorphism 75
4.12 Interfaces via Pointer or Value Semantics 77
4.13 Method Set Rules 78
4.14 Slice of Interface 80
4.15 Embedding 81
4.16 Exporting 84
Chapter 5 - Software Design 87
5.1 Grouping Different Types of Data 87
5.2 Don’t Design With Interfaces 90
5.3 Composition 91
5.4 Decoupling With Interfaces 94
5.5 Interface Composition 97
5.6 Readability Review 99
5.7 Implicit Interface Conversions 100
5.8 Type assertions 102
5.9 Interface Pollution 103
5.10 Interface Ownership 105
5.11 Error Handling 106
5.12 Always Use The Error Interface 112
5.13 Handling Errors 113
Chapter 6 - Concurrency 117
6.1 Scheduler Semantics 117
6.2 Concurrency Basics 119
6.3 Preemptive Scheduler 123
6.4 Data Races 125
6.5 Data Race Example 125
6.6 Race Detection 128
6.7 Atomics 130
6.8 Mutexes 131
6.9 Read/Write Mutexes 133
6.10 Channel Semantics 135
6.11 Channel Patterns 137
6.11.1 Wait For Result 137
6.11.2 Fan Out/In 138
6.11.3 Wait For Task 139
6.11.4 Pooling 140
6.11.5 Drop 141
6.11.6 Cancellation 143
6.11.7 Fan Out/In Semaphore 144
6.11.8 Bounded Work Pooling 145
6.11.9 Retry Timeout 146
6.11.10 Channel Cancellation 147
Chapter 7 - Generics 149
7.1 Basic Syntax 149
7.2 Underlying Types 150
7.3 Struct Types 152
Chapter 8 - Conclusion 155
April 2021 - Version 0.4 : Added illustrations, listing and figure numbers
March 2021 - Version 0.3 : Verdana Font, 1.25 line spacing, chapter numbers
March 2021 - Version 0.2 : Initial generics, more channel patterns, design philosophy
March 2021 - Version 0.1 : Initial draft release
* More Generic Code
* Consider removing blog links for content
* Add chapter intro content
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
Back in August 2019, Hoanh An started a project in Github called the Ultimate Go Study Guide. It was a collection of notes he took after taking the Ultimate Go class. Surprisingly, it got a lot of attention from the community and eventually had more stars and activity than the actual repo for the class. This shows the power of open sourcing material.
Then Hoanh decided to publish a book from his notes and repo. When I saw what Hoanh had written and the excitement his followers had, I reached out to him. We decided I would review and refactor his original work and we would publish a book together. This is that book and it represents the notes I would like any student to make while taking the class.
If you have taken the class before, these notes will sound and feel familiar. I think it’s a great reference to all the things I say in class. If you’ve never taken the class before, I think the notes are still a good source of learning Go. Maybe it will give you the push you need to take the class.
Now in April 2021, it’s taken us six months to get the initial release of the book in your hands. The plan is to continue to add more and more content to the book over time. Things like modules, generics, and packages from the standard library are slated for future releases.
I want to thank everyone in the Go community for their support and help over the years in creating this material. When I started in March 2013, I didn’t know anything about Go and had no idea where Go would take me. Learning is a journey that takes time and effort. If this material can help jump start your learning about Go, then the time and effort was worth every minute.
-- Bill Kennedy
Chapter 1 - Introduction
It’s important that you prepare your mind for the material you are about to read. The introduction will provide some thoughts and ideas, using quotes to stimulate your initial understanding of the language.
Somewhere Along The Line
* We became impressed with programs that contain large amounts of code.
* We strived to create large abstractions in our code base.
* We forgot that the hardware is the platform.
* We lost the understanding that every decision comes with a cost.
These Days Are Gone
* We can throw more hardware at the problem.
* We can throw more developers at the problem.
Open Your Mind
* Technology changes quickly but people's minds change slowly.
* Easy to adopt new technology but hard to adopt new ways of thinking.
Interesting Questions - What do they mean to you?
* Is it a good program?
* Is it an efficient program?
* Is it correct?
* Was it done on time?
* What did it cost?
* Be a champion for quality, efficiency and simplicity.
* Have a point of view.
* Value introspection and self-review.
1.1 Reading Code
Go is about being a language that focuses on code being readable.
“If most computer people lack understanding and knowledge, then what they will select will also be lacking.” - Alan Kay
"The software business is one of the few places we teach people to write before we teach them to read." - Tom Love (inventor of Objective C)
"Code is read many more times than it is written." - Dave Cheney
"Programming is, among other things, a kind of writing. One way to learn writing is to write, but in all other forms of writing, one also reads. We read examples both good and bad to facilitate learning. But how many programmers learn to write programs by reading programs?" - Gerald M. Weinberg
"Skill develops when we produce, not consume." - Katrina Owen
1.2 Legacy Software
Do you care about the legacy you are leaving behind?
"There are two kinds of software projects: those that fail, and those that turn into legacy horrors." - Peter Weinberger (inventor of AWK)
"Legacy software is an unappreciated but serious problem. Legacy code may be the downfall of our civilization." - Chuck Moore (inventor of Forth)
"Few programmers of any experience would contradict the assertion that most programs are modified in their lifetime. Why then do we rarely find a program that contains any evidence of having been written with an eye to subsequent modification." - Gerald M. Weinberg
"We think awful code is written by awful devs. But in reality, it's written by reasonable devs in awful circumstances." - Sarah Mei
"There are many reasons why programs are built the way they are, although we may fail to recognize the multiplicity of reasons because we usually look at code from the outside rather than by reading it. When we do read c