Hacker News new | past | comments | ask | show | jobs | submit login
Larry Wall has approved renaming Perl 6 to Raku (github.com/perl6)
619 points by Ovid on Oct 11, 2019 | hide | past | favorite | 439 comments

From what I could tell, Raku appears to be from Rakudo, the Perl 6 compiler, which is a shortened form of rakuda-dou (="way of the camel" in Japanese). Rakudo also means "paradise". The "raku" from "way of the camel" means "camel", while the "raku" from "paradise" means "fun" or "enjoyable" (or "music").

Incidentally, it also happens to sound similar to "roku" (="six").

There was something strangely familiar about the word "raku" but it took me a moment to make the connection. In Finnish, "raakku" is a common name for the mollusc species Margaritifera margaritifera, better known as the… freshwater pearl mussel! [1] I'm really not sure if this is an amazing coincidence or yet another layer of linguistic brilliance.

[1] https://en.wikipedia.org/wiki/Freshwater_pearl_mussel

Oh wow, I didn't know that, but I know that there is/was a band called "Raakku ja helmet". I always thought "Raakku" was a humorous nickname of the singer, because "raakkua" means "to cry like a crow", i.e. not so well. But "raakku" meaning "a mussel" brings a whole new level of meaning: "Mussel and the Pearls".

This is exactly the type of linguistic naming shenanigans I'd expect from the Perl community.

It is also a type of Japanese pottery. "Raku pottery is "imperfect but sophisticated", so that's a fit :)" https://colabti.org/irclogger/irclogger_log/perl6?date=2018-...

That description also fits a camel.

A camel strikes me as unsophisticated yet perfect.

If a camel strikes you it is indeed not sophisticated.

I understand that impression but I think it requires a different point of view. They are highly adapted in multiple quite complex ways. It's possible we're using divergent definitions of "sophisticated". I was using the one that means complex, developed, and refined for an environment rather than the definition of being tasteful, intellectually pleasing, and socially experienced.

That applies to every living thing ever, though. You're not focusing on the camel at all, or elevating it, unlike joshred's formulation.

Not everything that ever lived is as adapted as the camel and not in as many ways. it has huge fat stores so it can go a long time between meals. It can go a long time without even drinking. It has for thick enough it won't sunburn but thin enough it won't overheat easily. They have a third, translucent eyelid that opens to the side like something you might see on a reptile, but they still have the two main lashed eyelids like most mammals. They have a long, strong swatting tail. Their feet, unlike a horse or goat, are not hooved. They have a split foot with webbing in the middle that resists sinking in sand or soft soil. They're able to drink brackish or even salt water. They can eat stone fruits like dates with the stone. They'll eat cactus with the spines because their mouths are so tough. They eat fish, seeds, grains, and all sorts of things. They can eat foods far too salty for other animals and will even eat bones. Arabian camels will travel tens of kilometers a day in the wild to forage, in conditions many animals couldn't even survive, but can go two weeks between meals when they must.

Saying they are no more complex and adapted than any other organism sells them far short. Yet they're more stubborn than a mule, somewhat slower than a horse, they smell worse than either, and they'll spit on a person like a llama. They've been known to bite. Their shape is not is amenable to riding although they are used as mounts. So there are things one might really want to change before spending a lot of time with one.

What's surprising is that there is evidence that they originally evolved to deal with the snows of the arctic.

So those feet that are great on sand were made for walking on snow covered ground.

Likewise food is scarce in both the arctic during the winter and in the desert.

I'll agree that comparing to any other organism is going too far.

But if we focus on vertebrates, they are all so very very complex and adapted. Everything you've listed for a camel is at best a cherry on top. All other vertebrates are within a couple percent, and many of them have feature lists just as long.

So as a Japanese speaker, I don't think I ever would have made the 'raku' == 'rakuda' camel connection.

Also, while 'raku' is the reading for 楽, which connotes easy, simple and other good things, it is also the reading for a bunch of other characters--namely, 落, which means or carries the connotation of falling, declining or otherwise missing the mark.

When I see the 'raku' transliteration in the context of Perl, I think of 落. Not sure if that says something about my subconscious perception of Perl or not, but I can't help but think 'Raku' is a bad choice for the name of a language mired in indecision and falling from public favor.

On another note, I find the inclination of tech projects towards poorly translated Japanese words amusing. It nicely compliments the phenomena you see in the use of random English words for the naming of Japanese cars, condo buildings, and other 'prestigious' products. So if you find that ridiculous, you should find these 'Japanese' technology names ridiculous as well.

Raku isnt falling from public favor, it hasn't made it yet. It's an entirely different language to Perl 5. Like the difference between C and C# or Java.

Yea, sorry I'm not super familiar with the project, but that is the general vibe I get about Perl.

Interestingly enough 落(raku) also has the connotation of failure or missing the target, so not very auspicious in the context of a new language either!

> that is the general vibe I get about Perl.

Perl <=5 did make it, it was quite big in the 90s and early 2000s.

Raku means happy, fun or relaxed: https://jisho.org/word/楽

Rakudo means paradise: https://jisho.org/word/楽土

Rakuda is a camel: https://jisho.org/word/駱駝

And back when we had to read books to learn a language, the definitive guide on Perl was called "the camel book." https://en.wikipedia.org/wiki/Programming_Perl

I'm curious, how do you learn languages now?

I read a blog post with the basics, then Google everything else as I need it.

I think explains a lot of the polarised reactions people have towards Perl. It's trivial to understand the difference between the scalar var $foo and the array var $foo[0] if someone explains it to you or you read it; but if you're trying to Google-as-you-go, you don't even know what to search for. Those in the former group are more likely to find Perl delightful, while to the latter it's just frustrating.

> It's trivial to understand the difference between the scalar var $foo and the array var $foo[0] if someone explains it to you or you read it;

I don't Perl much, but aren't those both scalars and @foo is an array variable. $foo[0] would be a scalar that is the first element of @foo, right?

Yes, indeed — I should have said "scalar element of the array var..." or something.

Interesting. A good book is very efficient at teaching you how to think in that particular language, rather than translating the ideas you have in another language into the new language. How do you learn that with your method? It sounds to me that it would require a long time programming in the new language to come to the same realisations by yourself.

I've been developing software for more than ten years and it is rare now that I encounter anything genuinely new "idea wise" in a programming language.

The main questions I have when doing something in an unfamiliar language are now:

1. What is the syntax for X

2. Can it do Y

3. Is there a library/builtin for Z

For anything else, I've probably been there, done that, got the t-shirt.

I remember using some books to get a structured introduction when I started out many years ago though.

Nowadays I'll probably just open whatever existing code there is, go "ah, so it's like that", and hack away with the help of Google.

The stuff that takes actual learning tend to be major frameworks for me, not so much whatever programming language is used.

This is how to learn to mimic a new language and avoid actually learning it. It’s the difference between carrying around a French phrase book and being able to converse like a native.

Yeah, I don't think that anyone learning Raku that way would realize that the {} in the following is actually a lambda.

    for @a { .say }
So this works in basically the same way:

    my $lambda = { .say }

    @a.map( $lambda );
Or that the pointy block syntax …

    for @a -> $item { say $item }
… works on every keyword of the form `KEYWORD (CONDITION) {BLOCK}`.

    if $a.method() -> $result { say $result }
The pointy block is of course also a lambda.

    my $lambda = -> $result { say $result }

Raku is a much more consistent language than beginners expect. The above is just one example of this.

Because it is so consistent; once you learn something in one place, you can use that knowledge everywhere in the language.

But first you have to realize that is even a possibility.

It would take a long time to come to that conclusion if you write Raku by copy-pasting code.

That is because very few languages are as strangely consistent as Raku.

> Raku appears to be from Rakudo, the Perl 6 compiler, which is a shortened form of rakuda-dou (="way of the camel" in Japanese). Rakudo also means "paradise". The "raku" from "way of the camel" means "camel", while the "raku" from "paradise" means "fun" or "enjoyable" (or "music").

One of the worst problems for adoption of perl6 has been always overthinking. "Hey, look at my cool name" has never convinced anybody to use a computer language. Too many names.

Raku is a good name indeed. Like a promise of prune and simplify all the former zoo of names that could finally allow the people to focuse in the program

>One of the worst problems for adoption of perl6 has been always overthinking. "Hey, look at my cool name" has never convinced anybody to use a computer language. Too many names.

You're overthinking it. I don't think those who came up with the names did so to, or cared to, convince people to use the language with them...

> I don't think those who came up with the names did so to, or cared to, convince people to use the language with them

Mission acomplished then, if we take a look to the low interest in people to massively adopt the language since it was released in 2015

>Mission accomplished then, if we take a look to the low interest in people to massively adopt the language since it was released in 2015

Yeah, as if the name is what caused the non-adoption of a 20 years late replacement for a language that had already fallen out of fashion with developers (and with many growing pains in the compiler and tooling to boot).

If anything, they used the "Perl 6" for most of the time, which renders the argument even more moot...

I want to know who taught you math.

Because 2015 - 2000 does not equal 20.

The project started in 2000.


It would have been a much worse language if it had been released even a few months earlier. (That was before the GLR landed.)


