TL;DR: If you're choosing a programming language simply based on its own merits, you may get the decision wrong. You must take into account the leverage offered by its community and ecosystem, both current and future.

I have a friend in the D.C. area who is learning to program. He began with a free online course in Python, and is now using Django to code his first personal project, a web application. The last time we talked, I suggested that at some point in the future, before he goes too far with Python, he should do some research comparing it to Ruby (including Rails), and possibly also JavaScript (including Node and Express.) One idea I gave him was to go to each of the local user groups (Python, Ruby, JavaScript), and ask if anyone could help him decide. After a couple weeks I received this update:

hey chris,

so i brought up the question ruby vs. python at a meetup the other day and it set off a 30 minute discussion! a lot of folks in the room programmed in both, some even learned ruby first, so it was a good group to ask. in the end though, the consensus was go with whichever you like, so i'll think i'll stick with python for now. the language makes a lot of sense to me and i've got some momentum so i'll stick with it for now.

This reminded me of some advice I received when I was in his shoes, just starting out. I had asked a senior developer how to decide between C++ and Java, and she told me that apart from Java's garbage collection, they were pretty much the same. Both had classes with which you could do object-oriented programming. She seemed dismissive of my question. As we talked further, she seemed to suggest that it was the programmer's skill that was the decisive factor, rather than the choice of language, which was merely a tool.

Thus, some prevailing wisdom: It's general programming ability that counts. A good programmer will be successful in any language. The choice of language should be appropriate to the task at hand, but otherwise can be made based on taste.

Leverage

A year later, I was in my first job as a Java developer at a company that was mostly using C++. The VP of Engineering asked me and one of the C++ developers to each code a logging solution. There were a lot of features to code from scratch, such as saving the log output to a database, so he gave us each 5 weeks to do the job. I searched online for a few minutes and found log4j, an open-source library that had almost all of the requested features. I had to customize it to add a logging level that the VP of Engineering wanted, but I was done in about 5 hours.

Expecting to be treated as a hero, I went to the VP of Engineering with the news. His reaction was "alright, that sounds like it will work," and without missing a beat he found me something else to work on. After seeing a lot of this type of indifference over the years, my conclusion is that programmers and programming organizations feel good about using their skills, and they regard the stuff they build as assets. They don't get the same satisfaction and pride of ownership from integrating third-party solutions. I think the VP of Engineering was a bit disappointed to discover that logging in Java was not an opportunity to add to our company's stock of intellectual property.

A few weeks later, the C++ developer was still working hard on his solution. Although no one else seemed to care, my win with log4j sold me on the importance of leveraging third-party software. I mean, 5 hours instead of 5 weeks! I suddenly saw programming as a globally cooperative undertaking, with software compatibility as the most important factor.

Within the limited scope of individual or even team work, the idea that you should choose a language or other platform because you like it best seems reasonable. But again, think about the difference between 5 hours and 5 weeks. That's just one very small example. At every level of the stack, communities of developers work together to create ecosystems. Every platform choice you make–operating system, database, language, framework, library–is throwing in your lot with the present and future community and its output. It's vital to get each decision right, and to quickly reverse the ones you get wrong.

Platform vs Community

Typically, the language or other platform that you like best is the one that you feel helps you get more done in less time. What you appreciate is the inherent leverage that it offers. Therefore, the capabilities of the platform itself are definitely part of the equation: Your total leverage is the leverage you get from the platform plus the leverage you get from the community and ecosystem. All benefit depends on being able to apply the leverage to your problem space. In some situations, especially a novel problem space, a large amount of community leverage can be irrelevant, since it just doesn't fit. One of my favorite examples is Paul Graham's Beating the Averages, the story of using Lisp as a secret weapon in the early days of the Web.

Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.

What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours.

Paul's competition used languages such as C++, Perl, and Java that they perceived as offering more ecosystem leverage than Lisp, but because the problem space was relatively new, there wasn't enough applicable leverage to really help. Today, going it alone with Lisp for a mainstream CRUD web application would be a different story. In a competitive environment, it would be suicidal.

Change

Since technology never sits still, playing the game successfully means divining the future. Many platforms are guided by a small group or even a single individual. I once made the decision to ditch a new but popular framework when I learned its BDFL had accepted employment that I correctly judged would turn out to be a distraction.

Some rare individuals manage to create the future. It seemed like one year Ruby was mostly useful as a console in which I could calculate how much money I was making as a Java consultant, and the next year I saw the project I was working on getting crushed by a competitor who was using Ruby on Rails. When that project failed, I myself switched to Rails. David Heinemeier Hansson created Rails because he liked Ruby better than PHP or Java, despite the enormous ecosystem leverage offered by these dominant platforms. Unlike Paul Graham with Lisp, Hansson's evangelism resulted in the creation of an immense ecosystem. As Victor Hugo said, "one does not withstand the invasion of ideas." Creating a new ecosystem will not often succeed, but it can, if you invent the right platform, or are correct in your assessment of an under-appreciated platform.

Conclusion

Nowadays, I code my personal projects in JavaScript. To be honest, I think Ruby is a nicer language. But as a platform, JavaScript occupies an incredibly strategic position, being natively available on browsers, as well as on servers and desktops with Node.js. Most importanly, the leverage on offer from the ecosystem is so vast as to defy measure. The issue becomes one of too many solutions. How to choose among the dozen or so packages on npm for each and every problem? Again, don't pick the one you like!