Introduction In part I of this post, we learned about the error interface and how the standard library provides support for creating error interface values via the errors package. We also learned how to work with error interface values and use them to identify when an error has occured. Finally, we saw how some packages in the standard library export error interface variables to help us identify specific errors. Knowing when to create and use custom error types in Go can sometimes be confusing.

Introduction It is idiomatic in Go to use the error interface type as the return type for any error that is going to be returned from a function or method. This interface is used by all the functions and methods in the standard library that return errors. For example, here is the declaration for the Get method from the http package: Listing 1.1 http://golang.org/pkg/net/http/#Client.Get func (c *Client) Get(url string) (resp *Response, err error) Listing 1.

Introduction I was thinking about how the compiler looks to protect the code we write when it can. Invalid memory access checks are one type of safety check the compiler adds to our code. We might think that this "extra code" is hurting our performance and maybe over billions of iterative operations it is. However, these checks can prevent our code from causing damage to the systems we are running on.

If you have not heard about the ALS Ice Bucket Challenge I would be surprised. It’s everywhere nowadays, being done by celebrities alike. After being challenged by my children there was only one person, or should I say Gopher, I knew I needed to nominate. The Gopher took to the challenge and here it is: I would like to thank my daughter for spending time today filming and editing the video.

Introduction Dave Cheney published a post called Ice Cream Makers and Data Races. The post showed an example of an interesting data race that can occur when using an interface typed variable to make a method call. If you have not read the post yet please do. Once you read the post you will discover that the problem lies with the fact that an interface value is implemented internally using a two word header and that the Go memory model states only writes to a single word are atomic.

Introduction If you are building any kind of application for a consumer based product, it is common to have large amounts of application data being generated about your users. Running reports is a traditional use of this data, but what if you could make this data actionable? What if you could adapt the user experience by aggregating and testing this data against rules that could dictate actions or special messaging?

Introduction Closures in Go are a very powerful construct but they can also be the cause of bugs if you don’t understand how they work. In this post I am going to pull a small piece of code from Chapter 2 from the Go In Action book that discusses a pitfall you can run into when using closures. The full code example can be found in the Github repository for the book.

Introduction My business partner Ed asked me what would happen if a struct and an embedded field both implemented the same interface. We asked ourselves two questions: Would the compiler throw an error because we now had two implementations of the interface? If the compiler accepted the type declaration, how does the compiler determine which implementation to use for interface calls? We hacked out some code to answer the questions and then I dug into the specification.

Introduction One of the more unique features of Go is how the language implements constants. The rules for constants in the language specification are unique to Go. They provide the flexibility Go needs at the compiler level to make the code we write readable and intuitive while still maintaining a type safe language. This post will attempt to build a foundation for what numeric constants are, how they behave in their simplest form and how best to talk about them.

Introduction One of the first things I learned about in Go was using an uppercase or lowercase letter as the first letter when naming a type, variable or function. It was explained that when the first letter was capitalized, the identifier was public to any piece of code that wanted to use it. When the first letter was lowercase, the identifier was private and could only be accessed within the package it was declared.