Go is among the few programming languages available today, where
the saying "Just use the standard library." holds for a vast majority of use-cases. The language has had the fortunate fate to appear at a time when many practices have had the chance to mature and establish themselves into de facto standards. Older languages have had to adopt these at a much later point, often after the community had come up with a widely used 3-rd party alternative.
This is why some people new to Go, expecting to be given a list of 3rd-party libraries and frameworks, frown when they get pointed at the standard library right away. Combined with Go's tendency towards explicitness and lack of abstraction, it might seem like starting new projects from scratch (a.k.a., bottom-up) is the only way endorsed by the community.
Which is why you're reading this post. I want to clarify that while the Go standard library is outstanding, it is just that - a library of building blocks meant to be used to build larger ones. Take any large and renowned Go repository on GitHub - chances are, it is using libraries and frameworks under the hood. That is both reasonable and practical. You don't build a house by simply laying out the bricks and calling it a day. Many steps come after, which turn that bunch of bricks into a place suitable for living.
Hold that same metaphor for a little longer. Suppose you run a house building company and you were tasked with building a house within a month. Would you start by baking bricks out of clay, one after another? Of course, not. You are much more likely to begin from the top - crafting a vision and delegating parts of this vision to others.
Not everyone's requirements are so few or well-defined to allow getting things done with the standard library alone. While possible, it will require more time than is feasible or result in cumbersome code. Often, we don't have that time - we have one shot to see whether our idea works or not. Rather than giving up or choosing other stacks, we should acknowledge that good Go frameworks exist, and we should use them to our advantage. If we design our project with the minimum amount of code separation in mind, we can later even get rid of the framework, but if it gets us to 80% of a working idea, why not just use it to bootstrap our way through?
It's the entrepreneurial thinking and the product rather than the technology that ultimately build the business. Given a chance to choose a Go tool that will let me show an idea to the world without having to cater for every nook and cranny from the very beginning, I'd choose that tool hands-down.
Such tools exist but are sadly not surrounded by the large community support they deserve (which is why I want to mention them here). Take a look at Buffalo - a Rails-like Web framework that comes with everything included for rapid Web prototyping, and at the end of the day, still manages to produce understandable Go code. We have been inspired by Buffalo ever since it came out, and in one way or another, incorporated many of its components in our product Murmel.
Does Buffalo go against Go's purist idea of "a thing that does one thing"? Probably. Did it help us build a product in zero time without compromising its performance? Absolutely!
I don't want this to look like I'm advocating frameworks for everything. We are all rational beings, and there are times when one thing works and others when it doesn't anymore. But frameworks shouldn't be seen as going against Go's understanding of simplicity.