When talking about programming languages, we often talk about the cool features that we could use and the thriving ecosystems that we could leverage. But when we’re choosing programming language for a project, what really matters is the team that is going to use it.
Learning a new programming language – if you want to use it in anger – takes time, even if you have a lot of experience. In addition to the language itself, you have learn about architecture, ecosystem, deployment, and operations with the new language.
For example, I was working in a team of experienced Clojure and Java developers when the management decided invest in Python. We went along and started a bunch of new projects in Python.
None of us had significant recent Python experience, but it has a reputation of being an easy language. It took us a good while to figure out how to handle dependencies, how to get a suitable test setup, how to structure our programs, how to deploy them with our existing infrastructure. We didn’t actually get the software into production use before I moved on, but I bet that would have taught us a number of new lessons.
This was an investment with real opportunity cost: we had a tight six-month schedule to ship a new product and we took weeks to learn Python. We could have spent all that time on polishing product, had we used a language that we already knew. Hopefully the investment pays off in the years to come.
In the short term, an experienced team using a programming language that they know will always beat an experienced team using a programming language new to them. In the long term things may be different.