Also just about every time a new feature was added in the first few years the existing features were redesigned so that everything was consistent.

So despite having many features from many languages, it feels like all of those features belonged together.

Because of the time taken back then, it is actually really easy to add new features to the language now. (Try adding first-class regexes to any other existing language.)

For example, all of the normal operators are just subroutines with a special name. Which means you can create a new operator that works exactly like a built-in operator by giving it a similar special name. (From a certain viewpoint, Raku doesn't have built-in operators.)

Also regexes (which have been redesigned to be easier to read) and string literals are actually Domain Specific Languages in Raku. Which means you can also add your own similar feature if you felt so inclined.


I like to think of it this way:

A language like Python is a good toolbox.

Raku is also like a good toolbox, except it is also a fully decked out machine shop for creating new tools that no one has thought of yet.

Everyone who has worked in a machine shop knows it takes a few years to get one setup just-right.


Also there is a saying:

It can be good, fast, or cheap. Pick at most two.

Raku was created entirely by volunteers, so by definition it has to be cheap.

Which means there was only ever a choice between fast or good.

I'm glad the choice was to make it good rather than fast.

(Especially since the whole reason to create it was to make something that was more good than Perl was at the time.)

Everything counts. And don't make me talk about camelia.

>Everything counts

Not everything counts equally. If something affects the adoption by 1M users, and another is only a concern for 100 weirdos, the second is not exactly a major issue to focus on...

> If something affects the adoption by 1M users, and another is only a concern for 100 weirdos, the second is not exactly a major issue to focus on...

noun: weirdo;

1) a person whose dress or behaviour seems strange or eccentric.

Yep, weirdos will never ever have any influence on Perl development or Perl community.


He has long hair now, which is often under a cowboy hat. He of course still wears hawaiian shirts.

Meanwhile, in hebrew, it means spoiled or decayed. :)

That would be Rakuv רקוב, just Raku doesn't have any meaning in Hebrew. It does sound similar when pronounced though.

(Hebrew word formation is from 3-consonant roots, not concatenation, so removing a letter doesn't give a related word. It's either an invalid word or a different root with 3rd voiceless consonant רקוא which is a not a root / רקוע Raku'a "flattened" but that doesn't sounds quite differently.)

It's a pretty good name I think!

Naming matters. Nim changing from "Nimrod" matters. Cockroachdb's name is offputting. Perl 6's name has caused endless confusion and by itself sabotaged both Perl 5 and Perl 6. Perl 6 has interesting ideas but I don't even want to touch it because its naming issue is so toxic. I'm glad they're going to rename it.

“Nimrod” is a funny case. In the Bible, Nimrod is a king and a mighty hunter. In Looney Toons, Elmer Fudd, a decidedly not-mighty hunter, is sarcastically dubbed “Nimrod”, and so the connotation is reversed for those of us who are first exposed to the name as a sarcastic jibe from Bugs Bunny rather than the name of a Biblical figure.

Agree. To name another example, I personally can't take seriously anything named 'webinar'.

Webinar is similar in spanish to the word huevina that means "egg beaters" (a replacement cheap and second quality). It sounds also like "web-vaina" (a vaina is "something" and specially used when something annoying happens) and has common roots with words like "huevín" (little testicle) and "huevada" (something irrelevant, lacking of any real interest and a total lose of time).

Definitely looks like something created to be dismissed. I can't thing in a worst 'hype' word for replace (without any real need or reason) the perfectly neutral and good old term 'videoconference'. Webinar is the kind of term that Ned Flanders would use.

>Agree. To name another example, I personally can't take seriously anything named 'webinar'

Seeing that webinars have caught on like wildfire, become a multi-billion dollar business, and forced all kinds of eLearning and online platforms to say they offer the ability to produce/share "webinars", I'd say this is rather a counter-example.

I.e. more like "A few might find X or Y name off-putting, some outliers might even come with contrived meanings in unrelated not-exactly homonyms in different languages that supposedly would make a name unsuitable, but in most cases nobody really cares".

I agree with you and the GP.

The execution, the thing, the multibillion dollar industry, are excellent, and the world would be worse for their nonexistence.

The naming, on the other hand, is indeed a disaster. I too can't take it seriously, although I can't quite put my finger on why as well as the GP can. To me it just sounds like the "lite" version of something, but to the extreme where it might as well be the toy version.

Yet another case of buzzword intolerance, it would seem.

Is there a TLDR on what's wrong with the name "Perl 6" for those of us who have zero context?

It was not a version upgrade from Perl5, but instead practically a new language with some similar design principles. So the name was both holding Raku back by associating it with the warts of Perl5, and also holding Perl5 back because people assumed "Perl 6 was the upgraded version so why use the old one". People have been talking for a long long time that the language is different enough to deserve a different name, and things finally seem to have come to a head recently. As a Perl 5 fan and an early ~Perl 6~Raku enthusiast, I'm happy about this change, though it's almost certainly coming too late. Better late than never, I guess.

I believe the issue was that Perl 6 had too many changes that made it hard to convert apps from earlier version.

That created some kind of limbo where people weren't sure if they should use perl 5 or perl 6 (”why develop in perl 5, when it is probably a dead end and perl 6 is the future” and at the same time "why should I convert to perl 6, what if it will be a failure and I wasted my time?")

By renaming it, it revives Perl 5 so developent can continue, and at the same time Perl 6 is presented as a new language, now whichever wins will be based on its merit.

Also, importantly, reflecting that they are in no more competition than Perl and Ruby are.

The sibling comments aren't wrong. However, Perl 6 was originally intended to be the next version of Perl. For a long time it was vapourware, however, and development restarted on Perl 5.

When Perl 6 finally arrived, it was too much of a step change from Perl 5 to convince many people (myself included). Meanwhile, Perl 5 had continued to develop and was, in no way, in need of a replacement.

Perl 6 sounds like a successor of Perl 5 but in reality it is a totally new language. Many long time Perl 5 users think a new name for a new language would have been better.

The name Perl 6 was damaging to the popularity of Perl because beginners were confused whether they should learn Perl 5 or Perl 6. The same confusion existed in Python: Python 2 vs. Python 3 but the Python Wiki was always very clear. Until a certain point, it recommended Python 2 and after Python 3 became very popular, it recommended Python 3. That sort of clarity was missing in Perl. Due to the number of new programmers learning Perl decreased rapidly and finally Python overtook in popularity.

Thid said, Python 2 vs 3 did not matter for a beginner. Beside print they would not see a difference.

I started to use Python when 3 was taking off. Did some code on 2 for a few months, then just swapped the interpreter without any modification of the code (beside print).

For advanced devs the story may be different.

>Naming matters

Not that much.

>Nim changing from "Nimrod" matters


>Cockroachdb's name is offputting.

Not enough to matter. They still raised over $60 million in funding...

Many people have internalized Marketing/SEO/enterprise-pointy-hair-boss thinking about "what matters", but in the grand scheme of things, naming is not really that relevant...

To someone versed in both languages, no. Otherwise, the name giving official credence to assumptions that no longer hold is damaging to both.

Kudos for making this change! This is what the folks at Microsoft should have done when ASP became ASP.NET and ASP.NET became ASP.NET Core. I know... keeping the root of the name the same makes management think the technology is fundamentally the same (and, therefore, cheaper) but the SEO confusion trying to find the right version of an answer is a PITA.

Secondarily, while Perl has never appealed to me I am more likely to admit I'm checking out Raku because the chances that someone will ask me to look at and debug their cousin's friend's manager's Perl 3 CGI app is considerably reduced.

> Kudos for making this change!

Rakudos, even!

I'm amazed that Perl is still around. I personally find it the least readable language that I've ever used, and that includes a lot of languages. But some people really seem to love it, for reasons a bit beyond me.

How familiar are you with Perl, and how much have you used it?

Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.

Some of them might have glanced at some Perl code and saw a dense regex and dismissed it as "line noise". Well, yeah, if you don't know regexes you would be forgiven for thinking it was line noise, but if you did know regexes it should look no more like line noise than a similarly dense regex in any other language.

For a long time now, Perl has allowed regexes to be commented. Commenting dense regexes and splitting them up in to short regexes assigned to judiciously named variables is just good style in any language, and has been the norm in Perl for a long time. Furthermore, modern Perl style guidelines advise code to be written with verbose, English words instead of ancient Perl one-character special variable names.

So setting aside both dense, uncommented regexes and ancient single-letter special variable names, both of which have been recognized as poor style in Perl for decades now, I'm really not sure what the complaints about Perl readability are about. To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.

If you include non-mainstream languages, some languages which have a lot of fans here on HN are arguably a lot less readable than Perl to someone only familiar with traditional Algol-style languages. In particular, I'm thinking of Forth and Haskell. Yet you rarely hear complaints on here about their readability.

>How familiar are you with Perl, and how much have you used it?

It's what my company's entire code base is written in. So every hour of every work day for the past 6 months.

>To me it looks really no uglier than any other mainstream language, and one could easily make the argument that any other mainstream language you care to name is uglier in some of its own ways.

It's no one thing, but a bunch of little things that compound on top of each other. Until you get something like this:

while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

