Earlier quoted context omitted.
Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is good advice, the standard library really does have everything you need . But it's also roughly on a par with what's available in Rust (though as someone said above, the Go stdlib routines have been heavily, massively, tested in production by now, and are fully ma…
Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?
I think few people would want to use an ORM for the stuff you use Go for, but there are things like SQLC which can generate a lot of your "dynamic DB magic" without actually being a real dependency. You can set SQLC up to run in a container in a completely isolated environment, and then use the output, but you can frankly also just maintain the SQL which frankly isn't that different than using an ORM once you've set up the automation with ridicilously strict policies.
We use Go for some of our more vital backend parts. We mainly use Python for entirely different reasons, but since we're an energy company it's nice to have a standard library that can do everything without any sort of external dependencies. It's not because we have some sort of "not invented here" fetish, it's because we have to write and maintain a literal fuckton of complaince documents for every external dependency we use and it's already a full time job for just for Python in our information security department.