Honestly? I think the answer is "the one you already know". Most of the languages covered in the article are capable of doing 90+% of what the average tech startup needs (a web site, an API, database connectivity). Save yourself the trouble of heading towards the latest hip technology and just write with the stuff you already know how to use. Worry about how flexible and scalable it is once you've actually proven your idea works.
OP here, when you build a company, you need more than one person so you also need to think about your product needs (what tech better fitted) and who you will hire to help you build it.
That still seems backwards. Hire developers. Use a language those developers are comfortable with. Don't choose a language then hire developers for it.
In any case, I'm not sure that many (any?) product needs could dictate choice of language in the vast majority of cases. Yes, if you need to do a ton of realtime stuff then maybe think about Node etc., but most people want the same standard stuff.
"hire developers, use a language those developers are comfortable with."
So you can use that method when hiring the first developer.
When it's time to hire the second developer, are you looking for only developers that are comfortable with the same languages as the first developer? If so, you are hiring developers based on language, and no longer following your advice. If not.... then you get a bunch of developers comfortable with different languages, and now what?
Often the answer might be "good developers can learn to be effective at any language." Which while on the whole (if not always) true, nevertheless only sometimes works for an enterprise (sometimes you don't have time to wait for them to learn it). But even so, now that turns into different advice: Hire your first developer, have her use a language she's comfortable with, then hire subsequent developers that either already know that language or are capable of learning it, and have them learn it. Which doesn't sound quite so obvious as your original advice, although it's not neccesarily an unreasonable approach.
So use what you are comfortable with - as long as it's not something that's so completely obscure that no one else knows it. If you just chase popularity, you're also probably likely chasing mediocrity. On the other hand, no, Visual Object Forth ++ from Borland is probably not the best thing to build a web site with.
I think that the article would have been helped by defining what a "startup" is more clearly. "Two guys in a garage toiling away at an MVP" is not the same kind of company as "post A round, just moved into slick offices and we're hiring a dev team." (The article seems to be more about the latter than the former.)
Getting something up & running is more important that everything else put together (except maybe determining what that something is.)
It's hard enough to get from "thought" to "thing" without worry about all the details. For an MVP, almost any technology can do almost anything you need. So just do it.
Although not ideal, you can always refactor, rewrite, rearchitect, or redeploy. But unless you have a time machine, you can't go back and do it again. So listen to untog and use what you already know.
I can't remember where I read it, maybe even HN, but I'm regularly reminded of this quote:
"Never use a new language for the first time for a project you love or that's important to you - you'll end up hating both the language and the project."
