A language is not just the basic control flow operations, but includes package management, performance gotchas, correctness gotchas, standard library, library ecosystem, data representation, etc. Then there are details and edge cases that you just don't hit without months or years of hard work with a language.
My experience tells me to take choose a reasonably robust language, then stick to that language until you have an overwhelmingly compelling reason to switch.
How do you know which tools are the best?
1. Come up with a set of options by doing research, talking to people who have solved similar problems before, etc.
2. Rank them by some criteria (e.g. availability of libraries, documentation, raw performance, hireability, support, quality of tooling, etc).
3. Do some prototyping in your problem domain using the top 2-3 (more if you aren't confident in your ranking) and pick whichever you like best.
4. Always be willing to change your mind down the road. Avoid the sunk cost fallacy and try not to lock yourself in too much until you're confident in your choice.