We tend not to use ORMs, because they're evil.
There are various libraries people use for auth, etc. But rolling your own isn't hard - Go has (e.g.) bcrypt in the standard library, so most of the heavy lifting is already done, you can write a solid auth implementation in <50 lines of code using that.
Generally Go prefers libraries to frameworks. Wrap the hard bits up into a library that can then be used widely in any implementation, rather than rolling it into a one-size-fits-all implementation that doesn't really suit anyone properly.
please don’t generalize. there is no “we” ..
“we” are all different and i can tell you from experience that there are also many people and teams who use go and prefer ORMs and frameworks and do not build everything from scratch …
> We tend not to use ORMs, because they're evil.
This is typical Go culture. If it is not readily available in the language or the standard library, it's evil. It's an easy cop out to explain away the gaps in the ecosystem.
Not long ago, the Go team was saying that generics are evil for that very same reason.
I second that no-ORM statement. I even follow that in Java. Object mapping is fine, but I’ll write my own SQL, rather than debug obscure (to me) HQL queries.