Go's infamous error handling has caught quite the attention from outsiders to the programming language, often touted as one of the language's most questionable design decisions. If you look into any project on Github written in Go, it's almost a guarantee you'll see the lines more frequently than anything else in the codebase:

if err != nil {
    return err
}

Although it may seem redundant and unnecessary for those new to the language, the reason errors in Go are treated as first-class citizens (values) has a deeply-rooted history in programming language theory and the main goal of Go as a language itself. Numerous efforts have been made to change or improve how Go deals with errors, but so far, one proposal is winning above all others:

Leave if err != nil alone!

Many folks that know me personally know how much time I dedicate each day towards becoming proficient at speaking, reading, and writing Cantonese, making it my favorite language and one I have developed a major personal goal of becoming proficient in. Cantonese, known as jyut6 jyuh5 (粵話), is one of the major languages of China and the Chinese diaspora abroad, spoken by around 100 million native speakers [1] today along the pearl river delta in the southern Chinese province of Gwongdung (廣東), Macao, Hong Kong, and Southeast Asia as a lingua franca. It is a language rich with tradition and a history spanning over 2000 years, retaining significant elements of Classical Chinese.

for field, ref := range s.sharedFieldReferences {
    ref.AddRef()
    dst.sharedFieldReferences[field] = ref
}

One of cons of Go as a modern programming language is the lack of native options for making certain data structures immutable. That is, we often have to make key software design decisions in our application just to ensure certain data is immutable throughout the code's runtime, and it may not look pretty. At my company, Prysmatic Labs, we often encounter the problem where we need to maintain certain large data structures in-memory for performance reasons and we also need to perform one-off, local computations on such data. That is, we have very intensive read-heavy workloads in our application where we do not want to compromise data safety.

func (s *ServiceRegistry) RegisterService(
  service Service,
) error {
	kind := reflect.TypeOf(service)
	if _, exists := s.services[kind]; exists {
		return fmt.Errorf("exists: %v", kind)
	}
	s.services[kind] = service
	s.serviceTypes = append(s.serviceTypes, kind)
	return nil
}

Thinking of building an application in Go that has multiple running parts? Say you have some server that needs to do a bunch of different things while it runs, such as perform some backround jobs, update caches, handle several requests, expose a REST API, perform outbound requests to other APIs, all without blocking the main thread - what do you do? Typically, this is a good task for creating a microservices architecture where you have multiple applications talking to each other over some network service mesh, each containerized in some nice docker environment, orchestrated through something like Kubernetes or docker-compose.

type sub struct {
    feed         *BoolFeed
    channelIndex int
    channel      chan bool
    once         sync.Once
    err          chan error
}

This blog post explores the design rationale behind building a performant, simple, one-to-many event feed library in Go. We'll be recreating the event library from the go-ethereum project step by step, even explaining some of the tricky design decisions behind its robust concurrency approach.

Coming from Honduras, attending college in the U.S. felt an unattainable dream during my high school years. Emblazoned upon one of the entrances to Harvard University one can find the words:

"Enter to Grow in Wisdom, Depart to Serve Thy Country and Thy Kind"

This adage, although seemingly cliché, had its words weigh heavily on me as the years went on. I promised myself when starting my first year that I would not leave its walls an unchanged man. Despite its highs and lows, here is a final list of my major takeaways from my 4 years as an undergraduate at Harvard University.

type Marshaler interface {
    func MarshalType(
      val reflect.Value, 
      b []byte, 
      lastWrittenIdx uint64,
    ) (nextIdx uint64, error)
}

type Unmarshaler interface {
    func UnmarshalType(
      target reflect.Value, 
      b []byte, 
      lastReadIdx uint64,
    ) (nextIdx uint64, error)
}

Techopedia defines serialization as

The process of converting the state information of an object instance into a binary or textual form to persist into storage medium or transported over a network.

In simple words, it is the task of translating data using a common set of rules a standard system can understand, as well as the task of decoding translated data back into its original form using the same set of rules. All computers function around the notion of 1s and 0s, otherwise known as bits, which give us a convenient, common format we can serialize into.

The process of serializing data is called Marshaling, and the process of recovering original data from some serialized bytes is known as Unmarshaling. We will be using the two terms extensively throughout this post.