But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.
I once wrote some Haskell professionally. It was a successor to a previous generation of the application that I had written in Python and maintained for several years. Using Haskell was my choice and it was made because some of Haskell’s strengths would address specific pain points learned from that experience. Meanwhile, everything else I wrote for that client was still being done in mainstream languages for mainstream reasons and there was never any suggestion that we would rewrite anything else in Haskell or adopt it by default for any new work, so I think this situation is clearly distinct from category 3 in the article.
What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently.
Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done.
I do get caught in HR filters a lot without a bunch of projects in gooby though.
This is the right attitude
Languages are boring. Problem domains can be a lot of fun.
When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.
Not really, unless you're trying to extract the maximum performance from the compiler, or you're trying to publish your own libraries. You learn Java, C# is pretty close. You know LISP and Java, you can pickup Clojure really quick.
As for the ecosystem, what you need to learn depends on the problem, not on the solution. If you need to do JSON parsing, you take a few days to investigate the available libraries, write your own parser if none exists. That assumes you know what JSON is and what serializing data entails. These are universal problems that exists outside of the Knowing Language X scope.
I'd much prefer hiring someone who can build web applications than someone who knows express.js.