Mostly though it's how it's used. It can technically do anything, so a lot of the times it is asked to do everything. Until one day you wake up to find you have hundreds of perl files, all tens of thousands of lines long, that all interconnect in an insane Object Oriented hierarchy soup stretching across every conceivable programming space - from database control to money processing to security to web site design.

I've worked on large 20 year old Java and C applications (OLTP and batch processes) and I can assure you that they can be as ugly as any old Perl code you have dealt with.

Saying that I see absolutely nothing wrong with that perl code you are highlighting as being obtuse or ugly. Anyone who understands Perl should not have an issue with that line. It is clear and concise.

Well, the "foo && bar" is a bit of a bashism, idiomatic perl would do "bar if foo" or similar.

And a C-ism, and a C++-ism, and a Java-ism, and probably at least one other I'm not thinking of at the moment.

There are a variety of things that Perl programmers would consider idiomatic (depending, I would say, on the background of the Perl programmer). Using something like (foo && bar) in this manner is actually quite common in some Perl code bases (although, I suspect it is more commonly used where there are multiple conditions that are chained -- Damian Conway's "Perl Best Practices" book has some examples of those).

In the example given, I suspect the author of that code did it that way to reduce the length and put it on one line. I understand the desire for concise code, but if it were me, I would spread it out more to make it easier to read (mostly, I just wouldn't put it all on one line). I like having concise code also, but there is a fairly definite line that I try not to cross. If I have to work hard at all to keep track of the pieces, it's time to either add some more whitespace (horizontally or vertically, or sometimes both), change some of the constructs, or add some temporary variables to make the intent clear.

I am the person most likely to have to deal with the code a year later, so like many others, I try to not confuse my future self.

> while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

That's a business culture thing. If you set the expectation, that it's okay to do that, people might do that. If you set the expectation that it's not okay, people shouldn't.

The equivalent C and Python are likely just as ugly (given that the equivalent python might be using a far too complex range statement or put it on a single line using : and ;, which is possible...).

That said, as bad code goes, that's not really that bad. The only non-standard things are <> and $_, and if you don't know what those are, you really haven't done the minimum of learning about the language (<> might be somewhat exotic in that form depending on the codebase, but $_ is not something you can get way with not knowing about). In all, the major problem with it is that it's not commented and uses poor variable names, which is something every language needs to deal with. I would write it like so if I wanted it on a single line (but I would probably use 2-3 lines):

    # Report each duplicated line once
    my (%lineseen,@linedups); # This was required in yours too right? I assume you're using strict...
    while (<>) { (++$lineseen{$_}==2) && push(@linedups, $_); };
But I would likely opt for the following if doing it myself:

    # Report duplicate lines once
    my %lineseen;
    my @linedups = grep { ++$lineseen{$_}==2 } (<>);
Assuming I was using <>, which I generally don't since File::Slurp is usually available and clearer.

There's always <STDIN> if <> is too cryptic. I think what most fail to grok, if they've only glanced at Perl, is context. Above all Perl is a context-based language. It's the opposite of Python's spell-everything-out approach but just as valid. Perl also excels at whipupitude.

Except that <> isn't just <STDIN>, it reads from each line of each file specified as an argument on the command line or STDIN if no files were specified. This dual use (and magical-ness) is why I shy away from it in actual programs (but it is useful for one liners, which is why it does this), as it can be confusing.

Some people will look at this as evidence that Perl should be relegated to one-liners, but I find immense usefulness in combining my more engineered aspects with one-liners, and providing myself with a "project evaluator". What I do is create a simple bash script which just calls perl and sets the library include path to the project lib, includes a few useful things to always have (Path::Tiny, Try::Tiny, Data::Dumper, etc), and passed the rest of the args to Perl. Using DBIx::Class for SQL manipulation and/or using complex API client libraries I've written combined with the abilities of perl to do things easily as a one-liner is amazing.

<> is actually <ARGV>. And actually the least cryptic spelling IMO is "readline(*ARGV)" or just bare readline, which still compiles to the same opcodes. Sure, <> is more common, but it's easier to find what readline and ARGV mean.

File::Slurp is broken AF though, and obsoleted by File::Slurper since the original can't be fixed without breaking accidentally working code in the wild.

Still mostly fine so long as you know you're only dealing with 7-bit ASCII, IIRC, but Caveat Emptor.

Ah, well I actually use Path::Tony's slurp functionality mostly, depending on if it's already available in the project (which it is in any I set up).

It's easier to just say File::Slurp in mixed company so people immediately know what it is if they look it up, rather than them be confronted with a grab-bag of functions.

File::Slurper is just as immediately obvious, and happens to not be fundamentally misdesigned :) Path::Tiny is also great.

Huh, I worked at a company that wrote 1.5 million lines of perl together, and we never ended up with those problems. Maybe you picked the wrong co-workers? You can screw up in any language.

Yeah ... most of my 2-company-ago's software stack was written in Perl. Worked very well.

The specific example cited

while(<>){ $h{$_}++ && ... }

is quite understandable to anyone who has used Perl for more than a few weeks. Its a common pattern. Complaining about this, which is, for the uninitiated, looping over reading each line from STDIN until EOF, incrementing a hash variable indexed by each line, etc.

This is a very common pattern in perl. Draw your own conclusion as to whether complaining about idiomatic language from a "skilled practitioner" is something one should take without a grain or two of salt.

And of course, being Perl, there are many ... many ... ways to accomplish the same task. Leveraging CPAN modules. I'd leave discovering some of the as an exercise for the reader.

I have a decent amount of experience with Perl 5 and one of Perl's greatest features is also sometimes it's greatest liability, versatility. It's permissiveness tends to facilitate poor coding styles and methods which is why there's alot of bad Perl out there. Plus Perl 5 is just different for lack of a better term. If your proficient newer languages, Perl 5 and the Perl way of doing things probably seems a little strange.

It's different from the newer languages, it's different from the older languages, it's it's own thing. I find it really beautiful for that reason.

Who knew you could do that in a programming language? Not sure I would have ever thought to try.

I even love the above sample while loop, you can tell the person who posted it is good because they can't create too heinous an example. The <> and $_ provide what I think of as visual anchors that describe a path for the data to follow. Obviously some style minded author could do it better, but it's not bad. The real line noise is from the one-liners for systems tasks I think.

I totally agree, I didn't mean what I said in a negative way at all. That's how I got into Perl. What made it cool to me was just how different it was. It's experimental, esoteric and functional all at the same time depending on how you use it.

Seriously...? I last worked with Perl in college (more than a decade ago) and thats perfectly understandable to me. There is nothing un-readable about that code as long as you understand Perl conventions. The more important part regarding code quality was whether that piece of code was encapsulated into an independent function or a snippet of a wall of text.

You should see C++ Templates! Even the idiomatic examples in cppreference.com will blow up your head and require multiple re-reads.

> while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };

We use Perl::Critic [0] to deal with issues like that. It has enabled us to develop a very consistent style, and helps new devs adopt to it quite quickly.

[0] https://metacpan.org/pod/Perl::Critic

Note that:

    while (<>) { ($h{$_}++ == 1) && push (@outputarray, $_); };
Would be written as the following in Raku:

    my @output-array = lines.unique;

Actually, since the Perl 5 example doesn't chomp (remove newlines), the Raku version would need to be:

    my @output-array = lines(:!chomp).unique;
where the `:!chomp` is a named parameter representing a `False` value for the named parameter `chomp`. AKA, `chomp => False`.

'x' is an operator...

> Most of the anti-Perl comments I've heard have been from people who really didn't know it very well, if at all.

Indeed, I hope this thread gets picked up by http://n-gate.com/

You are violating the prime directive.


Even if you never want to write any Perl code, I definitely recommend checking out some of the features of Raku. As someone who is interested in language design but never has (or likely will) use Perl for a project, I still found reading about Raku's feature set super interesting. Here's a whimsical slide deck that introduces a lot of the most interesting features: [0]. Even if you find yourself shaking your head at all the craziness, you at least have to admire Raku's success at fulfilling its goals of being a post-modern language optimized for fun (-Ofun).

[0] http://tpm2016.zoffix.com/#/

I love Perl - the syntax, community, Larry Wall's writings and The Monastery. Occupationally I'm forced to write Ruby for a living these days but Perl's influence is there and enhances my appreciation or Ruby. I came into programming after reading in the Dreaweaver Bible that you could extend the search facility with regular expressions. Jeffrey Friedl's monumental Mastering Regular Expressions was listed for further reference and I was hooked. Perl was the natural language to learn if you were inspired by regexen and wanted to create dynamic websites back in the early 2000s so I sought-out Larry Wall's Programming Perl. That book is such a joy to read. I still dip into it today just for the quality of the writing ... and a little nostalgia.

Take time to really grok Perl and you may find the soundbite swipes at Perl don't make sense any longer.

Just because you can't read it, is not a good reason to hate it. But, as Larry says, "It is better to be hated by those who don't know you, than by those who do"

I find programming perl fun inversely to program size and proportionally to the need to slice and dice text. I didn't learn perl until the perl 5 era, but from what I can tell, I would've been as satisfied with perl 4, before they bolted on OO and tried to expand the applicable problem domain of the language. I mostly just use it as a super-charged awk and bash replacement for scripting.

