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.
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.
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.
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.