&gt; a lot of the community has wandered off to other &#x27;cool&#x27; languages and frameworks<p>I am just one such. Half my career was writing Perl.  But these days, most of my work is in Ruby and as a longtime fan of Erlang (but never having had the opportunity to use it in production), I&#x27;m taking a long look at Elixir+Phoenix.  This tutorial wasn&#x27;t enough to entice me back to Perl, and I&#x27;m wondering if there is anything at all that could.<p>In general we choose a language for their applicability to the problem domain.  The focus on text manipulation in Perl 4, and then extension of this with an object framework in Perl 5, made it a shoo-in in the 90s and early C21 when we all needed form parsing, HTML template stuffing, and email mangling tools.  In these days of dynamic DOM manipulation and event-driven microservices, it doesn&#x27;t seem so relevant; whilst Node and Go and Elixir look entirely on point.<p>If you go look at the Perl 6 FAQ, there&#x27;s a section, &quot;Why should I learn Perl 6?&quot;. It lists a grab-bag of language features, rather than a set of problems that Perl 6&#x27;s new design can solve. As a result it feels much like a solution in search of a problem.  That wasn&#x27;t even ever true of JavaScript, even though JS took years to come of age.<p>If I was designing a language today, and I am not, but if I were, I would look at how dominant Java seems to be in the big data community and try knocking it off that perch with appropriate language primitives, constructs and libraries. It seems to me this is the modern problem domain homologous to the bulk text mangling for which Perl originally became famous.