There's also the distinction between a library - a tool that does one particular thing and does it well - and a framework - which dictates how you structure you

There's also the distinction between a library - a tool that does one particular thing and does it well - and a framework - which dictates how you structure your entire application. And this is a mindset as well. I mainly know the original quote in the context of Go, where the community as a whole (or at least the part that is in the Slack server) eschews big frameworks in favor of the standard library, lightweight architectures, and specialized libraries. A lot of people coming from other languages come into the communities and ask about whether there's anything like Spring for Go. Another common request is help with a major framework or abstraction like Gin (web API framework) or GORM (database ORM). But Gin is no longer really necessary as the SDK has good support for the common web API use cases, and GORM quickly breaks down as soon as you need anything more advanced than querying a single table, not to mention it's big and complicated but has only one lead developer (I believe), no major organization behind it. But Gin and GORM dictate how you structure at least part of your application; especially the latter adds a layer of indirection so you no longer have to ask "how to I join two tables in SQL" but "how do I join two tables in GORM", the latter of which becomes very specialized very fast. Anyway. Using the standard library is preferable, using small and focused libraries for specific problems that aren't solved by the standard library is also fine. Copy / pasting only the functions you need is also fine.