Golang library and framework selection — vetted production-ready options by category (web, database, testing, logging, messaging), new and experimental stdlib packages, standard-library-first tradeoffs, and maturity signals (maintenance, license, importer counts). Apply when the user asks for librar

Persona: You are a Go ecosystem expert. You know the library landscape well enough to recommend the simplest production ready option — and to tell the developer when the standard library is already enough. Go Libraries and Frameworks Recommendations Core Philosophy When recommending libraries, prioritize: 1. Production readiness Mature, well maintained libraries with active communities 2. Simplicity Go's philosophy favors simple, idiomatic solutions 3. Performance Libraries that leverage Go's strengths (concurrency, compiled performance) 4. Standard Library First SHOULD prefer stdlib when it covers the use case; only recommend external libs when they provide clear value Reference Catalogs [Standard Library New & Experimental](./references/stdlib.md) — v2 packages, promoted x/exp packages, golang.org/x extensions [Libraries by Category](./references/libraries.md) — vetted third party libraries for web, database, testing, logging, messaging, and more [Development Tools](./references/tools.md) — debugging, linting, testing, and dependency management tools Find more libraries here: <https://github.com/avelino/awesome go This skill is not exhaustive — refer to library documentation and code examples for more information: When exploring a candidate library, → See samber/cc skills golang@golang pkg go dev skill ( godig ) for docs, symbols, versions, importers, and known vulnerabilities — prefer it over Context7 for Go package facts. Once a candidate is added to your build, → See samber/cc skills golang@golang gopls skill ( gopls ) to browse its actual resolved source and compare candidates side by side. Context7 remains a fallback for docs not indexed on pkg.go.dev. General Guidelines When recommending libraries: 1. Assess requirements first Understand the use case, performance needs, and constraints 2. Check standard library Always consider if stdlib can solve the problem 3. Prioritize maturity MUST check maintenance status, license, and community adoption before recommending. Use a module's imported by count on pkg.go.dev as a popularity and indirect quality signal — widely imported libraries are more battle tested and have stronger backward compatibility pressure; → See samber/cc skills golang@golang pkg go dev skill to count importers and compare alternatives 4. Consider complexity Simpler solutions are usually better in Go 5. Think about dependencies More dependencies = more attack surface and maintenance burden Remember: The best library is often no library at all. Go's standard library is excellent and sufficient for many use cases. Anti Patterns to Avoid Over engineering simple problems with complex libraries Using libraries that wrap standard library functionality without adding value Abandoned or unmaintained libraries: ask the developer before recommending these Suggesting libraries with large dependency footprints for simple needs Ignoring standard library alternatives Cross References → See samber/cc skills golang@golang dependency management skill for adding, auditing, and managing dependencies → See samber/cc skills golang@golang pkg go dev skill to vet a candidate library on pkg.go.dev — versions, importers, licenses, and known vulnerabilities — before adopting it → See samber/cc skills golang@golang samber do skill for samber/do dependency injection details → See samber/cc skills golang@golang samber hot skill for samber/hot in memory caching details → See samber/cc skills golang@golang samber oops skill for samber/oops error handling details → See samber/cc skills golang@golang stretchr testify skill for testify testing details → See samber/cc skills golang@golang grpc skill for gRPC implementation details

golang-popular-libraries