The bolted on OO is really just one new function...bless(). The rest is package namespaces, which are also used for non OO purposes.

I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.

It's not terrible to get working, but for many people a major point of OO is encapsulation and it doesn't work out of the box like that. You have to install another package or use the inside-out object model to prevent direct access to package variables and 'private' functions are usually by naming convention only.

It's just another example of Perl's biggest strength and weakness. Total freedom to build something amazing or shoot yourself in the foot.

Python and Perl have almost exactly the same OO model, yet many people quite like Python's OO, so that can't be it surely...

There's no private data or private methods in Python objects. All the properties are right there for anyone to read, protected only by convention.

JavaScript and Perl have almost exactly the same OO model, yet many people quite like JavaScript's OO, so that can't be it, surely...

There's no private data or private methods in JavaScript objects. All the properties are right there for anyone to read, protected only by convention.

(It's closer than it looks. Perl's "bless" function means almost the same as JavaScript's ".__proto__ =", and inside-out data hiding is possible in JavaScript much the same as Perl, although hardly anyone uses it in either language.)

I'm not necessarily a fan of the OO in those either :)

I try to use OO sparingly when possible, and in Perl that generally just means I've been using a hash and decide it'd be more convenient that it keep some functions to itself rather than pass it around to other functions.

I will say in Perl's defense, the bare implementation really made me appreciate what OO actually is under the hood. I felt like I understood it much better, especially since it takes a mixed approach (rather than 'everything must be an object, including Program.cs' which I never really enjoyed).

It does make it very clear that it is just a data structure (state) associated with a class (behavior).

It's also pretty neat that you can bless any type as an object. People use the hash most often for obvious reasons, but you can use a scalar/string, array, etc, if you wish.

That's fair, though as mentioned, not much different from other scripting languages with OO. The _private convention seems to work ok in practice, if not in theory.

Agreed. Not to mention, from what I understand they just borrowed the OO system from Python, so it shouldn't be that foreign to most people.

I also find it one of the least readable language. Or more precisely, the language that requires the most effort to be made readable. Every language can be made unreadable.

But it is also one of the most writable language. In Perl, for most problems, there is a quick and dirty way of addressing it. It is especially true when it comes to processing text files, the thing that Perl is best known for.

Many languages try to be clean and consistent, it is obviously good for readability, but it means that choices have to be made. Sometimes the best way is the "wrong" way and you have to fight against the language. Perl solved that problem by not having a "wrong" way of doing things, screw cleanliness and consistency.

Also, first class regex are awesome for quick and dirty text processing.

Perl gets a lot of flak, I am no fan of it, but frankly the least readable language IMO is bash.

True, it's very easy to make your code unreadable but other languages have the same drawback too. I would never pick it as the language for team projects. But with Perl you can really pack a lot of power into each line of code. It's hard to beat for scripting.

Seems you've never used shell scripting.

This is great news both for Perl and for Raku. I will probably bother to take a serious look at Raku now, sometime, if anything just for curiosity. Why not before? I have no good answer for that.

But my main worry about it is that I suspect it has brought along with it the community's dysfunctional fascination with over-the-top cleverness and arcane constructs. I'll probably stick with Python and Perl 5 on an as-needed basis, but Raku will be fun to look in on for brain stimulation.

My best case hope is maybe it's clarified some things! Like having an agreed on best practice for how objects are implemented, that would be nice.

I was a Perl dev a long time ago, and I think it made me a stronger coder. I still miss it, and I've not coded Perl for real in a decade.

You're correct about "over-the-top cleverness and arcane constructs" being a problem, but it's also about using code as communication. We code in _languages_, and on one extreme is coding newpaper style - lowest common linguistic denominator. On a good day this is a common, understandable language, and on a bad day it is trying to communicate with stilted baby talk. On the other extreme is dense linguistic cleverness. On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.

As coders we like to talk about using the right tool for the job, but in code we so often assume that the most stilted repetative pattern is always best. It often is - like newspapers, we can't (or shouldn't) assume our audience is well-versed in our material. But we have other constraints as well. I often argue in favor of _skimmability_ over _readability_ of code. That means that the attention/focus of the eye is important. Stilted languages with minimal syntax give you almost no control over that. More fluid languages like Perl give you a lot more flexibility. Learning to use that flexibility to increase clarity...for MOST people, not just for yourself...is a skill that most of us have only limited practice at, and none of us have mastered.

But it's a good idea to work at it, and when done well you communicate MORE with LESS, and it's something people notice because it's not buried in the midst of visual noise.

Interesting perspective there. Worth noting that Larry Wall trained as a linguist and "often compares Perl to a natural language and explains his decisions in Perl's design with linguistic rationale" [0]

> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.

So true. I think Perl golf could be Samuel Beckett.

[0] https://en.wikipedia.org/wiki/Larry_Wall

> On a good day this is nuanced yet clear and informative, on a bad day it is James Joyce.

If Raku's "bad day" is basically like "one of the most influential and important authors of the 20th century" (according to Wikipedia)… well, then, maybe I should check Raku out!

I think the reference was to languages in general. In James Joyce's Ulysses there are four or five chapters which all tell basically the same story, but written in wildly different styles - one like an ancient legend, another a 'stream of consciuosness', and so on.

Perl has pretty much coalesced on Moo(se) for this, though it's not core yet. And yes, Raku has a thorough core object system.

Why not before? Because Perl is you know, dead. Jokes aside, it's a pretty nice language apart from the !$double .@sigils. If I'd switch from Perl 5, I'd probably switch to Ruby, as Perl 6 oops Raku is quite slow.

> ... apart from the !$double .@sigils

In this case, `!$double` isn't a sigil. `!` is just the old prefix operator for negating a value [1]. If you meant to write `$!double`, then it's the twigil [2] for class attributes [3]. Twigils could be considered as secondary sigils but they affect the scoping of a variable. In this instance, `!` is for class attributes and will only be found there.

As for `.@sigils`, I've never seen this syntax. I'm probably out of the loop in this one.

As an aside, sigils are one of Raku's interesting features. They convey information [4] that might not be easy to discern from just looking at the code. What kind of structure is this variable holding? Is it holding an array? A hash? A code object? What's the scope of this variable? Is it class-scoped? Is it dynamically-scoped? Is it a compile-time variable?

> ... Raku is quite slow.

This is a legitimate reason for avoiding the language. However, it's worth pointing out that Raku core developers have made great improvements to the language in the speed department since it was first officially released in 2015. They recognize there's a lot of room for improvement. [5]

[1] https://docs.perl6.org/routine/!

[2] https://docs.perl6.org/language/variables#index-entry-Twigil

[3] https://docs.perl6.org/language/variables#index-entry-$!

[4] https://docs.perl6.org/language/faq#Why_sigils?_Couldn't_you...?

[5] https://docs.perl6.org/language/faq#Is_Perl_6_fast_enough_fo...?

Ok, twigils, whatever. They're next to each other so they're double the crazyness. Like the $#last_index in Perl. In Raku the . and ! are used to designate a private or public variable within a class definition. I got it backwards, which sort of proves the whole point. Push a private array nested into another and you have a bunch of gibberish worse than in Perl, where you'd only prefix it with \. Use an auxilliary variable and it feels too verbose. OTOH @{$hash{array_ref}} dereferentiation in Perl is quite annoying. And no, $hash{array_ref}->@ is definitely not how you fix this mess. I agree that sigils offer some insight into what type of the variable you are looking at.

Great improvements are not enough compared to other languages, even Ruby which is quite slow itself. Have you wrote anything in Node, Dart or Lua? They feel like a F1 car where Raku is an 17th century cart.

You probably mean: `@{ $hash->{array_ref} }` or `@{ $hash(array_ref) }`.

Either way shows exactly what is the structure of `hash`.

%hash is an actual hash with a nested array ref inside. If $hash is a reference to such a hash, yes. Never used the second syntax and I doubt that it works with something other than subroutines, but in that case it's either hash() where hash is an actual sub, or $hash->() where $hash is a subroutine reference. Both return an array refetence.

See? Confusing. That's why people hate Perl. At least I'm glad dereferencing is gone in Raku.

Ruby is also quite slow. The last benchmarks I saw makes it pretty clear Raku has closed the gap with Ruby (at least the mainline C implementation of Ruby) on a lot of fronts, and is likely to be faster for many things in another year or two and the VM gets better at optimization. My google fu isn't up to finding those benchmark results now, but it's no secret that Ruby is pretty sluggish compared to Perl 5.

Here's a great talk from PerlCon.EU 2019 about Raku Performance given by Jonathan Worthington: https://perlcon.eu/talk/80

I sure hope it will be faster because in my own tests it's slower than Tcl. And I've tested at least two releases a year since october 2016 when the stable Rakudo came out.

Ruby 2.5 has a jit which uses the C compiler to generate dynamically linked objects. It looks more like a workaround but it produces fast code. Then there's Jruby, Rubinius, Truffle, mruby. Crystal too, which is a different language but yet similar. No need to learn Go. Just take your Ruby background and pretty much start using it for writing Crystal.

The CRuby 2.6 JIT using gcc or clang improves some benchmarks but makes real applications slower, sadly.

Thankfully JRuby already has a functioning JIT and TruffleRuby is getting very close to a 1.0 release.

