The common reply in the Go community is "don't use a framework" or "roll your own". The idea is that small packages suited to individual tasks are a better sol

The common reply in the Go community is "don't use a framework" or "roll your own". The idea is that small packages suited to individual tasks are a better solution than a large framework package that includes more than you need, or tried to for your use case into a shared, common use case. IMO, frameworks are great for rapid prototyping, but in Go and it's explicit programming style, most devs prefer to build most by have and only import a minimal number of packages for specific tasks.