I used to think that way until I ran into one of the pathological cases (Ruby) and now I'll think very carefully about which job offers to accept based on the language(s) involved.
exactly - last year I had to learn Go and Scala for a job, and it was a nice experience learning something new. 2 languages with advantages and disadvantages, and good support from VSCode and IntelliJ. This year, I had to learn Ruby, and found it to be a mess, with poor support from VSCode and RubyMine. Apparently you can't know what methods exist on a class until runtime, so the IDEs don't can't tell you much about your code.
Just like you shouldn't be so open-minded that your brain falls out, a language shouldn't be so dynamic that you can't tell anything about a line of code until you're in the middle of executing it. Maybe it's great for cranking out a CRUD web app in a weekend, but not so great for a product that's had 300 developers writing code for 10 years.
I've just inherited a Rails project that's been in development for the last 10 years. I know one of Ruby's mantras is something along the lines of "Optimized for Programmer Happiness," but after working with it for a couple of months, I have to ask "who is the programmer there?," certainly not the maintenance programmer. If code is read X times more than its written, then aiding comprehension is of the utmost importance. I'm not a huge fan of Go, but I do have to say that its readability greatly improves the developer-experience.