How much of a difference is it going to make? I mean nowadays most people are going with python, for better or for worse.

I really wish the Perl 6 -> Raku change could let it catch up with other languages such as Python.

Edit: sorry for the confusion. I meant popularity-wise. I wish the change would clarify to people that Perl 6 and Perl 5 are basically two different languages and people should at least consider Perl 6 as an option when they start a new project.

What do you mean? Perl6/Raku has some great features that make it much better than Python. In addition to no GIL, there's other advantages, like discussed here: https://techbeacon.com/app-dev-testing/why-perl-6-game-thron... and https://www.evanmiller.org/why-im-learning-perl-6.html

The features demonstrated in this talk are worth a watch (or at least a scroll through the slide deck): http://tpm2016.zoffix.com/

Assuming you mean rename the next version of a programming language — I think that’s a horrible idea. The entire point of continuing with the previous name is that eventually the community will move onto the new language. I’m guessing Perl 6 made too many incompatible changes from Perl 5 though I don’t know much about them.

Perl 6 started out as a plan for the next version of Perl.

Over the years (announced in 2000, delivered in 2015) it evolved into a distinct language.

In the meantime, Perl5 suffered from the Osbourne Effect.

Meanwhile a rift developed in the Perl community. Some are for Perl 5 forever. Some are Perl 6 forever. Some Perl 5 people blame Perl 6 for Perl 5's perception as a dead language. Some Perl 6 people blame Perl 5's reputation for being "write only" and "dead" for difficulty getting people to try Perl 6.

IMHO, both sides are correct, both sides over-state their case.

Renaming Perl 6 has been discussed for close to a decade, by people who are Perl 5, Perl 6, and just plain Perl partisans.

It's been a difficult decision. Many people have worked very hard on both projects, and have strong feelings tied up in the issue. Important contributors to the projects have quit as a result the issues.

This isn't a change that was lightly made. It's far bigger than the Python 2 to Python 3 divergence. It's more like moving from C to C#.

I don't understand this comment. What needs to 'catch up'? They are vastly different languages with different philosophies, there's problems better solved in either language.

I meant popularity wise.

This has been a huge deal for the Perl community.

First, it was thought that Perl 6 would be the replacement for Perl 5.

But it was long ago recognized that there was no clear upgrade path from Perl 5 to Perl 6, so it was agreed that Perl 6 was a "sister" language to Perl 5 rather than the successor.

Except that many people expected that Perl 6 would be the replacement, so that stalled many projects. So an "alias" for Perl 6 was created, but that didn't seem to help.

Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

If I had my choice, I'd program in raku because it's a lovely language addressing many pain points (including being one of the few dynamic languages with a working concurrency model). But it's not adopted widely enough yet for that to happen. Time will tell ...

And this might save Raku.

Lisp has a social problem: It's been called Lisp too long. People look at some simplified LISP 1.5-esque thing in a programming languages textbook and see a "pure" language (which isn't so pure compared to Haskell, but the creep of what "functional programming" means is its own post) which is completely useless. They don't see modern Common Lisp with its package management facility and its packages which you can manage which provide actual functionality and its FFI bindings to external libraries and the fact it compiles to optimized machine code... no, they only see some parentheses thing which is interpreted-and-therefore-slow (you know... like Javascript on V8... ) and is too elegantly pure to be bound to the outside world. Meanwhile, all the Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... ) so everyone knows they're completely up to date.

My point is, Perl is a tainted name, because everyone knows Perl is dead and Perl 6 is the Duke Nukem Forever of programming languages. Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.

> Foogols get new names every couple decades (PL/I to Ada to C to C++ to Java to C#... )

+1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?

> +1 for Foogol. Reference to commercially obscure language but annoyingly influencial Algol?

Yes, even though I don't dislike Algol and the Algol syntax style, necessarily, I just wish they'd imported more Lisp influence sooner.

> Calling it Raku is a chance to get what the Perl 6 team actually did out into the world without the stench of death following it.

"Raku" = "cancer" in Polish. Not a lot of Polish enthusiasm forthcoming, I'd imagine.

I'd imagine that chances are high that whatever name you pick for something in one language - there would be another language in this world in which same or similar word means bad/offensive thing.

And not just Polish, most (if not all) Slavic languages. What a perfect name indeed.

No it is not. "Rak" is both cancer and crayfish in Polish.

The social problem of the name is less similar to Lisp than I think you're making it, but I do agree it is probably not a terrible thing in the end and could be considered good. I don't think it's going to be impactful enough to "save" or not save the language (as someone mentioned elsewhere, if you called Betamax by a different name, it's unlikely the ultimate outcome would have changed).

The reason I think it's not related to the Lisp issue is because the relation of Perl 5 and Perl 6 was like an unofficial successor with a compatibility mode, like C and C++, whereas the relations between Lisps that create the social problem you highlight of people not knowing about "Real Lisp" are the relations of very incompatible forks with varied functionality running around calling themselves "Lisps" or "members of the Lisp family" and people confusing that with "Lisp". (There were some "Perl 5/6, C/C++" types of relations in the path to Common Lisp like Flavors/CLOS but no one remembers or cares about those outside of Lisp users...) Another reason is the timing, why the name change now, years later -- it turns out Perl (5) is less dead or possessing a stench of death as you put it than people might want, it's still vigorous in its own rights, and so really it makes most sense to just call the new thing by a new name and not destroy both. (Larry's wineskin comment is nice.) The Python 2/3 situation is a closer analog if we counterfactually imagine Python 3000 came out with the current 3.7 feature set, syntax updates, and backwards incompatibility. Python 2 users (me among them) would still have dragged their feet, since Python 2 would still have been useful, still had its own vigor, the same as presently, but it might have resulted in renaming some later version of Python 3 instead of the current situation of renaming the continuation of Python 2 (Tauthon).

Going back to the lisp issue to further elaborate why I think it's not very related to this one, the languages that called themselves Lisp (not a Lisp, but Lisp or Some Lisp) shared a heritage going back to the original McCarthy Lisp. The merely "a lisp" languages used that for marketing, but were actually called something different (Clojure, Scheme, even Racket which has to further distinguish itself from Scheme). You see the heritage in the actual Lisp 1.5 manual, where one of the earliest examples should quickly dispel any illusions today about "Lisp's" supposed purity when they show the function 'length implemented with a program block and goto. By only modifying the top-level function define format and substituting ADD1 with 1+, the program works to this day in Common Lisp. For members of the lisp family that don't call themselves lisp, you're not going to be able to make such a trivial transformation, because there's no shared code heritage, just a vaguely shared s-exp-ness to the syntax. And right after that the manual describes the "pseudo-function" 'trace, which to this day is lacking in supposedly modern languages or requires a bunch of IDE ceremony to set up. It's present in CL and behaves the same, though. Continuing to call CL as simply Lisp seems pretty well-deserved.

The Lisp social problem then is that people run into members of the vaguely defined lisp family like Scheme (especially with SICP formerly being a common gateway for freshmen or HS students) or Clojure and confuse "a lisp" with "Lisp". They can spread their confusion further by releasing a project/blog like "let's write a lisp interpreter!" that can be understood correctly as "let's make a program that interprets code for a lisp¹" but tends to be misunderstood (sometimes even by the author) as "let's make a program that interprets code for Lisp".

Of course I also think this "social problem" is way overstated, especially these days when it's so trivial to dispel the old myths and when the gateways via Clojure or Racket are actually good in their own right and so don't leave the same impressions of "Lisp's a neat toy" that only seeing SICP Scheme could. But if people keep talking about the problem as if it is big, perhaps it will become self-fulfilling, hence my long comment in disagreement. ;)

¹ aka a member of the lisp family based on my vague membership criteria that probably don't even pass Steele's 3-part acceptance test in https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf that requires as its final step (atanh -2) to return a complex number. (Bonus if the correct complex number.)

>including being one of the few dynamic languages with a working concurrency model...

Elixir is worth a look. It's a pretty productive little language with a great concurrency model.

When someone says they want to work in Perl6/Raku, they likely have vastly different problems than someone using Erlang/Elixer. There is overlap of course (both general purpose), but I can't imagine using Erlang for scripting, while Raku is first class here.

I can't imagine scripting in Erlang. Or rather, I've seen it done and it wouldn't be my first choice.

Elixir, on the other hand, has many nice features for scripting, such as better string handling, process pipe-lining, and an excellent set of first-class generic data structures (beyond just map and list). It also happens to have Erlang's fantastic concurrency model.

As a testament to this statement I wrote a Google maps API scraper to get a list of driving distances from a pair of csv tables - shortname + address and shortnames to and from, in about 1 hour, and the whole thing clocked in at 90 lines of code including about 40 lines of comments.

That seems about right for a competent Python coder. It or Powershell or Linux command line tools would have very little code and be very easy to whip something up. Perl would be great here as well or honestly any dynamic language with great library support.

Elixir still has to borrow arrays from Erlang and it's a pretty ugly implementation at that so no - I would not agree that Elixir has an excellent set of first-class generic data structures.

Neither Elixir or Erlang have real arrays, unless you want to count tuples. That said, I don’t see how that correlates to scripting, the data structures that are first class in Elixir are very ergonomic and certainly flexible enough to tackle pretty much any task you’d use a scripting language for.

