Caching is the go-to solution in applications to avoid repeating expensive computation and instead prefer some value that can be readily fetched in-memory. A simple caching strategy is to use a cache as a thin layer above database read access as follows:

package main

import "sync"

type Database struct {
	cache map[string][]byte
	lock  sync.RWMutex
}

func (db *Database) GetItem(key []byte) ([]byte, error) {
	db.lock.RLock()
	if value, ok := db.cache[string(key)]; ok {
		db.lock.RUnlock()
		return value
	}
	db.lock.RUnlock()
	return db.readFromDatabase(key)
}

func (db *Database) WriteItem(key, value []byte) error {
	if err := db.writeToDatabase(key, value); err != nil {
		return err
	}
	db.lock.Lock()
	db.cache[string(key)] = value
	db.lock.Unlock()
	return nil
}

This strategy works great for applications where you have requests to read access for a certain value repeatedly, preventing you from performing a potentially expensive db query and leveraging fast access in-memory. Caching is very helpful. For some problems, however, a cache is definitely not enough.

(Credits to ScyllaDB)

Static analysis is the practice of examining source code in an automated way before code is run, typically to find bugs before they can even manifest. As a powerful programming language used in mission critical applications, Go also adds a lot of responsibility to its developers to write safe code. The risk of nil pointer panics, variable shadowing, and otherwise ignoring important errors can make an otherwise good looking program become an easy target for attacks or faults you never imagined could happen.

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.

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.