Recommended Resources

Generally Useful:

Let’s Talk about Logging: log an error or return an error, but do not do both
- Simpler: https://github.com/uber-go/guide/blob/master/style.md#handle-errors-once
Julia Evan’s Debugging Manifesto: a great general debugging guide. In particular, I’m a fan of “trust nobody and nothing”
UTC Is Enough For Everyone, Right?: a fun explainer on how time is really hard
Notes on Structured Concurrency, or Go Statement Considered Harmful: a post written to be “incendiary”, but really makes a good case for proper ownership and lifetime management of (concurrent) resources.
- Generalized: on resource lifecycle management:
  - if you created a resource, you’re responsible for its lifecycle
  - if you were given a reference to a resource, you are not responsible for its lifecycle

A Tour of Go for an introduction to the Language
Effective Go covers some good idioms/conventions
Go by Example is useful for little snippets of common needs
Rethinking Classical Concurrency Patterns really, really good talk about how to think about concurrency in Go
Don’t just check errors, handle them gracefully: errors are part of your API surface; consider not having, or relying upon, sentinel errors.
- for wrapping them, consider the following from The Go Programming Language:
  When the error is ultimately handled by the program’s main function, it should provide a clear causal chain from the root problem to the overall failure, reminiscent of a NASA accident investigation:
```
*genesis: crashed: no parachute: G-switch failed: bad relay orientation*
```
- Simpler: https://github.com/uber-go/guide/blob/master/style.md#error-wrapping
Align the happy path to the left—this will also inevitably show up as a PR comment to encourage reducing how indented code may be
- Simpler: https://github.com/uber-go/guide/blob/master/style.md#reduce-nesting
Functional Options for Friendly APIs: how to create variadic functions whose use is obvious at the call-site
Package Naming: package names should be descriptive. Utils is not.