Rules for New Go Programmers

When you start learning a new language and want to accelerate your progress, you have no choice but to deep-dive. You must immerse yourself in the culture, the language, and the literature. You must strive to learn to think in that language.

The same rules apply when you learn to program in a new language, for example, in Go. You skyrocket your chances for success if you follow simple rules. The Go programming community at the Bitfield Institute of Technology (BIT) call them the 10 commandments of Go. Ready to dive in?

First, your code and writing must be boring. They must be so clear and simple that your readers won’t need to think twice about what you want to say. You must use a formatter to shape the thoughts you express in the code. You must be as explicit as possible. You write what you mean to make the computer do. You don’t leave room for assumptions, and you practice obviousness-oriented programming.

Next, you design your program using a test-first approach. You don’t build bridges and houses without technical plans, and you don’t write programs and then adjust requirements to them. That’s backward thinking. You measure twice and cut once.

You delight users of your libraries and packages with clean and obvious APIs. You write packages that give users pre-configured functions ready to use for most common default scenarios. You save users from doing paperwork. Do you know anyone who likes unnecessary paperwork?

Don’t surprise users. Don’t hide explosives in your libraries—you are not allowed to panic! It’s up to your package user to decide how to handle the bubbled error. Live this job and leave this decision to others.

Write programs as if other humans’ lives depend on them! Don’t leak resources; assume nothing and check everything. You don’t know when your package will become part of a critical application.

Don’t build artificial restrictions in your libraries. You don’t know how the users will use your software. Remember the Go mantra: “Accept interfaces, return structs”.

Set boundaries between systems exchanging data. Don’t introduce tight coupling. That’s why you learn to employ the adapter pattern. The adapter transforms and validates external API data schema into the format your library requires. You must also check all errors to prevent invalid data from leaking outside your package boundary.

Next, don’t use interfaces internally; use concrete types. In Go, mocks are rarely needed, especially when they are written only for tests.

As always, there is at least one exception from the rule. So there are in Go. You must open your mind to embrace a new way of thinking—a new way of thinking in the Go language.

Enjoy the ride and remember what Rob Pike - one of the creators of Go - once said: “Simplicity is complicated”.