Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse.

It's what we call in France "la fête du slip".

PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLisp, because I really see the size of my deptree this way.

▲

junon 7 hours ago | parent | next [-]

Because fat std is rigid, impractical, and annoying.

	▲	majorbugger an hour ago \| parent \| next [-]
		Yeah, it's annoying to have good support for dates in Java since 2014, instead of only getting it now like in JS.
	▲	dboreham 23 minutes ago \| parent \| prev \| next [-]
		I think we found the constituency that led to the present sorry situation.
	▲	grey-area 4 hours ago \| parent \| prev \| next [-]
		In practice (e.g. Go) it’s actually pretty good and infinitely preferable to third party everything.
	▲	PunchyHamster 4 hours ago \| parent \| prev [-]
		Works just fine in Go.

▲

hypeatei 7 hours ago | parent | prev [-]

Fat std library mistakes/warts would likely result in third party packages being used anyway.

	▲	a-french-anon 4 hours ago \| parent \| next [-]
		Not necessarily, but let's agree that some design faults would happen: you still get the option to use the solid, boring and slightly rusty std instead of another 100 dependencies from the supply chain supermarket. At work, we're happy with Python's included batteries when we need to make scripts instead of large programs.
	▲	wolvesechoes 5 hours ago \| parent \| prev [-]
		So it provides another option, and in worst case it doesn't make situation worse than it is right now? Yeah, pretty bad idea.