> I think core-language-feature counts are something it's better to have in moderation.
If an app needs something, it will either get it from there, or failing that, from add-on packages.
That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required.
Due to inter-package dependencies, that plan can easily be foiled.
In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages.
The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.
I agree about batteries-included languages, but that applies more to library-type tools, IMO, than language features. A library-type tool is something like "I need to get an md5 hash; I hope a function to do that is included with the language distribution so I don't need to go find a library!". A language feature is something in response to questions like "How do I express that I'm calling a method on an object? Or that I want to read a key out of a dictionary object? Or automatically generate code for a method when I call something that doesn't exist?". Those are sometimes implemented in terms of libraries, but are instead often implemented in the syntax and behavior of the language/runtime itself. For example, Java has a specific syntax for "call a method on an object instance or class", and that's "thing.methodname()". Sure, it could be implemented in the library style ("call_method(thing, 'methodname', args[])"), but that's typically not what people want. Perl tends to have, in my experience, an outlier surplus of language features and libraries.
I'm only arguing for moderation in the syntactic/language-feature department; I agree with you that a good, curated set of wide-ranging libraries is something that every language should have--ideally as part of the core distribution.
> but that applies more to library-type tools, IMO, than language features.
I'm a Lisp person of many years, so my perception of this distinction has gradually atrophied, dried and fallen off.
But even in this context, I would still rather have a larger language (more stuff which is Just There), even though more kinds of things can be add-on modules in Lisp than in something like Perl.
If an app needs something, it will either get it from there, or failing that, from add-on packages.
That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required.
Due to inter-package dependencies, that plan can easily be foiled.
In the end, it's better to have a big, "batteries included" language. For one thing, it is all released at once. No separate versioning for one hundred different packages. The regression test suite for the language can cover that functionality which would otherwise be in packages. No nonsense of releasing a new version of the language and then relying on field reports about broken packages.