golang-popular-libraries

name	golang-popular-libraries
description	Select and evaluate Go libraries by fit, maintenance, API stability, security, licensing, and integration cost, with the standard library as the baseline.

Go library selection

Library popularity is not a correctness signal. Start with the standard library and the module's existing dependencies. Add a dependency when it removes meaningful risk or complexity and its maintenance, license, transitive graph, and operational behavior are acceptable.

Before recommending a package, verify its current module path, latest compatible release, supported Go versions, license, repository activity, security advisories, and the API in the exact version the project will pin. Do not infer a maintainer or lifecycle guarantee from a README badge.

Practical evaluation

Compare candidates against the actual constraint:

• standard-library capability and missing behavior;
• API fit and whether context/cancellation are supported;
• failure, retry, timeout, and resource-ownership semantics;
• compatibility with the project's Go version and build targets;
• transitive dependencies, generated code, CGO, and binary size;
• release cadence, issue responsiveness, license, and known vulnerabilities;
• migration and exit cost.

Prefer a small, direct dependency to an abstraction stack. Keep third-party calls behind a narrow adapter when the library is volatile or external. Pin versions through normal Go module review; run go mod tidy and tests after changes. Never use go get -u as an unreviewed bulk upgrade.

Useful baselines

• HTTP: net/http, httptest, and standard URL/encoding packages cover many clients and servers.
• JSON: encoding/json is the stable baseline. Do not use old golang.org/x/exp/json guidance as if it were a released encoding/json/v2 API; verify the target Go release and module path.
• Logging: log/slog with a handler selected for the deployment.
• SQL: database/sql plus a driver; sqlx or pgx when their explicit features justify them.
• RPC: google.golang.org/grpc or net/http according to the wire contract.
• Tests: testing, fuzzing, and benchmark support; testify is optional.
• CLI: flag for small tools, then a command framework when command-tree features justify it.
• Schema/migrations: use the project's reviewed migration tool and driver conventions.

Examples in this skill are categories, not a mandated stack. Check pkg.go.dev and the upstream repository for exact symbols, versions, and security notices before writing code.