I guess it depends on what you're comfortable in? I myself have tons of Elixir scripts that I use to automate much of my life. It's replaced ruby as my go-to for one-off scripts.

I didn't know that Elixir had such a low-threshold for one-off programs.

Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.

Oh man I just love and adore Crystal. I am a long time rubyist and I have to say they just nailed it with Crystal. I just wish I had more opportunity to use it professionally!

It must be time to take my Ruby skills and go and learn this. Is it really as easy as it sounds like it should be for a lazy, dynamic-typing sort of Ruby dev to pick up?

If you have never worked with a strongly typed language before there might be some getting used to that, but any pain is well worth it. Catching all your mistakes at compile time and not at runtime is so amazing. Oh and it’s literally 100x faster than Ruby in some cases.

> Catching all your mistakes at compile time and not at runtime is so amazing

It would be, but IME Crystal, or statically typed programming languages that don't have a type system at least as powerful as Haskells in general, don't get anywhere remotely close to that, and the overhead added to get what they do give is of dubious net benefit outside of large projects.

And even with Haskell, while you can express a much richer set of constraints in types, there's also more space for bugs in the type level programming.

I don't get it. How many types do I need, before the kind of data I am talking about becomes better represented by an object comprised of smaller pieces?

Why would I want to spend my time "type level programming"?

Maybe I don't understand what's meant by a type. Is it on the level of string/double/int, or is it expected to cover more (string with a well formatted ISO 8601 datetime, etc)? What is accomplished that couldn't be done in vanilla Ruby with an object representing a more complex datatype with its own getters/setters to cover validation?

Every mistake? Wow. I rarely make that kind of mistake, I usually screw up the logic.

Crystal is wonderful for one-off programs in my experience.

Elixir had a long startup time for one-off scripts in my experience, but Elixir’s syntax is still one of my favorites for scripting.

Is a 100ms startup time really a big deal for something that is either going to be manually triggered or cronjobbed and expected to take on the order of minutes?

Those sorts of startup times discourage writing command-line tools (e.g. composable text processing things one might join with pipes).

Ruby scripting has occupied the sysadmin space for over a decade yet on my 2013 Macbook Pro the latest Ruby 2.6.5 takes around 250ms to start. That's a mere 1/4 of a second. Sure, Python, Perl and PHP have shorter startup times but surely this is a non-problem?

No, things like sort, grep, uniq, cut, wc, cat, awk, sed, tr, etc etc. You wouldn't want them to take 1/4 second to start up.

Crystal's startup time is not great though. 700ms vs 100ms for ruby.

Compared with

   time crystal eval <<<"puts 1"
   time ruby <<<"puts 1"

You know that you are timing the compiler and not the compiled program here?

Rather try "echo 'puts 1' > puts.cr && crystal build puts.cr && time ./puts"

BTW, you can dramatically decrease the cold startup times of ruby if you call it with the options '--disable-gems --disable-rubyopt' if that's an option to you. For many scripts it certainly is.

But even on a 8 years old machine with spinning rust, after the ruby stuff is cached in the OS filesystem cache, my startup time are smaller than 10ms.

Elixir/Erlang isn't a general purpose language. You pointed-out one reason why - scripting. Computation is another area where the language is deficient. I'd go so far as to say Elixir's failure to challenge mainstream languages for mindshare is down to to it occupying a niche - lightweight concurrency and distributed systems.

Their point was that elixir is a good language for scripting. I'm not sure if this is true but I don't see any reason it couldn't be. I don't think "distributed systems" are niche... I think every web application I've worked on fits that description, which is basically my whole career at all different kinds of companies.

I'm trying to understand, what kind of scripting requires first-class concurrency that isn't fulfilled by say Python?

For concurrency I think Raku has slightly more developed async support than Python, but the bigger advantage, I think, is in parallelism where, aside from the CPython GIL limiting practical parallelism in the main implementation (which is a big deal), Python as a language lacks the parallel iterables produced by the hyper (parallel but constrained to return in order) and race (parallel and not constrained in order) methods on the Iterable role in Raku, or anything like Raku’s hyperoperators that are semantically concurrent and parallelizable at the discretion of the optimizer. (Come to think of it, while also parallel, all those are also high-level concurrency constructs that Python lacks equivalents to.)

Python as a language can support parallelism via threads, and CPython as an implementation can via multiprocessing, but those are both very low level abstractions; Raku has higher level abstractions which allow much more succinct expression of parallel operations.

Sounds like multiprocessing.Pool.imap and imap_unordered? When dealing with io you also have async/await equivalent iterators like asyncio.as_completed().

