Comment by a-french-anon
24 days ago
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.
Fat std library mistakes/warts would likely result in third party packages being used anyway.
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.
So it provides another option, and in worst case it doesn't make situation worse than it is right now?
Yeah, pretty bad idea.
Because fat std is rigid, impractical, and annoying.
In practice (e.g. Go) it’s actually pretty good and infinitely preferable to third party everything.
Yeah, it's annoying to have good support for dates in Java since 2014, instead of only getting it now like in JS.
Works just fine in Go.
I think we found the constituency that led to the present sorry situation.
That's rather rude.
If you're referring to my packages on npm, I joined way late to that game. This was also ~15 years ago.