Introduction In the first part of this scheduling series, I explained aspects of the operating-system scheduler that I believe are important in understanding and appreciating the semantics of the Go scheduler. In this post, I will explain at a semantic level how the Go scheduler works and focus on the high-level behaviors. The Go scheduler is a complex system and the little mechanical details are not important. What’s important is having a good model for how things work and behave.
Continue reading

In the months leading up to GopherCon, my wife Jamilet and I had come up with the idea of creating a “small” browser-based game for the convention using the racing theme. Neither of us had ever worked on a game before and we had no idea what was involved. However, we knew we wanted to design and build something special for the awesome Gopher community. The original idea was to create a game where Gophers raced each other around a track.
Continue reading

Introduction The design and behavior of the Go scheduler allows your multithreaded Go programs to be more efficient and performant. This is thanks to the mechanical sympathies the Go scheduler has for the operating system (OS) scheduler. However, if the design and behavior of your multithreaded Go software is not mechanically sympathetic with how the schedulers work, none of this will matter. It’s important to have a general and representative understanding of how both the OS and Go schedulers work to design your multithreaded software correctly.
Continue reading

Introduction I teach a class called Ultimate Go. The class is three days long and teaches you the history, mechanics and semantics of the Go programming language. The idea is to teach you how to read code to the level that you can understand the behavior and impact your program is having on the machine. This helps you make better and more consistent engineering decisions. At the same time, the class is very focused on teaching you how to optimize for correctness so the code you are writing is readable as a first priority.
Continue reading

Introduction One day I was talking to Damian Gryski in Slack about some performance improvements he made to his go-metro package. When I first looked at the changes I was completely confused how this could have any effect on the performance of the code. I felt the code was more readable, but more performant? I didn’t see it. Then Damian started to talk to me about a compiler optimization called Bounds Check Elimination or BCE.
Continue reading

Introduction I’ve been seeing a lot of question about interfaces lately on Slack. Most of the time the answers are technical and focus on implementation details. Implementation is important to help with debugging, but implementation doesn’t help with design. When it comes to designing code with interfaces, behavior has to be the main focus. In this post, I hope to provide a different way to think about interfaces and how to design code with them.
Continue reading

Introduction I was guided for many years to write functions that are generalized and to create layers upon layers of abstraction so things don’t break as business requirements change. That the cost of breaking a function signature, for example, is expensive and something that should be avoided. Therefore, write functions that take more generic parameters or hide things in a receiver or context to be less prone to breakage.
Continue reading

Prelude It will be helpful to read this four-part series first on escape analysis and data semantics. Details on how to read an escape analysis report and pprof output have been outlined here. https://www.ardanlabs.com/blog/2017/05/language-mechanics-on-stacks-and-pointers.html Introduction Even after working with Go for 4 years, I am continually amazed by the language. Thanks to the static code analysis the compiler performs, the compiler can apply interesting optimizations to the code it produces.
Continue reading

Introduction When I started to work with Go’s channels for the first time, I made the mistake of thinking about channels as a data structure. I saw channels as a queue that provided automatic synchronized access between goroutines. This structural understanding caused me to write a lot of bad and complicated concurrent code. I learned over time that it’s best to forget about how channels are structured and focus on how they behave.
Continue reading

Prelude If you want to put this post in some better context, I suggest reading the following series of posts, which lay out some other fundamental and relevant design principles: 1) Language Mechanics On Stacks And Pointers 2) Language Mechanics On Escape Analysis 3) Language Mechanics On Memory Profiling 4) Design Philosophy On Data And Semantics In particular, the idea of value and pointer semantics is everywhere in the Go programming language.
Continue reading