This is an updated version of theRaku Advent Post.

Welcome to2025!

How time flies. Yet another year has flown by. 2024 was a year of changes, continuations and preparations. Let's start with the changes:

Edument

Edument Central Europe, the branch of Edument that is based in Prague (and led by Jonathan Worthington), decided to stop (commercial) development of its Raku related products: Comma (the IDE for the Raku Programming Language) and Cro (a set of libraries for building reactive distributed systems).

Comma

The announcement:

With the discrepancy between revenue and development cost to continue being so large, and the prevailing economic environment forcing us to focus on business activities that at least pay for themselves, we’ve made the sad decision to discontinue development of the Comma IDE.

Fortunately, Jonathan Worthington was not only able to release the final commercial version as a free download, but was also able to release all of the sources of Comma. This would allow other people to continue Comma development.

With John Haltiwanger being the now de-facto project leader, this has resulted in abeta of the open source version of a Raku plugin for IntelliJ IDEA, as described inthis blog post.

Cro

Theannouncement

When Edument employees were by far the dominant Cro contributors, it made sense for us to carry the overall project leadership. However, the current situation is that members of the Raku community contribute more. We don’t see this balance changing in the near future.

With that in mind, we entered into discussions with the Raku Steering Council, in order that we can smoothly transfer control of Cro and its related projects to the Raku community. In the coming weeks, we will transfer the GitHub organization and release permissions to steering council representatives, and will work with the Raku community infrastructure team with regards to the project website.

As the source code of Cro had always been open source, this was more a question of handing over responsibilities. Fortunately the Raku Community reacted: Patrick Böker has taken care of making Cro a true open source project related to Raku, and the associated web site is now being hosted on the Raku infrastructure. With many kudos to the Raku Infra Team!

A huge thanks

Sadly, Jonathan Worthington also indicated that they would only remain minimally involved in the further development of MoarVM, NQP and Rakudo in the foreseeable future. As such, (almost) all of their modules were moved to the Raku Community Modules Adoption Center, where they were updated and re-released.

It's hard to overstate the importance of Jonathan Worthington's work in the development and implementation of the Raku Programming Language. So on behalf of the current, past and future Raku Community members: Thank You!

Issues cleanup

At the beginning of October, Elizabeth Mattijsen decided to take on the large number of open Rakudo issues at that time:1300+. This resulted in the closing of more than500 issues: some just needed closing, some needed tests, and some could be fixed pretty easily.

They reported on that work in the Raku Fall Issue Cleanup blog post. Of the about 800 open issues remaining, almost 300 were marked as "fixed in RakuAST", and about 100 were marked as "Will be addressed in RakuAST". Which still leaves about400 open because of other reasons, so there's still plenty of work to be done here.

More cleanup: p6c

The original Raku ecosystem ("p6c") is in the process of being completely removed. Since March 2023, the ecosystem was no longer being refreshed by zef. But it was still being refreshed by theRaku Ecosystem Archiver. But this stopped in August 2024, meaning that any updates of modules in that ecosystem would go unnoticed from then on.

At that time, every author who still had at least one module in the "p6c" ecosystem was given notice by creating an issue in the repository of the first of their modules in theMETA.list. Luckily many authors responded, either by indicating that they would migrate their module(s) to the "zef" ecosystem, or that they were no longer interested in maintaining.

Since then, most of the modules of the authors that responded, have been migrated. And work has started on the modules of the authors that did not respond. With the following results: at the beginning of 2024, there were still 658 modules in the "p6c" ecosystem (now 412, 37% less), by 230 different authors (now 132, 42% less).

Ecosystem statistics

In 2024, 579 Raku modules have been updated (or first released): up from 332 in 2023 (an increase of 74%). There are now 2309 different modules installable by zef by just mentioning their name. And there are now 12239 different versions of Raku modules available from the Raku Ecosystem Archive, up from 10754 in 2023, which means more than 4 module updates on average per day in 2024.

Rakudo

Rakudo saw about 2000 commits (MoarVM, NQP, Rakudo, doc) this year, which is about the same as in 2023. About one third of these commits were in the development of RakuAST (down from 75% in 2023).

Under the hood, behind the scenes

A lot of work was done under the hood of the various subsystems of Rakudo. So was the dispatcher logic simplified by introducingseveral nqp:: shortcuts, which made the dispatcher code a lot more readable and maintainable.

