Feature rich standard libraries help a lot with avoiding external dependencies. It's hard to avoid depending on lots of external libraries when writing Rust since the standard library doesn't cover much above low-level functionality. JavaScript is dramatically worse than that.
Conversation
Having a fat standard library can also cause a lot of friction. Assuming that the core developers get everything right, then all is well, but the odds of that are quite slim, and once you add a feature, it becomes very hard to remove it.
2
The standards for stability aren't inherently different in the standard library compared to an external one. If most of the external libraries don't provide good backwards compatibility, then that's just further demonstrating that they aren't a replacement for a standard library.
1
The difference is that, when a better idea comes along, a new library can be created.
Just look at the Python community for a good example of this. A huge portion of the standard library sits gathering dust. The community has created replacements that work better.
1
A better library can be created as part of the standard library too. Python's standard library is very poorly maintained and they moved away from wanting to have a strong standard library. It's no longer an example of a project that's attempting to provide that at this point.
1
The Python library maintainers did exactly what you suggest, and they're still in the situation that they're in. The standard library is poorly maintained for exactly this reason.
A smaller core remains relevant, and is better maintained as a result.
1
1
No, they didn't do anything close to what I suggest. The standard library was poorly thrown together and not thought out in the first place, and then they lost interest in improving it. They don't want a rich standard library anymore and aren't an example of trying to provide it.
1
Sure they did. They stopped doing it for python3, but Python 2 had several redundant libraries. Like urllib2.
1
They hardly did any of that and it's also not what I'm suggesting. I'm not sure why you're so interested in arguing against a strawman. Python is an example of what I'm suggesting is a good approach. It's a counterexample showing how to do things very poorly.
1
Well, do you have any examples of it being done the way you want it done?
1
Sure, Android's standard libraries along with the Kotlin language and standard libraries. It's an extremely broad and feature rich set of APIs. The platform has a versioned API level with yearly deprecations and removals. Evolves over time without legacy/abandoned apps breaking.
There's a reasonable amount of yearly work to migrate to the latest API level. You have many months of preview releases if you want to support the new ways of doing things for the initial stable OS release. You have over a year after that to migrate for new apps and app updates.
1
Legacy ways of doing things including entire libraries are very slowly deprecated and replaced with a clear migration path and detailed documentation / guides on moving from the old to the new ways. It's a vast amount of libraries / APIs when you include everything.
You're talking about two different projects, one of which is VERY platform dependent. I can (and do) use Kotlin for much more than Android.
Do you have any examples of a programming language's standard library that offers what you want, without a platform SDK?
1
Kotlin language and standard library take the same approach to gradually evolving without strict backwards compatibility. They avoid making sudden, drastic changes but rather slowly evolve it over time with easy to handle incremental backwards incompatible changes. Same approach.
2
Show replies