[outworlder]

> It's not like my 3 years of experience in Ruby is immediately translatable to Java/Python/whatever.

It should be.

Picking up language X is very easy for most values of X (more esoteric ones excluded). After you know a few (and the more diverse the set, the less new concepts you'll see), picking up a new one is quick. If it is something like Go, it's a weekend's worth.

Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time. If you are a solo developer, or if the entire team is ramping up at the same time, then it is bad.

But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not? They may even bring new skills to an otherwise homogeneous group.

I always let the interviewee pick the language during my interviews. Usually it is something like Javascript or Python. Sometimes it is Bash. I keep waiting for the day someone will offer to do it in Scheme, Haskell, Elixir, Prolog, D, Rust, even Ada. Pseudocode is actually fine too, unless I have a reason to think the individual lacks programming experience.

Whatever you do, DO NOT brand yourself as a X developer, if X is a programming language. I can understand specializations like machine learning. But languages? It's a mere tool, and you need more than one in your toolbox.

[RussianCow]

> But a new, experienced team member, with zero knowledge in the most used language in the team? Sure, why not?

It really depends on how much time you have to wait for a new hire to ramp up before they are useful. If you need immediate help, then hiring someone who doesn't even have experience with your programming language is a complete non-starter. If, on the other hand, you are hiring for the long term and can afford to pay a ~3-month tax for a good engineer for (hopefully) several years, then you are correct and the ramp-up cost becomes pretty insignificant. But don't make the mistake of thinking that this is an exception to the rule—what languages you know absolutely does matter to any company needing to get work done now.

[cup-of-tea]

> Picking up language X is very easy for most values of X

I disagree. If you know Y and you're learning X, it depends much more on the value of Y. If Y is Lisp you will be quite successful at learning any X. If Y is something like C or assembly language, then you will not (it's always easy to spot the C guy who just started using Python etc.)

[Communitivity]

In my experience it is like learning a spoken language. If you know a language in the same family then learning the new language is relatively easier (e.g, Java -> Scala, Lisp -> F#). I also think the ease of learning a language is proportional to the ratio of expressiveness of the language you are coming from to the expressiveness of the language you are going to (e.g., Lisp to F# might have a much easier time than F# to Lisp).

[crdoconnor]

>Using the language in idiomatic ways and knowing the most useful libraries and frameworks does take more significant ramp-up time.

Yeah. As in years. This stuff also changes all the time so requires perpetual learning.

>But languages? It's a mere tool, and you need more than one in your toolbox.

It's not a mere tool and languages are more than just trivially learned syntax. They are the umbrella under which a panoply of tools, approaches, ideas, priorities and culture aggregate.

Sure, you specialization isn't necessarily always the optimal approach and sure there are benefits to the cross fertilization of ideas across community lines. However, being a jack of all programming languages, master of none probably means you'll suck more than a specialist at a lot of stuff.

Moreover, some ecosystems plain suck and avoidance is the sign of a good programmer. Statistically, you're probably a worse programmer if you've used a lot of PHP and better if you've learned rust/F#.