Perl, for all its quirkiness, remains my favourite language - even though I've never done any professional work in it, and I took it up long after its glory days. A shame how it plummeted. It feels like "Unix, but as a scripting language!"
I've never been able to love Python, PHP, JS, Ruby or any other dynamic language the same way.
Maybe I would like Raku too, but I wonder if it's worth the effort - the languages are similar, and I already know all the quirks of one. A bit like learning Dutch after German?
Raku to me is like Esperanto: An absolutely beautiful idea that sadly is not used widely (or even known widely). And for both cases, I would love for things to be different, but since the alternatives (be it English or Java/Typescript/...) are deemed "good enough", chances are slim.
Makes sense to split the foundation, as the communities have split (and withered).
From its inception Perl 6 was an incredible journey that resulted in a genuinely weird and interesting new programming language, and squandered a broad wealth of momentum and good will and enthusiasm from the Perl community at large. It was a dramatic slow death over the course of a decade, where people who had built their careers, and small and large companies who had built their economic engines on Perl got to come to the realization that the whole thing was over, killed somewhat inadvertently by its own creator...
What if it had taken Nintendo 35 years to release the next GameBoy, and they now came along and said: "Listen up, everybody! We finally did it! It has a 16 bit processor now instead of 8 and 4 bit shades of green instead of 2, but it won't play any of your GameBoy games; you'll have to write new ones." -- If they did that, then being a hobby for a small number of true weirdos is the only way they could hope to fit into 2026. That's what Raku feels like to me.
> What if it had taken Nintendo 35 years to release the next GameBoy
More like Nintendo took 35 years to release the "VideoGameGirl", a product with a completely different name, and then suddenly a bunch of die-hard GameBoy fans are complaining that this separate product, even if it shares origin with the GameBoy, somehow doesn't even run games made for a different console.
That's how this Perl/Raku navelgazing feels like to me.
Indeed, but I guess the Perl/Raku haters don't have anything of actual meat in their complaints, so off bike-shedding about the most trivial shit we go.
> Perl/Raku haters don't have anything of actual meat in their complaints
For a random complaint of mine (one of many) see [1]. Using Perl as my main programming language for 3.5 years has given me plenty of "meat" to throw around; I just don't want to bore people with it, nor do I want to re-live the trauma.
Larry Ellison should buy it, then there would be no need for technical arguments any more, just like Java. You could just say "lawnmower" to end the debate on ethical grounds.
Not everything, but languages do serve a purpose tied to how many (and which) people speak them, and that's true for general purpose programming languages in the same way as for human languages. If learning Klingon is someone's "thing" then, well, everyone can judge for themselves whether the predicate "true weirdo" applies or not, but it's descriptive enough.
I would disagree, purely because the utility of a programming language doesn’t hinge on how many speak it.
The goal of programming languages is to execute instructions on the machine. Brainfuck still executes machine code the same whether 2 people write it or it becomes the lingua Franca of AI. There’s fewer libraries, but C FFI bridges a lot of that.
Learning Klingon is odd because human languages are meant for communication, so a language with no speakers is largely pointless (barring cultural value, which Klingon largely lacks because it’s a fictitious language and too modern to have that niche coolness).
> The goal of programming languages is to execute instructions on the machine.
The goal of a general purpose programming language is to communicate a program from one human to another, and from one human today to the same human tomorrow, while understanding that a program is only written once, but read many times. -- In that goal it is no different from a natural language. -- This goal needs to be optimized for within the constraint that programs must also compile and execute in the way and with the outcomes that a human reading the code would expect.
Your observation about Brainfuck makes my point for me: If the execution was the actual goal, then Brainfuck would be as good a programming language as Rust, Zig, or Nim; but that clearly isn't the case.
lol - I guess there is no defence for the long delays in getting Perl6 out of the door (2000-2015) and for sure that Osborned perl (5) and created a justified reaction from the perl community who wished that it had never happened. Thus the (slow) divorce with this being the decree nisi.
Turns out that Larry (and the team) were much better at language design than project management.
That said, since 2015 we have been blessed with an awesome new language.
>>Turns out that Larry (and the team) were much better at language design than project management.
It is true many times to deliver quality products you can't have deadlines. But without a deadline you are never finishing a thing.
Unfortunately for Perl, Larry Wall, and several of its project leads(Patrick Michaud, Audrey Tang) at various times had major health issues. Time moves on, and people have to at times resign entirely from projects due to shifting priorities and personal problems. Parrot VM I guess went through a similar arc.
Other people have moved mountains to get Perl going. But with time people's priorities have entirely moved on. At one time, all Python programmers would do is bad mouth Perl all over the internet, and that never really stopped. Any body who saw a Perl programmer do over a weekend, what they would take a year to do in their language(especially Java and Python)- had a deep rooted seething envy at Perl and Perl programmers. So they went around almost on religious crusade to have Perl gone. This was done entirely to crush competition. They just didn't want other people to wield a power they didn't have. Lisp has had a similar arc of development over the decades.
Perl 5 development being entirely stopped for years further complicated this issue. Eventually as most of the Perl code in many companies bit rotted and died, newer projects were started in Python/Java. And of course Frontend stack entirely moved away to Node/React. We had mobile development of which Perl never was ever a part of.
By the time ML/AI era came into being Python was defacto the language of programming for these kind of tasks.
The best part is now in the LLM era, the whole idea of a programming language itself is pointless.
> Any body who saw a Perl programmer do over a weekend, what they would take a year to do in their language(especially Java and Python)- had a deep rooted seething envy at Perl and Perl programmers. So they went around almost on religious crusade to have Perl gone. This was done entirely to crush competition. They just didn't want other people to wield a power they didn't have. Lisp has had a similar arc of development over the decades.
Isn't that the fate of the archetypical loser? To end up on the sidelines thinking "I'm actually the smartest and most powerful, the wider world just isn't capable of appreciating it".
I saw someone recently say something like... they wished contemporary Lisp people put anywhere near as much effort into creating lots of great software with Lisp as they do extolling Lisp.
Have literally seen a 'architect astronaut' crap on Perl in some 2 hour long call, and eventually had his way with getting the management to approve Java. This was mid-2000s
When our team initially budgeted it, 4 guys over 6 months were enough to get this over the finishing line. The java team took over took more than 3 years, and close to 30 people. It was a AbstractClassFactoryFactorySingletonDispatcher mess with spring decorators all over. Which quite honestly was quite ironic because the original case against Perl was it was hard to read.
The java code was easily 30x more verbose, no body at the end knew how to maintain it. It was all about the guy getting to own his own team, promotions, bonuses, raises etc.
Have seen the same story repeat over and over again, everyone knew they wanted Python because they could get to inflate their headcounts.
Its one of things about tech, its not the good tech that wins, its the tech that helps with office politics wins at the end of they day.
After golang came along a lot of these java things too went out of fashion. Curiously enough golang does feel a lot perly to use. And Python has long moved away from its minimalism activism days. To that Python has transformed into the same feature bloat it once accused Perl of.
> Python programmers would [...] bad mouth Perl all over the internet [...]
I am one of those, and I disagree with the moral connotation of that framing.
When you're in the know and give advice to someone who isn't, or when you're the previous generation passing on your lessons learned to the next, then you have two paths. You can either be honest about things that don't/didn't work, so mistakes won't be repeated. Or you can make it seem as if pixie dust covers everything you have expertise in that others don't and everything that your generation did that the next one will never know, so you look good. -- I don't think that the former path is the more morally reprehensible one at all. "Bad mouthing" is the wrong analogy here.
> You can either be honest about things that don't/didn't work, so mistakes won't be repeated.
What things don't work, then? There's a difference between disliking something to the point of personally being incapable of working with it, and something that in itself truly does not work. My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.
>>My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.
People who haven't used Perl to its full power have little how idea just how magical a language it was/is.
Have seen people's jaws on the floor watch Perl guys do automation they always thought was impossible, even more so delivered in such record times. CPAN itself as an idea was way ahead of its time.
Around COVID I had a project delivered, in a week. I basically wrote a Perl script that wrote Apache Pig scripts(Basically using Perl like a macro facility, and Perl is great at anything text). It was a massive project which otherwise would have taken more than a year to deliver. When I did show the team what I had done, had them in total awe in the same way people look at Claude Code today. Nevertheless it was the same reaction, when the project got done, they were not comfortable that some programmers could do stuff like this, which seemed alien to the remaining.
I have a belief that proliferation of Java/Python stunted the growth of web dev, and a lot other industries. In some way the last decade was entirely slowed down by adoption of these technologies. If Ruby/Perl were there things would have been way better.
I do love what LLMs are doing to Java and Python today.
Software development was never supposed to be as slow as what Python and Java made it.
> People who haven't used Perl to its full power have little how idea just how magical a language it was/is.
...why would you prefer to reach for the "no true scotsman ...", rather than read in any one of two other places in this thread that you are dealing with fellow scotsmen here?
I can't debate Raku with you, because I don't know any Raku, because, why should I? Life is short. I do know Perl 5, and the only context where a discussion of Raku even makes sense is as an upgrade path for Perl 5. Upgrade path doesn't mean that a program written in Perl 5 should run with unaltered syntax and semantics in Raku and not panic. Providing an upgrade path for Python 2 was one of the primary purposes of Python 3, and they didn't understand it that way either. Upgrade path simply means: Leverage syntax and semantics and mental models already in programmers' minds and change them where necessary to trade off short term pain for long term gain. (But it's less pain than learning a different language altogether with completely different syntax and semantics and mental models).
I can give you a list of grievances I have with Perl 5. Maybe Raku addresses some of those. Maybe it doesn't. I don't know, but also, it doesn't matter. The late arrival of Raku means decades' worth of people using Python and other languages as an upgrade path for Perl 5 instead, so Raku addressing any of those grievances is now closing the barn doors after the horse has bolted. Any Perl 5 codebases still out there are run by people who are so allergic to the idea of having to touch their code, that Raku isn't an option for those folks either.
Having said all of that: Some of my grievances with Perl 5:
* No separate types of bytestrings versus sequences of unicode codepoints. Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake. This includes databases backing Perl applications, where they themselves don't have enforcement, so even if you threw away all of your code and started from scratch and just wanted to keep your data, Perl 5 would still haunt you from its grave. -- Having strings not be mojibake is easy as hell in 2026. Perl 5 makes this easy thing impossible, so I really don't share your idea of "make easy things easy"
* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.
* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.
* Perl one-liners, and RSA decryption written in the form of a camel, make for nice t-shirts, but the same argument as above applies to them. There is no purpose today (but probably never was) in one-linerism because an LLM will knock out 10 lines of Python just as fast as 1 line of Perl, and reading those 10 lines of Python (which is the part that actually still matters) is more ergonomic than reading the Perl one-liner.
* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.
* No separate types of bytestrings versus sequences of unicode codepoints.
Fixed in Raku. You either have a string (Str) or a bytestream (Blob).
* Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake.
No mojibake in Raku.
* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.
Raku has single object / type system.
* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.
Raku regexes allow arbitrary whitespace, can contain comments and are composable.
Grammars are collections of tokens / rules / regexes that can be used to build an AST, and actions that can take that AST and build another data structure of it. A grammar is used to parse Raku itself.
Grammars can be subclassed or have rules / regexes mixed in (slangs).
* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.
The Raku ecosystem, albeit much smaller, is growing and actively maintained: https://raku.land
so it is also (just) possible to argue that since the relevance and attention on the HLL you pick choice is diminished, now you can just pick one you like as opposed to sticking with the Python / Go / Rust straightjackets
I forgot that some people purposefully go off-topic even though they actually do understand the topics :) Need to get better at expanding the bet options before I accept any more bets!
Context: Raku was formerly Perl 6; it was renamed in October 2019 for compatibility reasons.
> The major goal Wall suggested in his initial speech was the removal of historical warts. These included the confusion surrounding sigil usage for containers, the ambiguity between the select functions, and the syntactic impact of bareword filehandles. There were many other problems that Perl programmers had discussed fixing for years, and these were explicitly addressed by Wall in his speech.
> An implication of these goals was that Perl 6 would not have backward compatibility with the existing Perl codebase. This meant that some code which was correctly interpreted by a Perl 5 compiler would not be accepted by a Perl 6 compiler. Since backward compatibility is a common goal when enhancing software, the breaking changes in Perl 6 had to be stated explicitly. The distinction between Perl 5 and Perl 6 became so large that eventually Perl 6 was renamed Raku.
I really should get back to playing some more with raku, it was a fun experience the last time I messed around with it. Feels very expressive, like it will support any harebrained scheme you come up with.
A driving motivation for the immediate formation of The Raku Foundation in a country in the European Union is the Cyber Resilience Act, which will make it mandatory for any software that is sold or licensed in the European Union to define its dependencies, to have a mechanism for reporting and fixing faults, and establishes legal responsibility for those who sell software. This has major consequences for FOSS developers, which the EU has taken into account, by creating a new category of entity called Open-source software steward.
As to why NL:
So you gotta choose an EU nation - the choice of NL was really a convenience (the main driver of the project lives there), but NL also has innate strengths as a home as is pretty neutral choice (ie not France, Germany) and a lot of SWE talent and good English speaking skills (even if the legal docs are in local language).
well, yeah - but noting that there were many consultations and opportunities to challenge this decision and I (for one) would have complained if I didn't think that NL was a solid choice
Perl, for all its quirkiness, remains my favourite language - even though I've never done any professional work in it, and I took it up long after its glory days. A shame how it plummeted. It feels like "Unix, but as a scripting language!"
I've never been able to love Python, PHP, JS, Ruby or any other dynamic language the same way.
Maybe I would like Raku too, but I wonder if it's worth the effort - the languages are similar, and I already know all the quirks of one. A bit like learning Dutch after German?
Raku to me is like Esperanto: An absolutely beautiful idea that sadly is not used widely (or even known widely). And for both cases, I would love for things to be different, but since the alternatives (be it English or Java/Typescript/...) are deemed "good enough", chances are slim.
> ... even though I've never done any professional work in it ...
That's why you like it.
Makes sense to split the foundation, as the communities have split (and withered).
From its inception Perl 6 was an incredible journey that resulted in a genuinely weird and interesting new programming language, and squandered a broad wealth of momentum and good will and enthusiasm from the Perl community at large. It was a dramatic slow death over the course of a decade, where people who had built their careers, and small and large companies who had built their economic engines on Perl got to come to the realization that the whole thing was over, killed somewhat inadvertently by its own creator...
What if it had taken Nintendo 35 years to release the next GameBoy, and they now came along and said: "Listen up, everybody! We finally did it! It has a 16 bit processor now instead of 8 and 4 bit shades of green instead of 2, but it won't play any of your GameBoy games; you'll have to write new ones." -- If they did that, then being a hobby for a small number of true weirdos is the only way they could hope to fit into 2026. That's what Raku feels like to me.
> What if it had taken Nintendo 35 years to release the next GameBoy
More like Nintendo took 35 years to release the "VideoGameGirl", a product with a completely different name, and then suddenly a bunch of die-hard GameBoy fans are complaining that this separate product, even if it shares origin with the GameBoy, somehow doesn't even run games made for a different console.
That's how this Perl/Raku navelgazing feels like to me.
well the whole point of the rename is to sidestep the Perl vs. Raku navelgazing
Indeed, but I guess the Perl/Raku haters don't have anything of actual meat in their complaints, so off bike-shedding about the most trivial shit we go.
> Perl/Raku haters don't have anything of actual meat in their complaints
For a random complaint of mine (one of many) see [1]. Using Perl as my main programming language for 3.5 years has given me plenty of "meat" to throw around; I just don't want to bore people with it, nor do I want to re-live the trauma.
[1] https://news.ycombinator.com/item?id=42460014
Larry Ellison should buy it, then there would be no need for technical arguments any more, just like Java. You could just say "lawnmower" to end the debate on ethical grounds.
Not everything needs to be a mainstream movement, and not being one doesn’t automatically make you a “true weirdo”.
Not everything, but languages do serve a purpose tied to how many (and which) people speak them, and that's true for general purpose programming languages in the same way as for human languages. If learning Klingon is someone's "thing" then, well, everyone can judge for themselves whether the predicate "true weirdo" applies or not, but it's descriptive enough.
I would disagree, purely because the utility of a programming language doesn’t hinge on how many speak it.
The goal of programming languages is to execute instructions on the machine. Brainfuck still executes machine code the same whether 2 people write it or it becomes the lingua Franca of AI. There’s fewer libraries, but C FFI bridges a lot of that.
Learning Klingon is odd because human languages are meant for communication, so a language with no speakers is largely pointless (barring cultural value, which Klingon largely lacks because it’s a fictitious language and too modern to have that niche coolness).
> The goal of programming languages is to execute instructions on the machine.
The goal of a general purpose programming language is to communicate a program from one human to another, and from one human today to the same human tomorrow, while understanding that a program is only written once, but read many times. -- In that goal it is no different from a natural language. -- This goal needs to be optimized for within the constraint that programs must also compile and execute in the way and with the outcomes that a human reading the code would expect.
Your observation about Brainfuck makes my point for me: If the execution was the actual goal, then Brainfuck would be as good a programming language as Rust, Zig, or Nim; but that clearly isn't the case.
Hey, Klingon is totally mainstream and has been for decades longer than Raku has been around. Andorian is what true weirdos speak.
lol - I guess there is no defence for the long delays in getting Perl6 out of the door (2000-2015) and for sure that Osborned perl (5) and created a justified reaction from the perl community who wished that it had never happened. Thus the (slow) divorce with this being the decree nisi.
Turns out that Larry (and the team) were much better at language design than project management.
That said, since 2015 we have been blessed with an awesome new language.
>>Turns out that Larry (and the team) were much better at language design than project management.
It is true many times to deliver quality products you can't have deadlines. But without a deadline you are never finishing a thing.
Unfortunately for Perl, Larry Wall, and several of its project leads(Patrick Michaud, Audrey Tang) at various times had major health issues. Time moves on, and people have to at times resign entirely from projects due to shifting priorities and personal problems. Parrot VM I guess went through a similar arc.
Other people have moved mountains to get Perl going. But with time people's priorities have entirely moved on. At one time, all Python programmers would do is bad mouth Perl all over the internet, and that never really stopped. Any body who saw a Perl programmer do over a weekend, what they would take a year to do in their language(especially Java and Python)- had a deep rooted seething envy at Perl and Perl programmers. So they went around almost on religious crusade to have Perl gone. This was done entirely to crush competition. They just didn't want other people to wield a power they didn't have. Lisp has had a similar arc of development over the decades.
Perl 5 development being entirely stopped for years further complicated this issue. Eventually as most of the Perl code in many companies bit rotted and died, newer projects were started in Python/Java. And of course Frontend stack entirely moved away to Node/React. We had mobile development of which Perl never was ever a part of.
By the time ML/AI era came into being Python was defacto the language of programming for these kind of tasks.
The best part is now in the LLM era, the whole idea of a programming language itself is pointless.
> Any body who saw a Perl programmer do over a weekend, what they would take a year to do in their language(especially Java and Python)- had a deep rooted seething envy at Perl and Perl programmers. So they went around almost on religious crusade to have Perl gone. This was done entirely to crush competition. They just didn't want other people to wield a power they didn't have. Lisp has had a similar arc of development over the decades.
Isn't that the fate of the archetypical loser? To end up on the sidelines thinking "I'm actually the smartest and most powerful, the wider world just isn't capable of appreciating it".
I saw someone recently say something like... they wished contemporary Lisp people put anywhere near as much effort into creating lots of great software with Lisp as they do extolling Lisp.
Have literally seen a 'architect astronaut' crap on Perl in some 2 hour long call, and eventually had his way with getting the management to approve Java. This was mid-2000s
When our team initially budgeted it, 4 guys over 6 months were enough to get this over the finishing line. The java team took over took more than 3 years, and close to 30 people. It was a AbstractClassFactoryFactorySingletonDispatcher mess with spring decorators all over. Which quite honestly was quite ironic because the original case against Perl was it was hard to read.
The java code was easily 30x more verbose, no body at the end knew how to maintain it. It was all about the guy getting to own his own team, promotions, bonuses, raises etc.
Have seen the same story repeat over and over again, everyone knew they wanted Python because they could get to inflate their headcounts.
Its one of things about tech, its not the good tech that wins, its the tech that helps with office politics wins at the end of they day.
After golang came along a lot of these java things too went out of fashion. Curiously enough golang does feel a lot perly to use. And Python has long moved away from its minimalism activism days. To that Python has transformed into the same feature bloat it once accused Perl of.
> Python programmers would [...] bad mouth Perl all over the internet [...]
I am one of those, and I disagree with the moral connotation of that framing.
When you're in the know and give advice to someone who isn't, or when you're the previous generation passing on your lessons learned to the next, then you have two paths. You can either be honest about things that don't/didn't work, so mistakes won't be repeated. Or you can make it seem as if pixie dust covers everything you have expertise in that others don't and everything that your generation did that the next one will never know, so you look good. -- I don't think that the former path is the more morally reprehensible one at all. "Bad mouthing" is the wrong analogy here.
> You can either be honest about things that don't/didn't work, so mistakes won't be repeated.
What things don't work, then? There's a difference between disliking something to the point of personally being incapable of working with it, and something that in itself truly does not work. My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.
>>My impression is that the saying "Perl makes easy things easy and hard things possible" really does hold up.
People who haven't used Perl to its full power have little how idea just how magical a language it was/is.
Have seen people's jaws on the floor watch Perl guys do automation they always thought was impossible, even more so delivered in such record times. CPAN itself as an idea was way ahead of its time.
Around COVID I had a project delivered, in a week. I basically wrote a Perl script that wrote Apache Pig scripts(Basically using Perl like a macro facility, and Perl is great at anything text). It was a massive project which otherwise would have taken more than a year to deliver. When I did show the team what I had done, had them in total awe in the same way people look at Claude Code today. Nevertheless it was the same reaction, when the project got done, they were not comfortable that some programmers could do stuff like this, which seemed alien to the remaining.
I have a belief that proliferation of Java/Python stunted the growth of web dev, and a lot other industries. In some way the last decade was entirely slowed down by adoption of these technologies. If Ruby/Perl were there things would have been way better.
I do love what LLMs are doing to Java and Python today.
Software development was never supposed to be as slow as what Python and Java made it.
> People who haven't used Perl to its full power have little how idea just how magical a language it was/is.
...why would you prefer to reach for the "no true scotsman ...", rather than read in any one of two other places in this thread that you are dealing with fellow scotsmen here?
I can't debate Raku with you, because I don't know any Raku, because, why should I? Life is short. I do know Perl 5, and the only context where a discussion of Raku even makes sense is as an upgrade path for Perl 5. Upgrade path doesn't mean that a program written in Perl 5 should run with unaltered syntax and semantics in Raku and not panic. Providing an upgrade path for Python 2 was one of the primary purposes of Python 3, and they didn't understand it that way either. Upgrade path simply means: Leverage syntax and semantics and mental models already in programmers' minds and change them where necessary to trade off short term pain for long term gain. (But it's less pain than learning a different language altogether with completely different syntax and semantics and mental models).
I can give you a list of grievances I have with Perl 5. Maybe Raku addresses some of those. Maybe it doesn't. I don't know, but also, it doesn't matter. The late arrival of Raku means decades' worth of people using Python and other languages as an upgrade path for Perl 5 instead, so Raku addressing any of those grievances is now closing the barn doors after the horse has bolted. Any Perl 5 codebases still out there are run by people who are so allergic to the idea of having to touch their code, that Raku isn't an option for those folks either.
Having said all of that: Some of my grievances with Perl 5:
* No separate types of bytestrings versus sequences of unicode codepoints. Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake. This includes databases backing Perl applications, where they themselves don't have enforcement, so even if you threw away all of your code and started from scratch and just wanted to keep your data, Perl 5 would still haunt you from its grave. -- Having strings not be mojibake is easy as hell in 2026. Perl 5 makes this easy thing impossible, so I really don't share your idea of "make easy things easy"
* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.
* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.
* Perl one-liners, and RSA decryption written in the form of a camel, make for nice t-shirts, but the same argument as above applies to them. There is no purpose today (but probably never was) in one-linerism because an LLM will knock out 10 lines of Python just as fast as 1 line of Perl, and reading those 10 lines of Python (which is the part that actually still matters) is more ergonomic than reading the Perl one-liner.
* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.
* No separate types of bytestrings versus sequences of unicode codepoints.
Fixed in Raku. You either have a string (Str) or a bytestream (Blob).
* Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake.
No mojibake in Raku.
* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.
Raku has single object / type system.
* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.
Raku regexes allow arbitrary whitespace, can contain comments and are composable.
Grammars are collections of tokens / rules / regexes that can be used to build an AST, and actions that can take that AST and build another data structure of it. A grammar is used to parse Raku itself.
Grammars can be subclassed or have rules / regexes mixed in (slangs).
* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.
The Raku ecosystem, albeit much smaller, is growing and actively maintained: https://raku.land
yeah to "deep rooted seething envy"
and yes, LLM is moving HLL to a back seat - but not eliminating it entirely - otherwise, why not have your LLM emit ASM (or binary)
fortunately Raku got enough https://stackoverflow.com/questions/tagged/raku and https://rosettacode.org/wiki/Category:Raku that it made the cut to be usable on LLMs
so it is also (just) possible to argue that since the relevance and attention on the HLL you pick choice is diminished, now you can just pick one you like as opposed to sticking with the Python / Go / Rust straightjackets
Are you saying this as a Perl programmer or as an observer who never wrote any Perl?
Considering they're confusing Raku with Perl, I think it's a pretty safe bet they never coded with either.
3.5 years of using Perl5 for 8 hours a day every day. I'd like to take the other side on more of your bets please ;-)
I forgot that some people purposefully go off-topic even though they actually do understand the topics :) Need to get better at expanding the bet options before I accept any more bets!
And the original blog post from almost a year ago: https://dev.to/lizmat/towards-a-raku-foundation-3ne2
Context: Raku was formerly Perl 6; it was renamed in October 2019 for compatibility reasons.
> The major goal Wall suggested in his initial speech was the removal of historical warts. These included the confusion surrounding sigil usage for containers, the ambiguity between the select functions, and the syntactic impact of bareword filehandles. There were many other problems that Perl programmers had discussed fixing for years, and these were explicitly addressed by Wall in his speech.
> An implication of these goals was that Perl 6 would not have backward compatibility with the existing Perl codebase. This meant that some code which was correctly interpreted by a Perl 5 compiler would not be accepted by a Perl 6 compiler. Since backward compatibility is a common goal when enhancing software, the breaking changes in Perl 6 had to be stated explicitly. The distinction between Perl 5 and Perl 6 became so large that eventually Perl 6 was renamed Raku.
https://en.wikipedia.org/wiki/Raku_(programming_language)
I really should get back to playing some more with raku, it was a fun experience the last time I messed around with it. Feels very expressive, like it will support any harebrained scheme you come up with.
The link isn't working for me - anyone else?
Hm, are you on a VPN? Some hosters react bitchy to those.
You know what my favourite Perl joke is, invented it myself, raku is a Japanese lisp :D
A "risupu", per Google Translate.
I got 502 bad gateway. Then a register page. With a section about "Cyber Resilience Act".
That section is worth a read in my opinion.
sorry about the 502, glad to hear that is now resolved - there is some dogfooding going on with this site (uses https://harcstack.org)
well yeah the call to action is for all interested folks to register so that we can share details on how to become a member of the foundation
see also https://dev.to/lizmat/a-year-later-a-trf-1lh0 for some history and perspective
I looked through this article but wasn't able to find why it was decided to establish it in Netherlands (under the Dutch law). Could someone share it?
The site explains "why the EU" as follows:
A driving motivation for the immediate formation of The Raku Foundation in a country in the European Union is the Cyber Resilience Act, which will make it mandatory for any software that is sold or licensed in the European Union to define its dependencies, to have a mechanism for reporting and fixing faults, and establishes legal responsibility for those who sell software. This has major consequences for FOSS developers, which the EU has taken into account, by creating a new category of entity called Open-source software steward.
As to why NL:
So you gotta choose an EU nation - the choice of NL was really a convenience (the main driver of the project lives there), but NL also has innate strengths as a home as is pretty neutral choice (ie not France, Germany) and a lot of SWE talent and good English speaking skills (even if the legal docs are in local language).
> to find why it was decided to establish it in Netherlands
I don't think this is more complicated than Liz being Dutch and based in the Netherlands
well, yeah - but noting that there were many consultations and opportunities to challenge this decision and I (for one) would have complained if I didn't think that NL was a solid choice
> Raku began as Perl6
Guys.
We will just skip to perl7 anyway. People are too confused now.
As someone completely removed from the Pearl ecosystem, I thought this might be an Open Core something from Roku after the recent acquisition news.
Good read, thanks.