There's one idea I've seen reiterated over and over again in relation to the Go language, to the extent that it seems to be nothing short of dogma at this point.

You don't need a framework, just use the standard library.

This is most often said in relation to web frameworks, but the idea tends to (rightfully or not) bleed over to other domains as well. While I agree that Go's standard library HTTP support is truly next level, what does that idea mean? Why would I never actually need a framework?

Level set

To frame the conversation, it's useful to have a consistent definition of terms.

Library

In the context of this post, a "library" is a collection of utilities that solve a particular problem domain. They aren't intended to express their own opinions in your codebase beyond solving the particular problem at hand.

Framework

A collective grouping of solutions which work together to allow the developer to fill in the blanks and deliver quickly. Often a framework comes with opinions and patterns that helps to work within the framework.

Why no framework?

So back to the question: why don't we need a framework? There seem to be a few justifications for this idea (most of which I agree with).

The standard library's http support is most everything you should need, so why work with anything else

Well, I'm a bit hesitant about something that claims to be "everything I need", but it seems to be pretty much true. There aren't many use-cases that simply can't be solved with it, and for those that can't there's likely a bolt-on lib that can solve the problem.

So if I agree with this sentiment then what's the problem? Mainly, I can't easily fork the Go standard library. There have been times when the Go team's ideas don't necessarily match mine, and that's fine. However, if I disagree then I don't have a recourse to address that short of building something like fasthttp. So I can hitch my wagon to Go's standard library forever more, but if they make a change to it v2 that conflicts with my goals for using the language then I need to find something else. All that time poured into "just using the standard library" with the expectation of it solving all of my problems out of the box is a bit of a false sense of security.

Go devs abhor "magic"

Sure, I've been bitten enough by Spring "magic" to develop a distaste for it. However, I know that Spring has its place, and when it's the right tool for the job I use it anyway. Regardless what is the "Spring way", there is always a way to be more explicit where it counts because there is tremendous value to clean, clear, and explicit code. That's part of why I love Go so much.

That being said, sometimes I don't want to rewrite the same code over and over again, and sometimes that same code can congeal into a wider architectural paradigm that works really well for my use-case... kind of like a framework. I can have a framework that is explicit in what it's doing while abstracting away the stuff I really don't care about, and I don't think there's a problem there.

Just use "X" library

I pretty much just reject this idea outright. If I followed every "just use" idea out there I would never ship code. This is just as valid as "just use a framework" while simultaneously being used as justification not to. Weird.

A framework's priorities don't necessarily match yours

YES! This is a solid reason to steer away from something. Using the right tool for the job means A, not being afraid to throw your current tool away and B, thinking critically of your tool in the first place. Being able to weigh the value and cost of something requires actual engineering thought and understanding. We need to take the time to understand the trade-offs and be able to validate our decisions. Sometimes we really don't need a framework when a small set of handler functions would do just fine, and similarly it's fine to use a framework when its priorities do match yours. Just understand the difference.

Summary

To make good decisions we have to understand what we're getting vs what we're giving up. Life and engineering is about trade-offs, and neither is made substantially better by hard adherence to rules that don't allow for judgement calls. We do need to think critically of the technology choices we make, and that means that "easy" isn't always "right". If a framework's ideas don't match yours then there are more options out there, including the standard library. Just use the right tool for the job. It's fine.