A Complete Course of the Raku programming language
course.raku.org
course.raku.org
I initially thought this was about the programming language for roku and was a little disappointed it was about perl 6 changing names.
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.
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.
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
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.
[1]: https://github.com/atweiden/config-toml/blob/master/lib/Conf...
[2]: https://github.com/atweiden/txn-remarshal/blob/master/lib/TX...
[3]: https://docs.raku.org/language/regexes
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.
Would you say I'm missing something?
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:
<4 5 6 7>.map(-> $x { $x + 7 }) # result: (11 12 13 14)
<4 5 6 7>.map(* + 7) # result: (11 12 13 14)
<4 5 6 7>.map(* * 7) # result: (28 35 42 49)
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.
> (also yes, (* * *) will take two inputs and multiply them.)
That's true, but Raku also supports non-Unicode math operators, so the more idiomatic way to write that would be
(* × *)
_.methodname()
_ + 1
x => x.methodname()
x => x + 1
But otoh, Raku nicely stretches the approach to both zero and multiple placeholders:
* The zero placeholder `.methodname` in Raku is the same as Scala's `_.methodname`
* Any number of placeholders are allowed, so one can write eg `* + *` as an anonymous binary add function.
(4, 5, 6, 7) ! (. + 7)[0] https://gist.github.com/raiph/849a4a9d8875542fb86df2b2eda892...
[1] https://thenewstack.io/larry-walls-quest-100-year-programmin...
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
use DBI:from<Perl5>;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.
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.
[0]: https://www.youtube.com/watch?v=QNeu0wK92NE [1]: https://www.jnthn.net/papers/2019-perlcon-performance.pdf
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.
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.
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.
If you find yourself in a place with frequent one-off text wrangling or Unix admin problems some Perl knowledge is worthwhile.
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 article shows the regular expression syntax in several popular programming languages: https://cs.lmu.edu/~ray/notes/regex/
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.
If you are familiar with C / C++, then learning Perl is relatively fast and easy: https://perldoc.perl.org/perlintro
Only if your goal is to be able to work on legacy codebases. Learning a cool language in itself is cool.
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.
But as for usage, it's mostly legacy Perl codebases, which are much less interesting - Python and Ruby basically cover the same bases.
[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
What problem is there beyond that?
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.
> blocks the current thread of execution
That's a green thread.[1]
To quote Wikipedia[2]:
> 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.
[1] https://en.wikipedia.org/wiki/Green_threads
[2] https://en.wikipedia.org/wiki/Thread_(computing)
[3] https://en.wikipedia.org/wiki/Work_stealing
[4] http://jnthn.net/papers/2018-concurrency-guts.pdf#page=67
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.)
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.
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.
This guy is so amazing. Mad props to him.
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?"! :)
[0] https://gist.github.com/raiph/849a4a9d8875542fb86df2b2eda892...
f 5, 6;
is interpreted as equivalent to
f(5, 6);
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. :)
I'm not talking about gluing stuff together with scripts - I mean a large project operating wholly under it
https://www.rexify.org/ -- an automation framework
https://mojolicious.org/ -- amazing web framework
https://metacpan.org/pod/DBIx::Class::Manual - amazing ORM
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.
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.
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]
[0] https://taustation.space/blog/category/technology/ [1] https://raku-advent.blog/2020/12/20/day-20-a-raku-in-the-wil... [2] https://p6steve.wordpress.com/2020/04/17/raku-vs-perl-save-7...
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.