The Meta-classes ofNQP andRaku also received a bit of a makeover, as most of them hadn't been touched since the 2015 release: this resulted in better documentation, and some minor performance improvements. Support forTWEAK methods and a rudimentarydd functionality were also added toNQP.

TheJVM backend also got some TLC in 2024: one under the hood change (byDaniel Green) made execution of Raku code on theJVM backend twice as fast!

Timo Paulssen made the interface with low-level debuggers such asgdb andlldb a lot less cumbersome on MoarVM, which makes adding / fixing MoarVM features a lot easier!

On theMoarVM backend the expression JIT (active on Intel hardware) was disabled by default: it was found to be too unreliableand did not provide any execution speed gains. This change made Rakudo on Intel hardware up to 5% faster overall.

Also on theMoarVM backend,Daniel Green completed the work on optimizing short strings started byTimo Paulssen andBart Wiegmans, resulting in about a 2% speed improvement of the compilation of Raku code.

Work on theRemote Debugger (which so far had only been really used as part of Comma) has resumed, now with a much better command line interface. And can now be checked in the language itself with the newVM.remote-debugging method.

Some race conditions were fixed: a particularly nasty one on the lazy deserialization of bytecode that was very hard to reproduce, as well as some infiniloops.

A lot of work was done on making the Continuous Integration testing produce fewer (and recently hardly any) false positives anymore. Which makes life for core developers a lot easier!

New traits

Two new Routine traits were added to the Raku Programming Language in 2024.

is item

Theis item trait can be used on@ and% sigilled parameters to indicate that aPositional (in the@ case) or anAssociative (in the% case) is only acceptable in dispatch if it is presented as an item. It only serves as a tie-breaker, so there should always also be a dispatch candidate that would accept the argument when it isnot itemized. Perhaps an example makes this more clear:

multisubfoo(@a)         {say"array"}multisubfoo(@a is item) {say"item"}foo[1,2,3];# arrayfoo$[1,2,3];# item

is revision-gated("v6.x")

Theis revision-gated trait fulfils a significant part of the promise of the Raku Programming Language to be a 100-year programming language. It allows a developer to add / keep behaviour of a dispatch to a subroutine or method depending on the language levelfrom which it is being called.

As withis item, this is implemented as a tie-breaker to be checked only if there are multiple candidates in dispatch that match a given set of arguments.

This will allow core and module developers to provide forward compatibility, as well as backward compatibility in their code (as long as the core supports a given language level, of course).

In its current implementation, the traitmust be specified on theproto to allow it to work (this may change in the future), and it should specify the lowest language level it should support. An example of a module "FOO" that exports a "foo" subroutine:

unitmoduleFOO;protosubfoo(|) is revision-gated("v6.c") is export {*}multisubfoo()isrevision-gated("6.c") {say"6.c";}multisubfoo()isrevision-gated("6.d") {say"6.d"}

Then we have a program that uses the "FOO" module and calls the "foo" subroutine. This shows "6.d" because the current default language level is "6.d".

useFOO;foo();# 6.d

However, if this program would like to use language level 6.c semantics, it can indicate so by adding ause v6.c at the start of the program. And get a different result in an otherwise identical program:

usev6.c;useFOO;foo();# 6.c

John Haltiwanger has writtenan extensive blog post about the background, implementation and usage of theis revision-gated trait, if you'd like to know more about it.

Language changes (6.d)

These are some of the more notable changes in language level 6.d: all of them add functionality, so are completely backward compatible.

Flattening

The.flat method optionally takes a:hammer named argument, which will deeply flatten any data structure given:

my@a=1,[2,[3,4]];say@a.flat;# (1 [2 [3 4]])say@a.flat(:hammer);# (1 2 3 4)

One can now also useHyperWhatever (aka**) in a postcircumfix[ ] for the same semantics:

my@a=1,[2,[3,4]];say@a[*];# (1 [2 [3 4]])say@a[**];# (1 2 3 4)

Min/max/minmax options

The.min /.max /.minmax methods now also accept the:by named argument to make it consistent with the sub versions, which should prevent unexpected breakage when refactoring code from a sub form to a method form (as the:by would previously be silently ignored in the method form).

.are(Type)

The.are method now also accepts a type argument. If called in such a manner, it will returnTrue if all members of the invocant matched the given type, andFalse if not. Apart from allowing better readable code, it also allows shortcutting if any of the members of the invocant didnot match the given type. An example:

unless@args.are(Pair){die"All arguments should be Pairs";}

