So, first of all, for the examples you cite - reds, memcache, elastic search, aws, etc. - I have never, ever seen a member of the Go community say "don't use a library".
The Go community is anti-framework, not anti-library.
And what's the problem with frameworks? Well, remember up until now most Go shops (including my own), are micro-service orientated. You want small, lightweight, high-performance services. Why would you want or need a large monolithic bag of tricks in there? If you need complex routing, are you sure it's a micro-service? If you can't keep track of the datastore and need an ORM, are you sure it's a micro-service?
Also, it's a discipline, not a requirement. In the same way other languages have their idioms (I'm a Ruby dev of 10+ years experience too - those idioms are baked in _hard_ for me), Go's idioms are around structure, performance, and what is reasonable to write at a larger level.
Should you use libraries in Go? Yes. Should you use frameworks? Nobody is stopping you, but are you sure Go is the right place for you and your monolithic application?
Also, I don't see a problem with the official Go website having a tutorial in Go using the standard library. Why would they not?
I don't think you read my comment, or at least if you did, you didn't understand the point I was making.
Micro-services are the appropriate design pattern that means frameworks are redundant in a micro-service architecture.
Code structures do not need to be standardised in a service you can read the entire source code to in 20 minutes and replace in a few days if you need to.
Micro-services do not want or need the integration of a variety of plugins, and little to no boilerplate is required.
The Go community is anti-framework, not anti-library.
And what's the problem with frameworks? Well, remember up until now most Go shops (including my own), are micro-service orientated. You want small, lightweight, high-performance services. Why would you want or need a large monolithic bag of tricks in there? If you need complex routing, are you sure it's a micro-service? If you can't keep track of the datastore and need an ORM, are you sure it's a micro-service?
Also, it's a discipline, not a requirement. In the same way other languages have their idioms (I'm a Ruby dev of 10+ years experience too - those idioms are baked in _hard_ for me), Go's idioms are around structure, performance, and what is reasonable to write at a larger level.
Should you use libraries in Go? Yes. Should you use frameworks? Nobody is stopping you, but are you sure Go is the right place for you and your monolithic application?
Also, I don't see a problem with the official Go website having a tutorial in Go using the standard library. Why would they not?