Raku has `await` but it doesn't need `async`.

    sub foo ( Int \n where 1..100 ) {
      #  ___ start is a prefix operator that creates a Promise
      # V
      start { sleep n.rand; (1..n).pick }

    my $result = foo(10);

    say $result.status; # Planned

    say await $result; # 6 (after a delay)

    # this is nearly identical to foo above
    sub bar ( Int \n where 1..100 ) {
      Promise.in( n.rand ).then({ (1..n).pick })
(Note that `start` does not need a block unless you are grouping more than one statement as I have above.)

There are combinators like `Promise.allof` and `Promise.anyof`.

You usually don't need to use `Promise.allof`, because you can use `await` on a list.

    my @promises = Promise.in(1.rand) xx 10;

    my @results = await @promises;
(Note that the left side of `xx` is _thunky_ so there are ten different Promises with ten different random wait times.)


You should see the `react`/`supply` and `whenever` feature.

I am not that familiar with Python, but the GIL has long prevented any real in-process concurrency. Perl has concurrency but it's complex, heavy, and poorly supported. Raku's approach to this is built to avoid all these problems (like Elixir).

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity or readability of Python: https://github.com/jreese/aiomultiprocess

Very true, I had not even thought about the multiprocessing package; it's sometimes not as convenient as multithreading but it'll get those other cores working.

Indeed and as a Perl developer I make use of XS/external libraries, cooperative multitasking (event loops/promises), and forking to cover these use cases. It doesn't preclude wanting the additional option to take advantage of threads in a useful way, since they do exist.

It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.

Can you expand a bit on that? I'm not familiar with the issue you're describing.

Why should first-class concurrency needs be required to script in Elixir? This question seems to imply that Python is somehow a default language and special requirements must be needed to justify writing in something else. Elixir is general-use and pleasant to write scripts in so seems reasonable to me for someone to do so if that's their thing.

Ovid2 said Perl6 has a good concurrency model

lliamander replied that Elixir does too and it's worth a look

To that, 7thaccount replied that Perl6 and Elixir fill different niches.

So far, it seems Perl6 fills a niche that requires scripting and first-class concurrency. My question then is: what is this niche that requires very solid concurrency but also scripting. In other words, what does Perl6 have in terms of concurrency that Python does not (given they are both scripting languages)?

A fair question.

I don't know of many instances where scripting and concurrency would be needed in the same application. But if you wanted to use single language both for scripting tasks and applications that require concurrency, then Raku or Elixir would work.

One instance I can actually think of, that would be specific to Erlang/Elixir, is if you have a long running service that you sometimes run batch jobs against (like importing data from a CSV). An Elixir script can hook directly into an Elixir/Erlang service and interact with it using message passing. It's a heck of a lot simpler than RMI, and avoids the need to expose new HTTP endpoints specifically for such tasks.

Is that like the relationship between C# and PowerShell?

I think so, at least in some ways. I've shipped a project using PowerShell to script Windows Server/Hyper-V, and it was a pretty pleasant experience. Having a scripting language that not only does typical scripting stuff (wrangling text, etc.) and understands your application's objects is excellent.

Some differences:

* You can actually write your whole application in Elixir, whereas I could not see doing that with PowerShell

* In Erlang/Elixir, instead of objects you have processes. Think of your application as a microservice architecture on steroids, using the Erlang RPC protocol as a means for inter-process communication.

Because each process just sends and receives messages, your script can just send messages to any of the processes that make up your application, as if they were your own service. All you have to do is connect to the remote application using the Erlang Distribution Protocol (to connect different runtimes over the network).

I heard so much about the actor model, I should really try it in its intended glory one day.

It's a trip, and it took me a little while to wrap my head around. However, I now much prefer it to working with other concurrency abstractions (such as callbacks).

Jonathan Worthington (Rakudo Compiler Architect). Keynote: Perl 6 Concurrency


Does Python 3 have any operators that transform ordinary method calls into concurrent method calls? Perl 6/Raku does.

More to the point, does Python 3 have operators that transform sequential operations into operations that are both concurrent and parallelizable, and, in the case of iteration, provide control of parallelism parameters and whether results are constrained to be in-order or not.

To which the answer is “not only does Python not have them, but with the GIL CPython couldn't do much with them even if the language had them.”

Is that a bit like Go's `go` keyword?

edit: that is, as far as I can tell, after a quick Google, it's not too different from Python's Thread object.

The `start` statement prefix operator is a bit like Go's `go` keyword.

(In that when I translate Go into Raku, I usually replace `go` with `start`.)

    my Channel \input .= new;
    my Channel \output .= new;

    start for input -> \message { output.send(message) }

    start for output -> \message { say message }

But what he was really talking about is something more like the following.

    sub foo () {
      sleep 10;

    #                     ___
    #                    V   V
    my $delayed-result = start foo();

    say 'Hello World'; # Hello World

    say $delayed-result.status; # Planned

    say await $delayed-result; # 42

It is, python Threads are system threads.

Which is a similar response to the comments asking "why Perl over Python?" I ask, why not (both)?

Especially since you can use the Inline::Python module.

I'm embarrased to say I write scripts in node :P I used to write scripts in python but I've been writing so much JS that it's just easier for me in node. Plus, node defaults to locally installed deps so I don't have to deal with virutal environments.

Why do you think this is embarrassing? Javascript is great for small scripts. Largr codebases then sure

Well just from experience untangling async calls in python is a nightmare and sometimes hard to reason about. The red/blue function problem is real. Meanwhile dispatching concurrent long-running scripting tasks is basically trivial in elixir (Enum.map over Task.async, then Enum.map over Task.await)

I'm guessing because Python's concurrency relies on the Global Interpreter Lock. Although I think concurrent.futures might address that. Haven't worked with python concurrency libraries in a bit.

as I posted above:

I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?

There is machine learning, which usually calls into numpy or other c extensions With a lot of the data preparation done in python

tldr; Using a scripting language that allows for native threads or has a strong concurrency model builtin to the core would be beneficial for any CPU bound scripting task...


Python's concurrency model is good for waiting on network or disk I/O because of its GIL (Global Interpreter Lock): https://realpython.com/python-gil/#the-impact-on-multi-threa...

If your program is CPU bound the GIL will slow you down. I'm sure since the python ecosystem is quite vast there are ways around the GIL... but then you have to worry about every library you use not supporting "real" multi-threading, or (b)locking for no reason and shitting all over your efforts.

As I've posted above, I'm a bit confused by CPU-bound work being processed in a scripting language. If you're planning on doing intense CPU-bound work, maybe use a lower-level language? I'm not saying abandon Python: you can extend Python with C or just use IPC to transfer data between a Python front-end and a computation back-end.

I have a different perspective.

When I have a bit of Raku code that is too slow I complain (send a bug report) and then someone else figures out why the JIT isn't doing a better job and fixes it.

Then bingo-bango it ends up even faster than using NativeCall to call into the C code.

Of course there may be a delay before someone gets around to figuring it out; so in the meantime, NativeCall is actually very easy to use.


I would like to note that someone wrote Perl6/Raku code and the equivalent C/C++ code. They reported that the Perl6/Raku code was faster. (It was before Raku was brought up as an alias/name.)

I'm fairly sure that the reason the C/C++ code was slower is that it copied strings around rather than using pointers and indexes into other strings like MoarVM does.

At one time it was an obvious dichotomy that you would not use a scripting language for CPU bound work, but these days it is a much more blurry line. Partly because modern efficient languages are becoming ergonomic enough to work well as scripting languages while still giving you very good performance.

I actually love doing CPU bound work in Groovy which is usually described as a scripting language. But it gets converted straight to java byte code which is JIT'd and ends up as machine code. It only takes a few static typed hints here and there and it runs in the same league as C++ implementations. And it gets Java's excellent concurrency support for free.

I totally you feel you, I guess I thought your question was substantially more surface level than it was. My apologies.

I'm personally with you. I also don't tend to think object boxing is really the performance bottleneck for most applications, and if/when it is, likely the other requirements should've already ruled out using one (a scripting language).

It's like writing Nifs for Elixir, yeah sure you _can_, they have their purpose, but you could also just write another application to do that one thing and like you said, use IPC.

So in summary, we agree with each other, here's to:

the right tool for the job!

> the right tool for the job!

Hear, hear!

For that matter, Erlang has been around for like almost 30 years and has had multicore support since 2007, and has always been dynamic.

Erlang is great, and I miss working with it, but I'd never want to write much in the way of 'quick scripts' with it. Something like Ruby feels much more productive for that.

Heh, escript isn't so bad once you get used to it.

Clojure would be a great language for small-ish scripts if it weren't the dog-slow startup times, and has excellent concurrency support.

I hear that GraalVM might fix that but I sadly haven't had a chance to play with that yet.

Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason - standard libraries for file, dir and pathname manipulation written in a concise language. Scripting is a style of coding, not just a means to an end. It is here that dynamic languages excel. Clojure is the leanest of the JVMs but doesn't it still rely on Java for file, dir and pathname manipulation?

> Even if GraalVM fixes startup times aren't JVM languages just too long-winded for scripting? Perl, Python and Ruby dominate the scripting world for a reason

Ruby is a JVM language, in that JRuby is a very complete competitive, current, and widely-used-in-production Ruby implementation.

By JVM languages I really meant those designed originally for the JVM, ie. Java, Clojure, Scala, Kotlin & Groovy.

Even so, Clojure and Groovy aren't particularly long-winded, nor is Scala despite static typing.

You should definitely educate yourself about Groovy. It's my favorite scripting language, particularly because it enables a true scripting style, but actually works well as a full application development language too (though I would always want a backbone of static typed code).

It relies on the implementation of its runtime, JVM, .net, JavaScript, BeamVM etc but uses it's own language for those operations, slurp/barf etc

So as a developer it's all the same until you start leveraging the features of your particular runtime but this does make code sharing viable

There are JVM versions of Python, Ruby and Tcl, so it's not really about the VM itself.

Ya, GraalVM fixes it. But it requires a compile step, so it's not as nice for scripts.

My favourite for scripting right now is Joker: https://github.com/candid82/joker

Joker is a Clojure dialect which is interpreted, thus it starts super fast (but runs slower, but fast enough for scripts). Its design is to be batteries included for all things scripting. So it's just a self contained executable with everything you need for scripting. It's implemented in Go.

I use it wherever I would have used bash or powershell prior.

There is also Babashka: https://github.com/borkdude/babashka which is a similar idea, it's an interpreted dialect of Clojure with fast start times designed for scripting. The difference with Joker is that it is newer and more experimental, and it is implemented in JVM Clojure, compiled with GraalVM and has no Windows support for now.

Anyways, I really recommend the use of Joker. Its awesome for scripting. I just put its binary in all my bin folders and script with it. It's great.

GraalVM does in fact fix that. There's a (new-ish) project called babashka that lets you do some basic scripting for example: https://github.com/borkdude/babashka

Oh certainly. I've done production work with Erlang, and it's great for building systems. I also love the Prolog syntax (I've also since done some side projects in Prolog for great fun).

Why I suggested Elixir is because it has all the strengths of Erlang but is also a better scripting language, and would compete better with Raku on a more equal footing in that respect.

In fact Elixir and Erlang are the only reasonably known dynamic languages that differentiate on concurrency. The rest either do higher order event loop concurrency, which is ok, but not a differentiator, or do worse, shared memory multithreading (threads, coroutines with synchronous channels, mutexes, etc.)

I don't really know what "differentiate" means, but Clojure has support for CSP-channel style with core.async, shared-memory with transactions using atoms/refs, and actor-ish style with the agents.

> I don't really know what "differentiate" means [...]

Probably “set themselves apart from others”.

> Larry has now agreed with the change and Perl 6 will be renamed to "raku" and Perl 5, which has regular, major releases every year, will now be able to simply be "Perl" and be free to continue on its own way.

I hope that doesn't mean that when Perl needs a major number version change again, they'll chose 6. It would be pretty confusing to have 2 Perl 6.

Perl 5 was released in 1994. At this point, the "5" isn't really a version number anymore. It's just part of the name.

If you did a "major version bump" from here, you'd probably have to bring the "5" along for the ride. Like Java version 2, where you had J2EE version <X> for years.

In reality, there probably never will be another major version bump of Perl 5, in the marketing sense. The minor version number is really the major version number now.

Which in turn suggests the Java (and others') solution of dropping the 5 and making the minor version the new major version. Look out for Perl 31.0 soon.

Java even got rid of two numbers:

J2EE 1.4 -> Java EE 5

Both “2” and “1.”.

And as another example, Mac OS X (10), which debuted in 2000, has had every subsequent version continued to be named 10.X. Just this week, macOS 10.15 Catalina was released.

Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.

In communist Russia, minor version always have breaking change

I can say that at least currently, there is no appetite for Perl attempting to "reclaim" the Perl 6 version in the foreseeable future. It would be a disaster in both community relations and marketing. It will either be Perl 7 or Perl 34+.

Perl 2019

This one goes to 11


And we'll keep that name and idea. 5 + 6 = 11, as it should have been

This has the benefit of showing that Perl gets a new version released every year.

I have previously stated that I would like it to be an alias of sorts.

    use v5.30;

    use v2019;
Basically have both of those lines do the same thing.


Perhaps even something like:

    use Perl v2019;
(I actually considered posting a module that would make that work.)

A similar sort of situation happened with PHP which is why there is no PHP 6 -- it jumped straight from PHP 5 to 7.

And same with ECMAScript 3 to 5.

There was an ECMAScript 4, it just wasn't adopted by browsers. (It was semi-adopted for ActionScript 3.)

I thought the relationship went the other way, that AS 3 was going to be standardised as ECMAScript 4? Not that it matters, I’m likely remembering incorrectly!

Standards are a two-way street, and we're probably both right from different points of view. (Especially, because AS 2 also had a number of the features proposed for ES 4, so even if AS 3 was "solely" inspired to be an implementation of the ES 4 standard, ES 4 itself took inspiration from AS 2.)

It's not uncommon to leap frog versions in such cases. PHP went from 5 to 7, for instance.

But that's because PHP6 was dumped after being in development for a while.

This is not entirely unlike that. Somewhere along the way, everybody realized Perl 6 was not the path forward from Perl 5, and so Perl 6 never really took the place of Perl 5, just like PHP6 never took the place of PHP 5. It looks like a pretty similar scenario, if you squint, I think.

It makes little difference for Perl that this experiment in a next generation version of the language is still alive and going its own way. The result is the same...people kept moving forward with version 5, and if it needs a new version, it can't use version 6 because 6 was already used for that other experiment (that failed to take the place of Perl 5).

They didn't "skip" php6.

The primary goal of PHP6 was to implement full unicode support and drop mbstring. However, that took much longer than expected and multiple major features ended up getting backported to 5.3, 5.4 and 5.6; to the point that PHP 7 became the new feature version while PHP6 was worked on. They eventually gave up and PHP7 was released with unicode support built fairly deep, but basic string types and the like still being byte arrays.

PHP7 was PHP6, without the native and full unicode coverage requirement.

"giving up" sounds like "skipping" to me.

Yeah there was also no ecmascript 4, it went from es3 to 5 because 4 was abandoned as too complex.

And Microsoft skipped DirectX 4.0:

"after DirectX 3 was released, Microsoft began developing versions 4 and 5 at the same time. Version 4 was to be a shorter-term release with small features, whereas version 5 would be a more substantial release. The lack of interest from game developers in the features stated for DirectX 4 resulted in it being shelved, and the corpus of documents that already distinguished the two new versions resulted in Microsoft choosing to not re-use version 4 to describe features intended for version 5."


For those that can remember back that far, MacOS also jumped from 5 to 7. (7 was the first version that supported running multiple applications at once.. not counting the MultiFinder hack that came before it by a few years.)

It certainly did not. System 6 (including MultiFinder if you had enough RAM to support it ;) was active for several years in the early 90s before System 7 came out. The label "MacOS", meanwhile, didn't show up until a few years after that.

Doh, yes, system 6 was current for quite a while. I wonder what other thing from that era I confused it with. I swear something around that time skipped a 6.

Solaris skipped from 2.6 to 7. UnixWare also jumped from 2.x to 7. HP/UX skippped from 3.x to 6.x. In perhaps the strangest version jump of all time, Darwin jumped from 1.4.1 to 5.1, as part of Mac OS X 10.1.1.

It seems Unix vendors really don't like low version numbers. Of course, Windows famously jumped from 3.x to 95, so it's not like they're any better.

Windows 95 was Windows 4.0. There are several parts of Windows 95 that even indicated this in a user-visible way.

Microsoft was surprisingly good at not skipping numbers, until the jump from Windows 8.1 to Windows 10, which also lead to the NT kernel jumping from 6.x to 10.

Microsoft had to skip 9 because programmers are lazy.

A lot of programs refused to work if there was a `9` in the version name.

That was of course because those programs needed something newer than Windows 95 or Windows 98. So they just did a string search for `9` in the version name.

There may be a few programs that wouldn't work on `8.9` or `10.9` if they were released for the same reason.

System 7 skipped from 7.1 straight to 7.5. (And the pattern was repeated with 8.1 and 8.5.)

That would be an issue, but I don't think there is an appetite for a new major version of Perl at this point.

To avoid confusion they would probably break the version convention entirely and name it with the year instead. So instead of Perl6 it would be Perl'19.

I think it's likely they will skip the 5, and continue with version 32, or whatever minor they're up to now.

Ditch the major version. As the current one is 5.30, the next one will be Perl 31, the next stable is Perl 32.

There's even a good mathematical justification for going from 5->32; just say that previously the versioning was in log_2 scale...

Maybe it’s better to find a new name for the next Perl 5 language version. It would simplify internet searches. It should be clearly distinct from Raku though.. Angular is in a similar mess to Perl, very hard to find decent information on web crawlers

Well, PHP jumped from 5 to 7 (without there truly ever being a 6) so I think Perl could do the same with no major downside.

They'll probably skip to 7.

That is probably the best solution, but at the same time it is such a hilarious thing.

I think it would be a better idea to make the minor number be the major number. So skip to 32.

Why not Perl 10 or Perl X?

no, it's called cperl now. perl5 didn't see not much improvements for the last 20 years, the development happens only in cperl, which is the perl5 successor.


Since the language-previously-known-as-Perl6 will be known as Raku, there shouldn't be any conflict with Perl v6

Even if file names/packages don't clash, there's still a conflict when it comes to documentation, articles, blog posts, books, stack overflow questions and other documents that might or might not be updated.

That would only further confusion

Hey Ovid. I'm curious...if P6 had been performant and production worthy enough for your tau-station game, how much easier would the project be than with P5 + Moose? Just curious...I remember you saying years ago that you would've used it if you could've at the time.

The https://taustation.space/ game runs great on Perl 5, but yes, with a robust Perl 6, many things would have been easier to implement. But by "robust" I don't mean just the language—I also mean the ecosystem.

There is no DBIx::Class (or related schema loader) for Perl 6. I don't know how mature the web frameworks are. Or even basic stuff like Excel reader/writers (we use lots of Excel for backend data analysis).

On the other hand, most of the async stuff we currently use can be thrown out. With raku's gradual typing, our in-house type libraries can be tossed out. Our local modules for making it easier to write clean procedural and OO code could be thrown out.

And the raku code would be far more concise and easy to read. Here's a simple Point object in Moose:

    package Point {
        use Moose;
        use overload '""' => \&Str, fallback => 1;
        use Moose::Util::TypeConstraints;
        subtype "PointLimit" => as 'Num'
            => where   { $_ >= -10 && $_ <= 10 }
            => message { "$_ must be a Num between -10 and 10, inclusive" };

        has [qw/x y/] => (
            is       => 'rw',
            isa      => 'PointLimit',
            required => 1,

        sub Str {
            my $self = shift;
            return sprintf "[%f,%f]" => $self->x, $self->y;


    class Point {
        subset PointLimit of Rat where -10.0 .. 10.0;
        has PointLimit $.x is rw is required;
        has PointLimit $.y is rw is required;
And for those who don't "grok" the above, here it is in Python 3, just so you can see how clean raku's OO syntax is:

    class PointLimit:
        def __init__(self, name):
            self.name =  name
        def __get__(self, point, owner):
            return point.__dict__.get(self.name)
        def __set__(self, point, value):
            if not -10 < value < 10:
                raise ValueError('Value %d is out of range' % value)
            point.__dict__[self.name] = value

    class Point:
        x = PointLimit('x');
        y = PointLimit('y');

        def __init__(self, x, y):
            self.x = x
            self.y = y

        def __str__(self):
            return "[%f,%f]" % (self.x, self.y)

It's worth checking out the Red ORM, great progress is being made and it feels very Perl 6 native in terms of its semantics.

Red looks interesting. Though I don't like the mapping of tables to "model". In general, I find that a model should be a consumer of an ORM, not the ORM itself. Otherwise, you expose to much to the business layer and it's harder to refactor.

For example, if you have a column on table A and you later need to move that to table B, a clean model can encapsulate that change. Hard to do when the ORM is being treated directly as the model.

Try Xoos. Red also uses a meta model syntax for extra ugliness.

Thanks for the detailed reply Ovid!

I'm only a novice in Perl5 land (Python is usually my go-to along with Linux CLI tools and Powershell on Windows, or honestly a lot of SQL these days but sometimes I reach for Perl5 when it has something I need) but I always keep an eye out for different and interesting technologies and Perl6 is definitely on my radar to check in on every now and then. As you've pointed out, it seems to have a lot of power that could reduce a lot of the one-off scripts I write. I do a lot of basic text file manipulation and any feature that can save me time is valuable even if there is more stuff to learn. To me, Perl6 appears to allow for writing beautifully succinct and readable OO, Imperative, or FP like code. However, if I just need to wrangle some data (throwaway code) it looks like it can be for text what APL is for arrays (a powerful Swiss army knife).

On another note, while I have you here, do you ever plan on putting out another Perl book, but one on Perl 6 (I know there are several already published).

Clojure has a focus on concurrency, is functional and it embraces JS and Java, the dominant platforms.

> This has been a huge deal for the Perl community.

I wasn't aware that there was one beyond the poor sods charged with maintaining my youthful sins.

I get hired all the time to fix legacy systems in Perl or to build new systems in Perl.

We're still out there, but it's not "cool" to talk about.

I hope you are not working on my old sins. But if you are, can I watch? :-)

I'm pretty sure Ovid's hair would turn grey if he did! ;-)

Rather reminds me of what happened with Palm OS 5 and Palm OS 6. Both ended up adopting separate names but because OS 6 wasn't backwards compatible the sheer weight of legacy software kept it from ever catching on.

If only the Python community could learn something here

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact