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").<p>Incidentally, it also happens to sound similar to "roku" (="six").
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.
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.<p>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.
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.
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.<p>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.<p>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 really wish the Perl 6 -> Raku change could let it catch up with other languages such as Python.<p>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.
This has been a huge deal for the Perl community.<p>First, it was thought that Perl 6 would be the replacement for Perl 5.<p>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.<p>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.<p>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.<p>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 ...
I kinda wish something like this would happen with LuaJIT, so it can get out of Lua’s shadow.<p>Lua has breaking changes all the time, which makes sense for its original purpose — embedding — where you don’t need to follow updates. As such the version supported varies among different environments. But LuaJIT has an ecosystem that they try not to break. It’s more of a “conventional” scripting language because of that. It also has an FFI that isn’t in plain Lua.
I find Perl 5 best for the kinds of fire-and-forget text processing scripts that are a bit too complicated for awk but not involved enough to bring in a "real" language. It's a double-edged sword - in a throwaway script it's awesome to not have to bother converting between the number 12 and the string "12", both numeric and string operators will work on them the same way. In a large project that kind of thing is just going to cause a bunch of untraceable bugs due to unidentified invisible behavior. Or you need to resort to weird hackarounds like "0 but true". Also: $_ is like that, only more so.<p>CPAN invented the software repository, and I'm glad it was there so PyPI/Gems/NPM/etc. could learn from its mistakes.<p>Every few years I tried an alpha of Perl 6, but it was always too slow and unstable to get anything real done, and it was always a totally different implementation from the previous one I'd tried. Maybe this name change shows they're getting serious now.
One thing that fascinates me about Raku/Perl6 is how hard it leans into object-oriented programming at a moment when so many other new languages seem to be trending in a distinctly functional direction.
The Author point to [1] for reason for Raku instead of Camelia.<p>One thing that struck me,<p><i>12. Both raku.com and raku.org are currently available.</i><p>I was surprised that a 4 letter .com or .org is still available. So I looked it up and turns out to be not true.<p>And it was interesting half of the discussion had domain name availability as factor.<p>[1] <a href="https://github.com/perl6/problem-solving/issues/81#issuecomment-520216578" rel="nofollow">https://github.com/perl6/problem-solving/issues/81#issuecomm...</a>
It will have quite interesting implications, especially for former Perl 5 syntax enthusiasts. One could say in Polish they "code in cancer" ("programuje w raku").
Larry's actual approval (although he has basically said before that the community doesn't need his approval anymore) is here: <a href="https://github.com/perl6/problem-solving/pull/89#pullrequestreview-300789072" rel="nofollow">https://github.com/perl6/problem-solving/pull/89#pullrequest...</a>
I used a workflow automation system at my previous gig that used java heavily on the backend. Rakuraku Workflow was the name. I hated it. The name, that in japanese means something like “easy easy” (楽々) didn’t help much. It was a mess.
I wish them the best of luck, but in my experience rebranding a seriously off track project is often the treatment of last resort. It’s the vancomycin of struggling projects.
Good move. The name 'Perl' has connotations (good or bad depending on who you ask), but this language always seemed like a different kettle of fish.<p>Names matter.
so, raku is shortened for rakudo the perl compiler. rakudo itself might be japanese but i can't confirm.<p>google, in their infinite wisdom, doesn't want to translate the word because they think i am typing it wrong and they know exactly what i meant to type... but anyways, i think it has to do with paradise or heaven, but i could be wrong.
Julia has a really great threading model coming in v1.3, which is likely to be released this month: <a href="https://julialang.org/blog/2019/07/multithreading" rel="nofollow">https://julialang.org/blog/2019/07/multithreading</a><p>It already supports a variety of parallel techniques but it's about to get easier and safer (e.g. safe I/O).
The naming is a very good idea since it really is a totally different language and the numbering made it seem like an incremental upgrade. Whether it's too late will remain to be seen. Also, now maybe there is space for an actual Perl 6! :-)
<a href="http://tpm2016.zoffix.com/#/13" rel="nofollow">http://tpm2016.zoffix.com/#/13</a> - There is so many good ideas to copy to Rustlang!
Call me a pessimist, but its too little too late... I learned regex in perl so the language will always have a soft spot in my heart. But Python has trounced Perl for almost any task. There simply is no reason to learn perl unless youre in the unfortunate position of managing some legacy stack.