[massung]

With programming languages, all you’re doing it picking which problems you don’t want to have to worry about and which ones you do.

When a team decides to switch programming languages, which would be a major undertaking, it’s typically for one of the following reasons:

1 - There is a deeper understanding of the problem space and the initial language doesn’t actually help the team from creating bugs that would be determimental to the continued operation of the business (eg, choosing Erlang when 9 9s of uptime is of absolute importance or a systems language when nanoseconds matter).

2 - Time has passed and there are many frustrations the team is dealing with in either maintaining - or extending - the current codebase. And there is now a belief that switching everything over to $LANGUAGE will solve those problems. This is rarely true and almost always a red herring as (typically) institutional knowledge of what the original set of problems $ORIGINAL_LANGUAGE solved are forgotten/ignored due to them not ever being a problem. But as soon as you flip the switch, the team will be acutely aware of them.

In the end - unless it’s made for a legit business reason (see: #1) - more time will pass and the same team will be frustrated with a different set of problems.