Some community members believe "Perl 6" is a very confusing name: it uses a digit as part of
the name and it conflicts with the name of a sister language "Perl". Some outsiders don't realize
"Perl 6" is a brand new language—vastly different than "Perl"—and so avoid it, thinking they
know what it is already. At the same time, some who love "Perl" come to "Perl 6" and feel tricked,
because the language isn't the next release of that language, but an entirely different one.
To clear up the confusion, Larry Wall created a second name for the language, a "stage name" if
you will. That name is "Raku". It can be used interchangeably with the original "Perl 6" name or
even be combined with it to form "Raku Perl 6". Pick the one that works the best for you and use
The fact that it is always brought up to me makes me think they should've just called it something entirely different. Hindsight is 20:20 though.
Well... a lot of folks saw this coming. As you say, it's been brought up again and again, since the start. Foresight is also 20:20, if the right people are willing to listen to what's being said.
* Perl 6
* Raku Perl 6
and we're told to, "Pick the one that works the best for you and use it consistently". And don't forget there's,
Rakudo, a compiler for Perl 6
Rakudo Perl 6 Compiler
If you wanna rename things, fine - just do it, don't do this halfsies thing. Don't make the name collide with something else, especially in a very related project.
Actually, the more I think about it, using "Rakudo (the language formerly known as Perl 6)" as a descriptor would probably do the best job encapsulating what it is succinctly. It was a continuation of Perl, but now it's its own thing. As opposed to "Perl 6", which doesn't really convey how radically different it is.
I'm not really one of the "Perl 5 needs to reclaim the Perl 6 name" camp, even though I'm a full time Perl developer and have been for close to two decades. Perl 5 will do what Perl 5's going to do, and freeing up the Perl 6 name won't help all that much with that (it's not like there's enough changes worth making a Perl 7 from, and a purely marketing driven name change would just be laughed at). It might actually be more beneficial to Perl 6.
Is it still useful? Damn right it is, but there's not going to be a Perl 5++.
Speaking as someone who's been writing Perl since oh, 1997 or so. So another multi-decader (and no plans of stopping) - where do we all meet? At the bar?
Now, I'll concede the point regarding language design though: the Perl 5 Porters have become very conservative wrt language evolution. I used to be highly skeptical of this (I convinced folks of strict by default in 5.12 and oh how much I lobbied behind the scenes for fully @_ eschewing function signatures!) but since we made a number of blunders in such changes in the decade prior, I understand the conservativism.
The idea of extending things via modules in Perl 5 was a great one, but there's a limit on what you can without features guaranteed to be in core. I also get the idea that keeping the core small is probably a good one (by not shipping every module in the world), and keeping the language opinionated (by letter you select just what type of meta-object system you want, but after a while, it doesn't seem like these things help with architecting a future for the core language.
So it goes, I suppose.
It is doubtful this will ever be backported into the official distribution, because $drama...
Me too, historically anyway, but I'm not a fan of this half-way approach. Someone explicitly requested that Larry create an alias for the language .
> If another name is truly as superior as the full-rename proponents claim it would be, I believe the alias can become a defacto name through its sheer amount of use. Thus, the creation of the alias can be seen as a means for the full-rename proponents to prove their claims.
Emphasis mine. Among other things, this does not compute for me. Adopting three names for the language (Raku, Raku Perl 6, Perl 6) is the exact opposite of what the full-rename proponents are suggesting. You're not giving them an opportunity to prove their claims, you're giving them the middle finger. Or that's how it seems to me, anyway.
“There are only two hard things in Computer Science: cache invalidation and naming things.” -- Phil Karlton
Hacker News is really inconsistent in marking PDFs.
Secondly, the PDF is very well put together. This is much nicer than your typical release notes cobbled together from git commits: it's actually pleasant to read. (Though if you really prefer an HTML version, that's also available: https://github.com/perl6/roast/blob/master/docs/announce/6.d...)
Finally, the site https://marketing.perl6.org also seems to have other material that's pretty well put together. As someone who is not immersed into the community, this helps promote the feeling that the project is vibrant. (Side-note: they should get a domain to reflect this.)
Yes there's waaaay more to a language ecosystem than marketing, but I'm glad to see this effort.
Interesting thread from this summer: https://www.reddit.com/r/perl6/comments/8p26bb/is_perl6_fast...
That's just the compiler rather than VM or NQP level, where you will see even more performance related work.
One of the bigger breaking changes in 6.D at the language spec level is for performance of scheduling multi threaded work. https://github.com/rakudo/rakudo/pull/1004
The main canary test for performance used by the community is the Text::CSV module. The vanilla Raku implementation is about 2x slower than the C wrapping Perl equivalent. The nice property of the Raku library is you can run it in parallel quite trivially and then its suddenly faster than the Perl version. In general the simple introduction of hyper/race keywords into user code is a big win for performance, but perhaps not cost.
There are a tonne of features of the language specific for performance most people walking through the door aren't so aware of. Native type decorating your code and variables for example, usually invokes significant improvements to numeric work. The JIT does some of that automagically but simple issues like your code implicitly switching between rational and floating point types will break optimisation. If you don't say what you really want to do Raku always assumes you want to do the safest and usually slowest thing like use bignum or rational type things, that are harder to speed up down at the CPU.
Performance and Python aren't exactly related (I know you can call into C code with numpy etc., but still Python itself and idiomatic code in it is often super slow).
And Python is a much popular language, compared with Perl, plus the Python 2 -> 3 changes were much smaller than Perl 5 -> 6.
I'd venture to say that besides some very niche distributions, Perl 6 will never be included in the base installations, unless it gets some killer app.
Someone's always playing programming language games
Who cares they're always changing programming language names
We just want to dance here, someone stole the stage
They call us irresponsible, write us off the page
If you're looking of the compiler, check https://rakudo.org/files
The original news server only marked pdf on the scribd site 
Just by using a language you will find a lot of design choices that you either like or don't. There's no reason that you need to design a language to criticize the choices made in a a language.
Perl is (still) a fantastic language to use when you have complex tasks and don't want to spend more time on boilerplate and specific formalisms of the language, than the problem space. Perl is still (as in has been for many years) the goto language for a number of difficult problems. If your tooling is helping you write in the tool versus helping you solve your problem, you might be using the wrong tool.
edit: included missing reference.