|
On the other hand, it is a lot of work to build your product in one language, which you then outgrow, which forces you to switch to another language. I've seen this happen many times, particularly with projects that started out in Python. Eventually the codebase and teams get too big, and managing a large codebase in a language with Python's type system becomes very cumbersome. Type annotations were a reaction to that, and adding them to the language has probably enabled a lot of teams to continue using Python. Off the top of my head, other examples of good changes include NIO and better concurrency primitives/lambda syntax in Java, generics in Go, and async/await in several other languages. All of those solved pain points for developers that might have otherwise been solved by switching languages. Why does this matter? First of all, it's a lot of work to rewrite products in different languages. Also, while it sounds attractive to pick the right language for the task every time, in practice it is difficult to run a coherent engineering organization if every product or team uses a different language -- it's hard to build good shared libraries and app frameworks for every language in use, and if someone leaves the company it can be hard to transfer their projects to other engineers. Most of the time, as an engineering org matures it eventually settles on a few "blessed" languages, invests in good frameworks for them, and requires all the teams to use them. Out of necessity, those tend to be the "kitchen sink" variety. |