Language changes (6.e.PREVIEW)

The most notable additions to the future language level of the Raku Programming Language:

.nomark

The.nomark method onCool objects returns a string with the base characters of any composed characters, effectively removing any accents and such:

usev6.e.PREVIEW;say"élève".nomark;# eleve

:smartcase

The.contains /.starts-with /.ends-with /.index /.rindex /.substr-eq methods now all accept a:smartcase named argument: a conditional:ignorecase. If specified with aTrue value, it will look at the needle to see if it is all lowercase. If it is, then:ignorecase will be assumed. If there are any uppercase characters in the needle, then normal semantics will be assumed:

usev6.e.PREVIEW;say"Frobnicate".contains("frob");# Falsesay"Frobnicate".contains("frob",:smartcase);# Truesay"Frobnicate".contains("FROB",:smartcase);# False

IO::Path.stem

The.stem method onIO::Path objects returns the.basename of the objectwithout any extensions, or with the given number of extensions removed:

usev6.e.PREVIEW;say"foo/bar/baz.tar.gz".IO.basename;# baz.tar.gzsay"foo/bar/baz.tar.gz".IO.stem;# bazsay"foo/bar/baz.tar.gz".IO.stem(1);# baz.tar

RakuAST

About one third of this year's work was done on the RakuAST (RakuAbstract Syntax Tree) project. It basically consists of 3 sub-projects, that are heavily intertwined:

1. Development of RakuAST classes that can be used to represent all aspects of Raku code in an object-oriented fashion.

2. Development of a grammar and an actions class to parse Raku source code and turn that into a tree of instantiated RakuAST objects.

3. Development of new features / bug fixing in the Raku Programming Language and everything else that has become a lot easier with RakuAST.

RakuAST classes

There is little more to say about the development ofRakuAST classes other than that there were440 of them at the start of the year, and454 of them at the end of the year. As the development of these classes is still very much in flux, they are not documented yet (other than in the test-files in the/t/12rakuast directory).

On the other hand, theRakuAST::Doc classes are documented because they have a more or less stable API to allow for the development ofRakuDoc Version 2.

Raku Grammar / Actions

The work on the Raku Grammar and Actions has been mostly about implementing already existing features. This is measured by the number of Rakudo (make test) and roast (make spectest) test-files that completely pass with the new Raku Grammar and Actions. And these are the changes:

• make test: 110/151 (72.8%) → 140/156 (89.7%)

• make spectest: 980/1356 (72.3%) → 1155 / 1359 (85%)

A lot of work was done byStefan Seifert, picking up the compile-time handling refactor thatJonathan Worthington had started in 2023, but was unable to bring to fruition. TPRF continued the funding for this work.

By the way,DuckDuckGo donated US$ 25000 to the foundation to allow this type of development funding to go on! Hint, hint!

Like last year, there are still quite a few features left to implement. Although it must be said that many tests are hinging on the implementation of a single feature, and often cause an "avalanche" of additional test-files passing when it gets implemented.

If you'd like to try out the new Raku Grammar and Actions, you should set theRAKUDO_RAKUAST environment variable to1. The.legacy method on theRaku class will tell you whether the legacy (older) grammar is being used or not:

$raku-e'say Raku.legacy'True$RAKUDO_RAKUAST=1raku-e'say Raku.legacy'False

Localization

A cousin language was created:Draig, allowing you to write Raku code in Welsh!

Syntax Highlighting

TheRakuAST::Deparse::Highlight module allows customizable Raku syntax highlighting of Raku code that is syntactically correct. It is definitelynot usable for real-time syntax highlighting as it a. requires valid Raku code, and b. it may execute Raku code inBEGIN blocks,constant specifications anduse statements.

A more lenient alternative is theRainbow module byPatrick Böker.

RakuDoc

The final version of the RakuDoc v2.0 specification can now becompletely rendered thanks to the tireless work ofRichard Hainsworth and extensive feedback and proofreading byDamian Conway, as shown in theseblogposts.

Conference / Core Summit

Sadly it has turned out to be impossible to organize a Raku Conference (neither in-person or online), nor was it possible to organize a Raku Core Summit. We're hoping for a better situation in 2025!

Beginner Videos

Completely out of the blue, a Dr Raku created about90 Raku beginner videos on YouTube.

Summary

Looking back, again an amazing amount of work has been done in 2024! Looking forward to an even more amazing 2025!