Sadly only first part is complete. Raku is the much more functionally inspired new Perl. It’s the renaming of Perl 6 and means “camel” or “paradise” in Japanese.
Is Perl/Raku widely used these days? Are they worth learning? I've always been curious about those languages but I've had the impression that people are moving away from them.
Learning Perl is worthwhile because it is ubiquitous on Unix-like systems and Perl-compatible regular expressions are the defacto standard regular expression syntax.
Perl may not be as popular now as it was in the past, but it is still around and lots of legacy systems that were written in Perl are still in active use.
But as Perl-compatible regular expressions are available in many other languages, this is not really a reason for learning Perl itself, right? Or am I missing some deeper insight into regexes, because I don't know Perl?
That's true, but it's worth mentioning that using the regexes in perl is quick and even fun to write. They are built-in to the language. some people find it very convenient.
I find that regular expressions and text-wrangling tasks are faster and easier in Perl than in other programming languages due to its accessible syntax and regular expression engine speed.
This GitHub repo gives some regex performance test benchmarks: https://github.com/mariomka/regex-benchmark Perl is pretty fast among the scripting languages that were benchmarked.
I use both every day. The core perl5 packages I rely on are updated regularly. The perl5 runtime is released on a reliable schedule. Everything works.
I use raku mostly for fun. It has come a long way. It has further to go, but I don't mind. There is a surprising amount of vital packages already available for getting things done.
I don't think anyone believes perl5 will be as popular as it was years ago, or that raku will be a top-five language, but who cares? As long as the core community persists, its enough.
Raku is crammed with enough good, original ideas about programming languages that I would compare it to the "learning Lisp" meme in that it will probably reveal something new to you.
But as for usage, it's mostly legacy Perl codebases, which are much less interesting - Python and Ruby basically cover the same bases.
Really, probably not. Perl was mind blowing, productive, and super fun when your only other choices were C/C++ and bash/sed/awk. Most people eventually realized that There’s More Than One Way To Do It makes for code maintenance nightmares.
Over the years I have learned and dipped my toes in many programming languages, and I'd need some kind of reason to look into yet another language. What are Raku's main contributions to the programming language design space that I probably haven't seen elsewhere?
I was taught in school that `0.1` is rational. Afaik it isn't in any lisps. I think that's the point the GP was making.
That said, while making `0.1 + 0.2 - 0.3` come out as exactly zero, with a clean and principled way to avoid things going pathological when the denominator gets large, is nice, it's hardly one of Raku's "main contributions to the programming language design space that I probably haven't seen elsewhere?"! :)
Gradual / optional type declaration, grammars as a first class language feature, async / parallel programming, rational numbers, lazy evaluation, OOP with classes and roles and an underlying metaobject protocol.
The real bummer about optional typing is that it doesn’t speed up the program. I used it all over thinking that I was “optimizing” or helping the compiler. Really I was creating more work for it.
The goal is definitely that it can enable greater optimisation and I agree that it's not a reality yet. The other benefit is that it constrains types so that you get compile time type checking, which is very useful.
Raku incorporates many of the neatest ideas in languages but retains a perlish flavor. I would almost equate it with Racket, in that there is support for many styles of coding, and your code may look nothing like another's. TMTOWTDI is fundamental to the perl philosophy so if you prefer total consistency, you are probably better off with python or go.
great question @msvan - raku has many ... for me the unique genius of raku is to have stolen all of the best parts of type system, OO, grammars & regex, functional and procedural coding and jammed them into one smoothly integrated syntax
It's core concept cake (like a "concrete turing machine model" counterpart to lisp 1.5's half page of lambda calculus definition) combined with the mutable braid of mutable PLs icing.[0]
I'm so glad they renamed Perl 6, having it dangling for decades like a Sword of Damocles hurt Perl more than anything else could. At least both languages are now able to progress in their separated ways, and I must say Raku is a really pleasant language, and a joy to use.
I'm going to butcher my question so my apologies, I've heard Perl described as a sort of linguist / grammatical type of language, where you can solve the same problem using multiple approaches and syntax. Is this something Raku is drifting from or embracing? I think Raku is kind of interesting and I did try it out a few times whilst it was called Perl 6, but I'm not sure what its niche is. I mostly do Python for professional projects but don't mind experimenting with other languages.
I guess what I'm trying to ask is what are the major fundamental differences between the two languages? Features aside, although if some features are part of the answer thats fine.
Raku definitely embraces multiple approaches and syntax, continuing the “There is more than one way to do it” motto of Perl. In addition, Raku aims for consistency and composability while introducing new language constructs like laziness, gather/take, async/await, hyper operators, grammars and more.
> I've heard Perl described as a sort of linguist / grammatical type of language, where you can solve the same problem using multiple approaches and syntax. Is this something Raku is drifting from or embracing?
Very much embracing – "turning up to 11" might be a better way to put it. I recently wrote a three-part blog series[0] about what Raku's primary values, and the more-than-one-way-to-do-it idea features prominently in that list.
As someone who wrote a limited amount of Perl 5 before writing a not
insignificant amount of Perl 6 (now Raku), I find Raku syntax to be
deeply Perlish while also being more modern and internally consistent
than Perl 5.
IMO Raku has three standout features:
1. Grammars in the stdlib [1]
2. The absolute most flexible multi-dispatch system of any programming language [2]
3. The best regex syntax of any programming language [3]
In 2015, I had to write a DSL for a double-entry accounting system. That's when I discovered @jnthn's Perl 6 grammar debugger [4], which allowed stepping through a Perl 6 grammar line by line and visually seeing how the grammar was consuming a string. At that time I had very little programming experience, which made Perl 6 far and away the easiest way to write a custom DSL parser.
If you enjoy Erlang/Elixir multi dispatch, e.g.
def format({:ok, %HTTPoison.Response{body: body, status_code: 200}}) do
body
|> Meeseeks.parse(:xml)
|> Meeseeks.all(xpath("/*"))
|> Enum.map(&Meeseeks.tree/1)
|> _format
end
defp _format([{"current_observation", _version, current_observation}]) do
current_observation
|> Enum.map(&_format/1)
|> Enum.filter(& &1)
|> Enum.into(Map.new())
|> Poison.encode!()
end
defp _format({"credit", _, [credit]}) do
{:credit, credit}
end
defp _format({"credit_URL", _, [credit_url]}) do
{:credit_url, credit_url}
end
Raku does that in an even more flexible manner, destructuring included. I love how declarative it makes the code read.
However, I must say I've left the honeymoon phase of Raku far behind me now. In my experience, Raku grammars are insanely slow: at least as of many years ago, it was taking ~40 minutes to parse a ledger-style accounting format log file that wasn't even very big. When jnthn's grammar debugger got really buggy and less actively maintained, that defeated one of the biggest reasons I had to use the language. I've also experienced numerous bugs with Raku's type system, and just in general wouldn't write many things in Raku.
But to your question — I would write even less things in Perl 5. I have no use for Perl 5 now that Raku exists, and don't know why anyone would write Perl 5 in the modern day given how many other compelling options exist in its niche. Raku is different, and it deserves to see top caliber core development. It doesn't have that yet, and that's sad.
Frankly Raku isn't capable of replacing really any mature programming language for anything but informal scripting tasks where you don't care about speed, and where you don't need an “academic” tier type system. For those tasks, it is quite a fun language. I remain optimistic about Raku's future, and would seriously question the conventional wisdom of using Python or JS in its place for many, many things.
> When jnthn's grammar debugger got really buggy and less actively maintained, that defeated one of the biggest reasons I had to use the language.
I created a couple PRs for the grammar debugger, one that fixed a bug, another that dramatically sped it up, but neither were merged. But imo that was appropriate; spending time on that debugger wasn't a good use of his time.
And now jnthn's work on grammar debugging in Comma is so vastly superior to the old debugger that it would imo be especially silly of him to use up his limited time continuing to pay attention to the old code. I'm curious whether you agree with that?
> Raku is different, and it deserves to see top caliber core development. It doesn't have that yet, and that's sad.
I agree it needs more than jnthn, but surely you agree that jnthn is top caliber?
He has a degree in CS, specializing in PLs, compilers, and VMs, so exactly the right focus for his core dev work. And the university he did his degree at was Cambridge, one of the world's top universities, especially in CS. And he was awarded the degree with honors.
In addition, he is a highly successful, highly paid enterprise systems consultant whose work on Rakudo in his limited spare time, in recent years augmented by occasional grant supported projects that pay less way less than his commercial rate, has always struck me as extraordinarily good.
I've always thought it would be wonderful to have two jnthns, but that we have to respect and appreciate what resources we do have, and let him work at a pace that doesn't burn him out while he continues to mentor the other core devs, as he has now for many years.
a few years ago damian conway made a few talks about the raku first-class grammar objects, it kinda signals no departure from the linguistic interests of that community.
There are a TON of experiments and language mash-ups in Raku. Let's see here.... Types can include guard clauses that are evaluated at runtime. Typed multi-dispatch on top of that. In addition to normal "sets" it has "junctions", like some sort of funky quantum superposition or something. In theory those can be made parallel at some point. Stuff like that.
One that is particularly funky is the "whatever-star". This is a "" char that can be used in a few places to mean more or less... whatever. For example:
That stabby inline lambda there can be sugared down in a lot of ways, including with the whatever-star:
<4 5 6 7>.map(* + 7) # result: (11 12 13 14)
... I've not seen anything quite like that in other languages, not sure if it is a new invention or if only nobody else is crazy enough to try it. And yes, you can use multiplication next to it to make it look crazier:
<4 5 6 7>.map(* * 7) # result: (28 35 42 49)
(also yes, ( * *) will take two inputs and multiply them.)
I will note though that dwelling on these crazy/fun edge cases is amusing, but programs can look quite a bit more like a basic ruby app (with sigils) if you so desire.
Imo, while both Perl and Raku are exemplars of extensible PLs in their own ways, Perl's approach is essentially a tower of hacks built on the wrong foundation while Raku's core concept[0] is built to last for decades, if not a century[1].
Short answer: no, Perl is a very rare choice for starting a "serious new application", and Raku's even further off.
In Perl's case, it's not that the production-ready libraries and frameworks aren't there -- they are, and they are fast and stable and in some cases very sophisticated -- but simply that the community of developers likely to start a "serious new application" has passed Perl by for more modern (e.g., Rust, Elixir, Kotlin, Go even if its ideas are old) or ubiquitious (e.g. JS, Python) choices.
In Raku's case, there is not a deep bench of libraries and tools suitable for production.
In both cases, hiring for previous knowledge is not practical.
Unpack this for us... Do you mean commercial applications? If so, you can determine for yourself the small number of languages used for "serious applications".
If you mean data analysis, ETL, system administration, and general data reconstruction, I can't think of a faster, more appropriate language than Perl. Sed and awk are also powerful mainstays.
If that is your basis for evaluation, then I don't think Raku is for you.
But I think you are missing out, not just on Raku but on lots of cool stuff that is not being used "in serious applications".
There is time and place for boring tech, like when you are building a banking backend or something. But there is much more to life than churning out banking backends, and Raku is well suited for those other endeavors.
I don't know much about Perl but am aware of Tau Station, which was launched a few months ago. I recall reading somewhere that it includes a new Perl codebase with approaching a million lines of well written modern code.[0]
Raku is a different language, a very young one that has its adoption-for-serious-applications curve mostly ahead of it. Thus you get articles like the advent one from a few weeks ago that seriously documents a serious Raku application in a notably unserious way.[1] It's apparently only 7K or 13K lines of code, depending how you count, but well written Raku code is typically a fraction of the length of well written Perl code, so there is that.[2]
So far I have found the lack of good tutorials my main roadblock towards learning Raku. I am looking forward to spending the weekend working my way through this.
Raku seems to be stuck in a "we'll optimise that later" dead-end, especially with string processing. Parse a large log file with a regex and compare Raku with Perl5. Raku has a long way to go.
Actually, it is even simpler than that. If you have the Inline::Perl5 module installed, then the only thing you need to do to load a Perl module, is to use the :from<Perl5> adverb in the -use- statement, e.g.:
I think Raku's Inline approach will one day eliminate that suffering and replace it with the even larger advantage that Raku's ecosystem will trend toward being the sum of other PL's existing ecosystems.
Consider the Perl modules on CPAN. Raku's ability to just use many of these existing Perl modules, including ones that use XS, completely unmodified, running via standard perl binaries, and thus running exactly the same as they would be if run standalone instead of within the Inline harness; and using standard Raku syntax, as if Perl modules were native Raku modules; all of that, done well, is an extraordinary breakthrough.
Stefan Seifert did remarkable and respected work for a decade on some of the most important Inlines that Perl folk use; imo his 5 years of work on the Raku evolution of that notion are far more remarkable in terms of the long term implications I see as I watch the maturing of the Perl Inline and look forward to the anticipated redo of the Inlines for other langs to catch up with the Perl Inline.
> Raku seems to be stuck in a "we'll optimize that later" dead-end … Raku has a long way to go.
I agree that Raku still has a long way to go in terms of performance – it's not nearly as fast as it has the potential to be.
That said, I strongly disagree that Raku's performance is stuck. I've only been using Raku for about a year, but even in that time I've seen a noticeable improvement. Over a longer period, Raku has gotten dramatically faster – around a 10× improvement from the 1.0 Christmas release, depending on how you measure. For details, check out this 2019 talk where one of the lead Raku developers discusses performance gains/plans. ([0] video; [1] slides)
There's definitely still work to do (especially with regexes and grammars, as you mention). But the language has made tremendous progress, and is now in the same basic range as Python/Ruby/Perl.
Agreed that both Raku (the language, community, and ecosystem) and Rakudo (the compiler) have a long way to go.
But whose who know them well know that there's still lots of low hanging fruit and it's "just" a matter of continuous improvement, year by year.
> stuck in a "we'll optimise that later" dead-end
That's a bit like saying Java (or rather the JVM) seemed to be stuck in being dog slow based on its dog slow performance in the first few years of its official existence. It paints a false picture.
In reality JVMs got faster each year, sometimes by big jumps, and 10 years after Java's first official release it was still slow, but no longer dog slow. (And nowadays Java is no longer considered slow.)
What matters is whether there is sustained love and continuous significant improvement of a PL, and an implementation. Raku has demonstrated that it has that for 20 years, and Rakudo for 10.
There is good reason to look forward to that continuing for both Raku and Rakudo until well beyond the point at which its raw string processing performance has become respectable.
And this will be in addition to what's remarkable about Raku's string handling, namely its world leading Unicode support and O(1) string indexing. Presuming that will finally pay off, and I see no reason to think it won't, it will seriously pay off.
Yes, unlike the languages mentioned in TFA, it just works. Specifically, you can `await` anywhere without the requirement of declaring the surrounding context as async which in practice means you eliminate the red/blue distinction.
It's a cooperative yield point so while the code containing the `await` blocks and waits, the underlying thread/core is released and "stolen" by the standard scheduler for other work, and then resumed when the processes it's waiting for complete or are cancelled.
That is your opinion. Mine is that it is okay to "sow doubt", similar to that it is okay to "sow doubt" when someone claims they built a perpetuum mobile.
But since you are asking me to download the language so politely: I think this is not necessary. A look in the documentation (https://docs.raku.org/language/concurrency) seems to be enough:
> The subroutine await is almost equivalent to calling result on the promise object returned by start but it will also take a list of promises and return the result of each
So "await" is equivalent to calling "result". What does calling "result" do?
> result blocks the current thread of execution until the promise is kept or broken
This stands in direct contradiction to what was said in the thread here:
> so while the code containing the `await` blocks and waits, the underlying thread/core is released
Unless the OP referred to a _different_ await, I would say: case closed.
> a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler
This is the definition the doc is using.
The thread of execution that is blocked is a green thread -- the sequence of instructions containing the `await` that is managed by a scheduler managed by Raku.
> This stands in direct contradiction to what was said in the thread here:
>> so while the code containing the `await` blocks and waits, the underlying thread/core is released
> Unless the OP referred to a _different_ await
No, what I meant by "underlying thread/core" is an OS thread as against a green thread, and what I meant by "released" wasn't that it was released back to the OS but instead that Raku's scheduling sees the `await`, blocks the enclosing green thread, and immediately unblocks some other green thread by "stealing"[3] the OS thread to run that other green thread instead.
I hope I've now reassured you that Raku(do) both eliminates the red/blue distinction and doesn't block OS threads.
Yes, it's unusual among PLs. No, it's not easy to design a PL to do this at a language level. Nor is it easy to implement. (For example, the Rakudo implementation involves taking a continuation[4].)
But it is possible, and Raku has never had the red/blue distinction, and has had work stealing semantics for `await` since 2018.
I think the main problem has been that it requires building an appropriate concurrency design into the foundation of a language.
For most PLs, concurrency is somewhat of an afterthought, and even for those where concurrency was addressed from the get go, the design nevertheless doesn't support work stealing, or, if it does, doesn't support doing so at the language level.
> I doubt...
Scepticism is healthy. :)
But regardless of my speculation about why most PLs don't go this route:
* The general technique (called "work stealing"[0]) was first implemented last century;
* PLs can support it directly at the language level provided they have suitable foundations;
* Raku is one such PL.
The first version of Raku (Raku Christmas, released Christmas Day 2015) already eliminated the need for function colouring. While the first version included an array of concurrency, async, and parallel processing features, including an `await` keyword, there has never been an `async` keyword in Raku. This is unusual, but Raku is not the only recently released PL to do so.
Work stealing semantics for `await` were only formally introduced in Raku Diwali, released Diwali day 2018, and the corresponding Rakudo compiler. Again, this makes Raku unusual, but not unique.
(What is perhaps unique is that Raku programs can include both old and new semantics in the same program. Raku has a radically different take on language evolution and backwards compatibility such that incompatible changes don't mean modules are incompatible with each other. Not easy to do, but possible, as demonstrated by Raku programs that make use of both Christmas and Diwali modules.)
> Sounds pretty easy, no?
It is easy for users. Once it's implemented in a language.
But it's not easy for language designers and implementers. (And it's essentially impossible to introduce if a PL has already adopted older approaches to concurrency.)
I think Java does have coloured functions. It's just that the colours are "fast" and "slow" - i.e. functions which will block the thread for a long time and those which don't.
You can't call "functions that may block for a long time" from a UI thread. Java doesn't have async, so you have to punt them to a background thread manually.
Not sure why I’m getting downvoted? The linked article goes at length saying callback hell is terrible, await is a partial solution, and languages that are free to use threads have it best. Author upholds that, “Goroutines in Go, coroutines in Lua, and fibers in Ruby are perfectly adequate.”
I don't know why you got downvoted. Then again, I'm not quite sure what you meant by "await is a partial solution" and "languages that are free to use threads have it best".
As far as your quote goes, I'll add:
> Or, more precisely: multiple independent callstacks that can be switched between. It isn’t strictly necessary for them to be operating system threads.
(Quoting the same paragraph you quoted.)
Standard Raku provides support for OS threads; green threads; coroutines; multiple independent callstacks that can be switched between; an `await` that doesn't require function coloring and is cooperative, supporting work stealing of its thread when it's waiting; multiple other constructs for concurrency, multiple others for asynchrony, multiple others for parallelism; and is an extensible PL anyway.
If you could briefly put your comment into that context, so that I (and perhaps other later readers) could better understand it, that would be helpful to me. I plan to upvote both your above comment and any below if what you're saying then makes sense to me. TIA if you have time to reply.
Raku is a seriously cool programming language, but it is still not at the level to where I'll put in learning effort past all the tutorials I've read in the past. When it reaches maturity, I could see myself using it in some hobby projects. It seems like it has a good bit of the power you see in languages like Smalltalk, but in a more accessible package.
I haven’t used Raku for anything big, but I do use it for a lot of small projects. I find the expressiveness great and I can get things done with minimum fuss. It’s especially good for command-line tools where a MAIN function gives a CLI with parameters and autogenerated usage.
Look, Larry, give it up, OK? Nobody is going to use Perl 6. There are a million other languages out there these days. What does your language do that is in any way special or unique? Nothing.
Needless to say, the name Perl has little cachet or relevance today, thus explaining the name change. Lipstick on a pig.
At this point, if a supposed 'alternative' can't replace the C language, I want nothing to do with it. We need to get back to the hardware. No, Go doesn't cut it, and (laugh track deafening) I'm not interested in Rust, either.
I think the very idea of a VM language, while a cool and fun toy back in the early 2000s, is losing its relevance, at least for the moment. Source code portability is much better than binary portability.
This language looks cool! I also really like the page-by-page format for the tutorial, which strikes exactly the right balance (for me) between giving too little and too much info.
As a side note, I noticed that the "Notes on using Unicode" page[1] referred to the quotation marks used in kanji-based languages[2] as "fancy." I think this kind of exotification of non-western cultures (where mundane things become exciting or "fancy" because it's not from your culture) can be a kind of cultural "code smell" that warns off non-western developers. Even if it comes from a humorous or enthusiastic place, an outsider just sees someone getting weirdly excited about a normal thing.
Nice! As a side note, I think it's very cool that Raku supports multiple quote characters. It's unusual to see that in source code and, while I code mostly in English, I imagine it would be nice for people writing in other languages.
Is there a one-page version of this? Or at least with support for ? and ? keys for page navigation.
It's basically impossible to skim this course or to jump around it quickly.
Edit - here's a GreaseMonkey script for the arrow navigation between the pages. Right arrow - next page, Left arrow - previous page. https://pastebin.com/uQMWyfq0
If you insist on comparing it to Perl, you could consider it "Perl Re-Imagined". Just like "The Lord Of The Rings" is a re-imagination of "The Hobbit".
> If you insist on comparing it to Perl, you could consider it "Perl Re-Imagined". Just like "The Lord Of The Rings" is a re-imagination of "The Hobbit".
The Lord of the Rings is a sequel to The Hobbit, rather than a re-imagining. Of course there was a bit of re-imagining necessarily involved, much like the relationship between Star Trek: The Original Series and it's sequel The Next Generation.
I think that in some ways the semantics of Raku are closer to Ruby than to Perl5. https://docs.raku.org/language/rb-nutshell is a ruby-to-raku walk through. Among other things, Raku has first-class Roles that I think Ruby should consider adopting. In Raku the sigils (symbols prefixing variables) give an immediate indicator as to a general role that the variable implements -- so $ for single-values, @ for lists, % for dictionaries (hashes), & for callables. That adds a lot of "noise" that makes Raku look different, but under that it is like a lot of modern dynamic OO languages ... lots of objects and method invocations with a few JSON like built in types.
Overall this seems like a fitting outcome for both projects, it certainly gives what it now Perl7 a sense of momentum and freshness as far as discussions around some of the direction being taken by Raku (nee Perl6). Huge thanks to everyone involved.
something inside me just snapped.. if you don't have parenthesis, you don't have clear delineation of parameters vs functions, especially when things get nested, or need to be read years later.
Tail nesting doesn't need parens, but otherwise you're right, use parens to nest.
As for reading code, rest assured that "buy food" rather than "buy(food)" is something the vast majority of English readers find easy to read, even years later.
That said, if such things make you snap, perhaps it's time to relax and ignore posts about programming languages you don't know. :)
reply