Usually, a problem can be solved in multiple ways, with each being an effective solution. Regarding programming languages, this is also true. Many problems can be solved with multiple languages, in fact theoretically all turing complete languages should be able to solve the same problems.
Nevertheless, we tend to stick to the language that we are most comfortable with, whether that be the first language that we learnt, or just the language that we're most comfortable working with currently. Learning new languages requires investment, not just in learning the language, but of the libraries, idioms, and environments as well.
When solutions are chosen to problems, they can usually be boiled down to some combination of what I'm calling the language itself, the libraries, or the environment.
Language here is meant to be the expression of the solution to problems. It is the syntax, but more importantly the vocabulary of concepts that can be used as mechanisms to construct solutions. In the general sense, this is the most crucial, because like with human language, it constrains the concepts that are available for solutions.
These are the existing bodies of code tha are available to be readily consumed. Most languages have a suitable standard library that are able to perform the necessities. Naturally, necessities vary a little bit based on audience and the problem, but there are certain agreed upon operations that are so ubiquitous that they are taken for granten. But, the breadth and depth of the libraries around a language can vary tremendously.
By environment, I refer to the tooling surrounding the language and libraries. This could be any ide's that are used, but more importantly, it's the ecosystem of operations available to support daily operations for programmers. These include things like debugging, build/package management, deployment, run time characteristics, and many others.
The decision as to whether a language can be used involves weighing the combination of these three elements. We could have the perfect language, but it won't be picked up if there aren't libraries to support day to day operations. And if we have a great language and even better library support, it may be dismissed if it can't run in our production environment. Note that the opposite can also be true. Sometimes a library is selected because of what it can do and the language and environment simply come along for the ride.
There are also social elements to consider as well. If our team is particularly well versed in a certain area, chances are good that we won't veer too far from our domain of expertise. Additionally, if some knowledge is highly esoteric, that can play a major role in the decision as well.
What's interesting to me is that it rarely comes out that the decision is merely the sum of its parts. There's a certain minimum score required in each area. The minimum varies based on context, but nevertheless, a champion in one but a flop in the others will most likely not be chosen.
Although in the abstract there are many factors to consider, practically a select few typically emerge as the important players. It's important to identify which of these are significant earlier on, and focus on those when we make our choices.