reagin Choose a Go Library
Make a requirement-driven decision, not a popularity ranking. The best outcome may be the standard library, an existing dependency, a small local implementation, or no change.
Define the requirement
Before searching, establish:
- required behavior and excluded scope;
- library versus application usage;
- expected scale, latency, reliability, and security constraints;
- supported Go versions, platforms, and CGO policy;
- public API, serialization, storage, and interoperability constraints;
- license and maintenance requirements;
- the repository's existing dependencies and architectural conventions.
If a missing choice would materially change the recommendation, present it instead of assuming a framework or vendor.
Build candidates from live evidence
Start with the standard library and modules already present in go.mod. Add external candidates only when they offer material value.
For each external candidate, inspect current authoritative sources:
- pkg.go.dev module and package pages;
- canonical repository and tagged releases;
- versioned documentation and migration guides;
- license files;
- Go vulnerability database entries;
- module graph and Go-version requirements.
Use recent activity, maintainer response, release discipline, test evidence, and documented compatibility as signals. Stars, dependents, and name recognition are secondary context, not selection criteria. Record when evidence was checked because library status changes.
Exclude a candidate early when it fails a hard constraint. Do not hide uncertainty behind a numeric score.
Compare decision-relevant tradeoffs
Use a compact matrix tailored to the request:
| Criterion | Questions |
|---|---|
| Fit | Does it solve the required problem without forcing unrelated architecture? |
| API | Is the surface clear, stable, testable, and compatible with project conventions? |
| Operations | What background work, resources, configuration, telemetry, or shutdown behavior does it add? |
| Dependencies | What transitive modules, CGO, generated code, or toolchain steps enter the project? |
| Maintenance | Is the relevant version maintained and are migrations documented? |
| Security | Are there known advisories, risky defaults, or sensitive data paths? |
| License | Is the exact version's license compatible with intended distribution? |
| Exit cost | Can the project isolate or replace it if requirements change? |
Test a focused prototype or benchmark only when repository evidence cannot resolve a material question. Use representative data and preserve the user's chosen constraints; do not turn comparison into an unrequested implementation.
Recommend transparently
State:
- the recommended option, including standard library or no new dependency;
- why it best fits the named constraints;
- the strongest alternative and when it would win;
- material risks or unknowns;
- version and source evidence with observation date;
- an adoption boundary, such as a small interface or adapter, when it meaningfully reduces lock-in.
Do not claim a library is production-ready, fastest, safest, or most popular without scoped evidence. Do not recommend a package merely because a related skill exists.
If implementation is also requested, make the dependency change narrowly and verify the resulting module diff and tests.