Disagree. I've found over the years that I pick up new programming languages rapidly. I attribute this to already having a broad base of experience in different paradigms and techniques such that at this point everything is just a variation on something I've worked with before.
But can something that everybody uses become a competitive advantage? Intuitively that doesn't seem true to me, although it would be an interesting dynamic if it was.
So it seems like you need a small collection of successful early adopters to prove its value instead as a middle ground for there to be any concentration of advantage at all.
I assume you're putting "competitive advantage" in reference to "gets me hired" instead of strictly "gets the job done well", in which case, yeah, someone hiring someone else for the way they get a job done rather than their ability to do so would probably get you stuck. You could fake your way in.
Otherwise you might be referring to "no one will get my code", which is also a legitimate concern.
I think you are probably better off being a top performer in a very common field. There is more opportunity that way. If you are lucky you can also be an early adopter in a growing field and ride the wave.
For example, Erlang and Haskell are cool languages and probably a technically better choice but I am not sure being an Erlang developer is a good choice for career development. There are not too many options for working in that field.
This strikes me as completely the wrong way to make decisions. If you're taking it as a given that you're a top performer in a common field, then yeah. You might as well assume you're a billionaire and argue how many doors that opens for you.
But you're not a top performer in a common field until you've committed years of effort to not being a top performer in that field. And you can hardly argue that the world is a worse place because someone wanted to be the world's best yodeler instead of the best truck driver.
What made me think that functional programming is worth being aware of is that good testing practices head towards things done more easily in functional programming, pretty quickly. Programming in functions guarantee a compartmentalization of state and a determinism of the result (as opposed to non-determinism).
Procedural programs and Object-Oriented programs need to postulate concepts like design-by-contract, assertions with explicit precondition/post-condition checks, and unit testing suites as a form of insurance against non-determinism and poor compartmentalization. So it's possible to get this kind of control but only after writing a lot more code.
Going completely stateless is probably foolish though.
As for your heuristic: yes, I agree, a top performer in a common field is a safer bet and a sound strategy. If you're able to secure yourself properly you won't be overcome by a large increase of top performers, if such a thing is possible. We have a lawyer over-supply so I guess in some fields it is.
You don't have to be an "X" developer. Developers can know more than one language, and knowing functional programming can definitely be a competitive advantage, even if you don't typically use functional languages.
