Go doesn’t enforce a project layout. That freedom is powerful but requires discipline — start simple and let structure emerge as complexity grows.

When your Go project depends on an internal library living in a private GitLab repository, a plain go get will fail — GitLab doesn’t know who is asking, and Go doesn’t know the repository is private. Fortunately, a handful of configuration steps sorts everything out, both locally and in CI.

gitlab-backup: Back Up and Restore GitLab Projects from the Command Line

Source code: github.com/sgaunet/gitlab-backup

When you self-host GitLab or rely heavily on gitlab.com for your projects, having an independent backup strategy is essential. GitLab’s own backup mechanism works well at the instance level, but sometimes you need something more surgical: back up a single project, or an entire group, on demand, and store the result locally or in S3. That’s what gitlab-backup does.

I’ve been maintaining perplexity-go for a while now — a small Go client for the Perplexity AI API. It started as scratching my own itch (I needed a CLI to query Perplexity from scripts) and grew into a library I now reach for whenever a Go project needs real-time, cited answers from the web.

This post is a tour of what it does, why it exists, and how to use it.

A running list of Go modules I use or want to keep on my radar. Some I reach for daily, others I’m still evaluating. The Go ecosystem moves fast, so this post will keep evolving — treat it as a snapshot, not a manifesto.