There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please.
But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.
That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.
"No good developer would choose to start a new project in earnest in a new language they don't understand well."
There are plenty of developers who chose to do just that, eg:
PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET).
WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang).
Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).
Whatsapp certainly wasn't a weekend project that took on a life of it's own. More of a multiyear project where the guy figured he may as well use the best technology because he'd have plenty of time to learn it. From startup school:
..why did you choose Erlang?
Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.
But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about.
That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.