I'm always torn by these posts. I love perl's (well Moo's) class definitions - the simple, obvious way to make immutable objects combined with the `lazy` pattern fits really well with how I like to write code. But.

I have never quite got my head around the point of runtime constraints. If something passes bad data to a function, moo(se) throws an inscrutable error and I'm stuffed - there's no obvious way to recover, things just die. Static type checking tells you at compile time that you goofed, and then the system doesn't have to spend all that time checking every argument to every function every time it's called. PEP484, jsdoc + tsc & RBS show you can do this incrementally on existing code.

Huge amounts of existing perl code & libraries are not async-aware, so rewriting things to take into account concurrency is a huge undertaking. From Log4perl's global MDC through to pretty much every single file parser's blocking behaviour, there's so little code that can be reused from the perl5 oeuvre that I honestly think it's too late.

The fundamental issue here is that yes, all of these things could happen. We could assert that perl8 will be concurrent/async, have awesome runtime type checks etc etc. But why bother? Who is going to pay for it (aka spend time on it)?

The elephant in the room is that even if we did all this stuff - rewriting all the "core" libraries needed for a modern language to follow these awesome new paradigms (from json parsers, date libraries, web frameworks, database libraries - essentially, all of go's core libraries + a ton more), perl is still slow.

As hn discussed a few months ago, the author of mojolicious decided to try a JS version of mojolicious. His experience, like mine, was that even as a naive JS coder writing stupid schoolboy code, he saw a 5x+ speedup. Go is the same - a seasoned perl dev writing stupid, beginner go code results in >5x performance, and pretty much free concurrency.

It's almost embarrassing researching technologies these days. When was the last time you found something that provided perl support? We all know the hierarchy: Java, js, go, python, .net, rust. Then the next tiers: php, ruby, maybe scala, kotlin or swift. Maybe even the unexpected: dart, lua, OCaml. Perl? Maybe if someone on cpan wrote one. I honestly think the last first-party library I saw was mongodb, back around 2010 (the perl library is now officially EOL since 2018, obvs).

By all means write a new perl because you love it, but be honest with yourself in terms of what is achievable. No-one is going to spend the time/money/resource required to take the existing perl codebase and make it into a modern language that can compete with python, js, java, go or rust. And even then, what compelling/unique features can a "new" perl offer? Rust gained marketshare because it was safe with near-c performance. Go compiles & runs almost as fast as a dynamic language, compiles to a single binary, had an awesome core library, excellent performance and a compelling concurrency story. Nodejs had an critical mass of devs who already knew js from browsers, a bunch of highly-resourced companies competing to make it fast, and is getting better all the time (async/await, const/let etc etc).

I understand that people love languages, but sometimes we have to understand that perl is like Amiga (or blackberry, zune, or even scala (ooh, contentious)) - we can love a thing but understand that its time has been and gone. We can mourn what could have been, but there is no world in which Amiga will become a significant force again. Similarly, there is no world in which perl will gain significant marketshare again.