Awesome Go: The Go resource list you need to bookmark
Every Go project starts with the same question: is there already a library for this? There almost always is. The hard part is finding the good one among the half-dozen abandoned ones with near-identical names.
Awesome Go is where I look first. It’s a community-maintained list of Go frameworks, libraries, and software that has been quietly doing its job for years. Rather than just telling you to bookmark it, I want to give you a tour of what’s actually in it and how I use it.
What makes Awesome Go different
Package search tools will happily index anything with a go.mod file. Awesome Go won’t. Every submission goes through review: maintainers check code quality, documentation, and whether the project is actually being maintained. Plenty of pull requests never make it in.
That filter is the whole value. When you pick a library off the list, a human has already looked at it and decided it clears the bar. It’s not a guarantee it’s the right choice for your project, but it removes most of the junk before you start evaluating.
How the list is organised
Everything is grouped by category, and the categories map neatly onto the decisions you make at the start of a project. Web frameworks: Gin, Echo, Fiber, Chi. Logging: Zap, Zerolog, Logrus. Configuration: Viper, Envconfig, Koanf. Testing gives you Testify, GoMock, and Ginkgo, and the database section covers drivers for everything from PostgreSQL to MongoDB.
Each entry is a one-line description and a link to the repository. No star counts, no rankings, no editorialising. You still do the evaluation yourself, which I think is the right call. A list that told you which framework to pick would be out of date within a year.
Finding packages the smart way
Say you need an HTTP client with retry logic. You could type hopeful phrases into GitHub search. Or you could open the “HTTP Clients” section and scan a handful of vetted options in about a minute.
Here’s where that gets you:
// You find resty in the Awesome Go list
// https://github.com/go-resty/resty
package main
import (
"fmt"
"github.com/go-resty/resty/v2"
)
func main() {
client := resty.New()
client.SetRetryCount(3)
resp, err := client.R().
SetHeader("Accept", "application/json").
Get("https://api.example.com/users")
if err != nil {
fmt.Println("request failed:", err)
return
}
fmt.Println("Status:", resp.Status())
}
The list pointed me at resty, and I spent my evaluation time on one strong candidate instead of researching ten weak ones.
Contributing to Awesome Go
Awesome Go takes part in Hacktoberfest each year, and adding a package is a genuinely approachable first open source contribution. It’s just a pull request, but the quality bar is real:
// Good packages have clear, documented APIs
// Here's an example of what maintainers look for
package mylib
// Client handles API communication.
// It supports retry logic and rate limiting.
type Client struct {
baseURL string
timeout time.Duration
}
// NewClient creates a Client with sensible defaults.
func NewClient(baseURL string) *Client {
return &Client{
baseURL: baseURL,
timeout: 30 * time.Second,
}
}
// Get fetches a resource. It returns an error if the request fails.
func (c *Client) Get(path string) ([]byte, error) {
// Implementation with proper error handling
}
Clear documentation, exported types with comments, proper error handling. Nothing exotic. You would be surprised how many packages fall at this hurdle.
Building your own toolkit
When I start a new project, I browse the relevant sections and make a shortlist before writing any code. For web services, my stack usually ends up looking something like this:
package main
import (
"github.com/gin-gonic/gin" // Web framework
"github.com/rs/zerolog" // Logging
"github.com/spf13/viper" // Configuration
"github.com/jackc/pgx/v5" // PostgreSQL driver
)
func main() {
// All discovered through Awesome Go
r := gin.Default()
r.GET("/health", func(c *gin.Context) {
c.JSON(200, gin.H{"status": "ok"})
})
r.Run(":8080")
}
Every one of those is on the list. That’s not the reason I use them, but it is how I found some of them in the first place.
When to look beyond the list
The list favours established libraries, which is mostly a feature but occasionally a limitation. A brand new package can take months to appear, and coverage in niche domains is thin. If you’re doing something unusual, you’ll end up back on GitHub search eventually.
It also can’t teach you patterns. If you’re exploring advanced patterns like functional options, the list will hand you libraries that use them, but the judgement about when to reach for them comes from reading code and getting it wrong a few times.
Wrapping up
Bookmark Awesome Go and check it before you add a dependency. Better still, pick a category you already know well and read through it. You’ll almost certainly find something you didn’t know existed, and if you maintain something good that isn’t listed, open a PR.