One of the nice things about Dart in particular is that they are actually very aware that they are currently a small community.
In that sense they ended up making a big focus on having great interop with other languages. Currently they have C, C++, Rust, Swift, JavaScript (browser and node), Java, Kotlin and Objective C all more or less working and an upcoming goal of WASI will also open up that entire ecosystem.
Plus all of your usual interop solutions for out of process communication. I.e anything that speaks gRPC like Ruby, C#, Go, PHP etc has strongly typed automatically generated code libraries for you.
I don't think this is wrong, but maybe missing some nuance:
Popularity definitely gives you "more stuff on the shelf", but it's also probably fair to say that at some level of popularity there's "enough" on the shelf.
What "enough" is, probably varies for different projects.
Just as an example, a while back I was involved in an Erlang project and while that ecosystem certainly does not have as much available as, say, Ruby, it had the pieces we needed, like a Postgres library and a few other things. The runtime itself was a better fit than others for the semi-embedded system we were working on, so in the end we chose that over more popular languages.
For sure you're right, it's always a tradeoff. But to compensate for a deficit in popularity, a technology needs to have tremendous merits.
Language performance is only important in some very specific cases (I/O trumps CPU in most use case), type safety is now becoming pretty standard everywhere.
Your example of embedded system is indeed a case where the environment has so specific constraints that the runtime behavior of the technology can make a huge difference. But for the regular "json <-> postgres" backend that are the bread and butter of our industry, i'd say it's an exception.
>In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.
I would have thought so too, but surprisingly we have seen completely new ecosystems emerge where incumbants had seemingly covered all the bases.
When Node.js and Go came along, we already had Perl, PHP, Python, Java and C# for backends (as well as tons of less popular options).
Each new player offered some technical benefits, but I never felt that these relatively modest technical differences merited starting a whole new library ecosystem and doing it all over again.
I can only conclude that you and I are wrong to think that the availability of mature libraries dominates other factors such as people wanting to get rid of the previous generation's culture. Wiping the slate clean seems to be a deeply felt desire.
Most of the stalwarts you mention had been built to depend on more or less huge systems where the webserver/appserver was in a central postion (Apache, J2EE or IIS), node had a certain minimalness combined with client/server code sharing going for it and Go had the whole "be as cool as Google" vibe off it (also not tied to a big server but being self-contained) and both of them meshed well with a certain microservice trend of those days.
Yes, there was a certain hype driving them but they also fit into the "devops" paradigm shift where the unit of management became a container/application instead of begging a BOFH to configure part of a "large" server that were suddenly becoming commoditized (The desire wasn't maybe so much a clean slate as to not be held back by sysadmins).
Fashion-driven development is obviously much more pervasive than we'd like to admit. And if I don't understand the previous tech better than the new one I might just as well use what's hot and all the rage now.
In that sense, the most important property of a language is its popularity: it will ensure connectors exist, and are used enough to be working fine.