I'm a big fan of rapid prototyping in Perl - not because I think it's a more appropriate solution, but because it's the language _I'm_ most productive in while in "make it up as I go along" mode (and the language I enjoy random hacking in most). If I'm not going to write a spec before I start coding, I'll get to proof-of-concept stage very quickly using Perl. So long as you remember to _always_ throw the first one away and plan to rewrite it, getting something working _fast_ is a great advantage - even if only to allow you to fail fast - I'd rather give up on a weekends worth of Perl hacking that revealed no-one else cares about the problem I'm trying to solve, than a weeks worth of careful design spec and carefully considered system architecture and code structure.
So long as you admit to yourself when you've got a quick-n-dirty hacked together dog and pony show, I think the "best" _initial_ back-end language is the one that you can get a MVP up and running and generating customer feedback most quickly. Even if you _know_ you need a multi-cloud-auto-scaling no-sql-memory-cached auto-sharding super-service to support your 10,000 simultaneous users, you don't need to build all of that until you've got demonstratable traction... You _certainly_ will be better off with a single-threaded-maxed-out-at-8-users prototype, and getting real customer feedback early.
Once you've proved the problem is worth solving, _then_ do your massive-scale system architecture, and choose the ongoing backend based on that.