[at_a_remove]

I agree about the stdlib. There was a reason that xkcd had the "import gravity" joke. One of the reasons I ditched perl was having to evaluate so many different perl libraries, which would do anywhere from thirty to eighty percent of what I needed, and tended to come with some really exciting dependency chains.

I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future).

Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.

[CraigJPerry]

Anecdotally, this approach has been replicated by go. The stdlib in go is surprisingly complete. I’ve seen several go developers cite this as an advantage, being able to write many apps without adding dependencies from external to the language runtime.

I definitely think they’re onto something. Dependencies are a hard problem to solve.

Modern build tools like gradle work great at resolving deps, until they don’t and at that point we’re in for a world of shock at just how complex dependency resolution can be in large projects.