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
Prelude These are good posts to read first to better understand the material presented in this post:
Index of the four part series:
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
The idea of value and pointer semantics are everywhere in the Go programming language. As stated before in those earlier posts, semantic consistency is critical for integrity and readability.
Continue reading
Prelude This is the final post in a four part series discussing the mechanics and design behind pointers, stacks, heaps, escape analysis and value/pointer semantics in Go. This post focuses on data and the design philosophies of applying value/pointer semantics in your code.
Index of the four part series:
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
Continue reading
