The standard library of a language is a collection of tools you most likely want to use sometimes but not every time you write a program. Those are most of the time to big to include in every program or are some kind of niche ( like "Math" modules). That's why you have to import parts of the standard library each time you want to use them. The standard library is also installed with every copy of the language, thus you don't need to install dependencys if you want to use someones code thats purely build with the standard library. A common example would be Threading, many languages include a way to have multi threaded processes, but you, as a developer, can decide whether to use it or not.
Nice explanation. I'm curious, if anyone has an idea, of how different language creators/maintainers think about the use of standard libraries. Which languages have the most robust standard library vs the ones that are more minimal, (or comparisons across different spectrums) and why that is?
There's a fundamental contention between maintainability/bulk and usefulness.
C++ opted for a minimal standard library for the longest time. It kept the language small, and made it easy to keep those libraries maintained. But for the longest time a lot of basic tasks in C++ were a chore, since there just wasn't a library for them. It really felt like you couldn't make a pure C++ program since there was always something missing. (This has changed in recent years, but it still leans towards minimal)
Compare this to Java that seemed to put everything and anything into the standard library. You could develop things quickly, since everything you needed was there. Over the years however a lot of the API became antiquated. But since it's part of the standard it's stuck there forever, requiring maintenance and guaranteed support. Or you have to deprecate and risk breaking somebody's project.
Languages like Python and NodeJS take the approach of having community supported packages for a lot of featureS (though Python's standard libray is quite feature rich on its own). The package approach is a good way to keep the language easy to use without maintaining a large standard library. It has the drawback that many, potentially essential, APIs are maintained at sub-par quality, and may be abandoned by their developers.
Nobody knows what the the right balance is. It's not likely the same for each language, as it's more domain driven than language drive. Certainly though an easy way to integrate community packages is a huge boon. Having too much crud lying around however, both standard and in the community, hurts everybody though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The standard library of a language is a collection of tools you most likely want to use sometimes but not every time you write a program. Those are most of the time to big to include in every program or are some kind of niche ( like "Math" modules). That's why you have to import parts of the standard library each time you want to use them. The standard library is also installed with every copy of the language, thus you don't need to install dependencys if you want to use someones code thats purely build with the standard library. A common example would be Threading, many languages include a way to have multi threaded processes, but you, as a developer, can decide whether to use it or not.
Nice explanation. I'm curious, if anyone has an idea, of how different language creators/maintainers think about the use of standard libraries. Which languages have the most robust standard library vs the ones that are more minimal, (or comparisons across different spectrums) and why that is?
There's a fundamental contention between maintainability/bulk and usefulness.
C++ opted for a minimal standard library for the longest time. It kept the language small, and made it easy to keep those libraries maintained. But for the longest time a lot of basic tasks in C++ were a chore, since there just wasn't a library for them. It really felt like you couldn't make a pure C++ program since there was always something missing. (This has changed in recent years, but it still leans towards minimal)
Compare this to Java that seemed to put everything and anything into the standard library. You could develop things quickly, since everything you needed was there. Over the years however a lot of the API became antiquated. But since it's part of the standard it's stuck there forever, requiring maintenance and guaranteed support. Or you have to deprecate and risk breaking somebody's project.
Languages like Python and NodeJS take the approach of having community supported packages for a lot of featureS (though Python's standard libray is quite feature rich on its own). The package approach is a good way to keep the language easy to use without maintaining a large standard library. It has the drawback that many, potentially essential, APIs are maintained at sub-par quality, and may be abandoned by their developers.
Nobody knows what the the right balance is. It's not likely the same for each language, as it's more domain driven than language drive. Certainly though an easy way to integrate community packages is a huge boon. Having too much crud lying around however, both standard and in the community, hurts everybody though.