This is an updated version of the Raku Advent Post.
Welcome to 2025!
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 a beta of the open source version of a Raku plugin for IntelliJ IDEA, as described in this blog post.
Cro
The announcement
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 than 500 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 about 400 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 the Raku 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 the META.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 introducing several nqp:: shortcuts, which made the dispatcher code a lot more readable and maintainable.
The Meta-classes of NQP and Raku 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 for TWEAK methods and a rudimentary dd functionality were also added to NQP.
The JVM backend also got some TLC in 2024: one under the hood change (by Daniel Green) made execution of Raku code on the JVM backend twice as fast!
Timo Paulssen made the interface with low-level debuggers such as gdb and lldb a lot less cumbersome on MoarVM, which makes adding / fixing MoarVM features a lot easier!
On the MoarVM backend the expression JIT (active on Intel hardware) was disabled by default: it was found to be too unreliable and did not provide any execution speed gains. This change made Rakudo on Intel hardware up to 5% faster overall.
Also on the MoarVM backend, Daniel Green completed the work on optimizing short strings started by Timo Paulssen and Bart Wiegmans, resulting in about a 2% speed improvement of the compilation of Raku code.
Work on the Remote 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 new VM.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
The is item trait can be used on @ and % sigilled parameters to indicate that a Positional (in the @ case) or an Associative (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 is not itemized. Perhaps an example makes this more clear:
multi sub foo(@a) { say "array" }
multi sub foo(@a is item) { say "item" }
foo [1,2,3]; # array
foo $[1,2,3]; # item
is revision-gated("v6.x")
The is 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 level from which it is being called.
As with is 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 trait must be specified on the proto 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:
unit module FOO;
proto sub foo(|) is revision-gated("v6.c") is export {*}
multi sub foo() is revision-gated("6.c") {
say "6.c";
}
multi sub foo() is revision-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".
use FOO;
foo(); # 6.d
However, if this program would like to use language level 6.c semantics, it can indicate so by adding a use v6.c at the start of the program. And get a different result in an otherwise identical program:
use v6.c;
use FOO;
foo(); # 6.c
John Haltiwanger has written an extensive blog post about the background, implementation and usage of the is 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 use HyperWhatever (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 return True if all members of the invocant matched the given type, and False if not. Apart from allowing better readable code, it also allows shortcutting if any of the members of the invocant did not 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 on Cool objects returns a string with the base characters of any composed characters, effectively removing any accents and such:
use v6.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 a True 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:
use v6.e.PREVIEW;
say "Frobnicate".contains("frob"); # False
say "Frobnicate".contains("frob", :smartcase); # True
say "Frobnicate".contains("FROB", :smartcase); # False
IO::Path.stem
The .stem method on IO::Path objects returns the .basename of the object without any extensions, or with the given number of extensions removed:
use v6.e.PREVIEW;
say "foo/bar/baz.tar.gz".IO.basename; # baz.tar.gz
say "foo/bar/baz.tar.gz".IO.stem; # baz
say "foo/bar/baz.tar.gz".IO.stem(1); # baz.tar
RakuAST
About one third of this year's work was done on the RakuAST (Raku Abstract Syntax Tree) project. It basically consists of 3 sub-projects, that are heavily intertwined:
Development of RakuAST classes that can be used to represent all aspects of Raku code in an object-oriented fashion.
Development of a grammar and an actions class to parse Raku source code and turn that into a tree of instantiated RakuAST objects.
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 of RakuAST classes other than that there were 440 of them at the start of the year, and 454 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, the RakuAST::Doc classes are documented because they have a more or less stable API to allow for the development of RakuDoc 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 by Stefan Seifert, picking up the compile-time handling refactor that Jonathan 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 the RAKUDO_RAKUAST environment variable to 1. The .legacy method on the Raku class will tell you whether the legacy (older) grammar is being used or not:
$ raku -e 'say Raku.legacy'
True
$ RAKUDO_RAKUAST=1 raku -e 'say Raku.legacy'
False
Localization
A cousin language was created: Draig, allowing you to write Raku code in Welsh!
Syntax Highlighting
The RakuAST::Deparse::Highlight module allows customizable Raku syntax highlighting of Raku code that is syntactically correct. It is definitely not usable for real-time syntax highlighting as it a. requires valid Raku code, and b. it may execute Raku code in BEGIN blocks, constant specifications and use statements.
A more lenient alternative is the Rainbow module by Patrick Böker.
RakuDoc
The final version of the RakuDoc v2.0 specification can now be completely rendered thanks to the tireless work of Richard Hainsworth and extensive feedback and proofreading by Damian Conway, as shown in these blog posts.
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 about 90 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!
Top comments (1)
Thank you for performing this important work. Raku is the only language that I can tolerate but also magically enjoy greatly: flow and features and human-centric design. It's a valuable contribution to the world and I want it to persist and grow. You all making that happen are doing something important and profound. Thanks again and Happy New Year.