Funny that all of these, minus the first one, have next to nothing to do with the language itself, and everything to do with its standard library and external tooling.
Yes, first point, and datatypes as well. And to be fair, the author does state clearly that some of the features & benefits he lists can come from a mix of language/standard libraries, OS, runtime or third-party. At the end of the day, you just have to be able to be productive with the language.
If you’re coming up with a brand new language, you have to do a damn good job of compensating for it by piggybacking on existing VM/Libraries/third-party tools (which Swift largely does), building it in your language and standard lib (e.g. Ruby), or doing a good job at attracting a new community to build that for you.
I guess that's what attracted people to Python some ten years ago, as opposed to Perl. One can be sure that CPAN has a Perl library fit for your needs, but having such features in the standard library makes a big difference for a newcomer.
The same could be said in the devops context with Ansible vs Chef/Puppet. Ansible joined the game pretty late, but it's attracting a lot of users because of its "batteries included" philosophy. But this battle is still ongoing and only history will tell us the winner.
> having such features in the standard library makes a big difference for a newcomer.
And not just for the newcomer. The biggest benefit is that your dependencies and your dependencies dependencies can all compose better when they're all using the same standard implementation of feature X.
The extreme case of this problem was c++ in the bad old days when lots of organizations were writing their own String libraries. Inevitably, you'd add a dependency that pulled in yet another incompatible string implementation.
