Recently, the Perl 6 team approved a rename of the language to Raku. We sat down with Edument team member Jonathan Worthington to talk about what it means, and what lies ahead.
First of all, give us a quick recap on your involvement with the project so far.
The story goes all the way back to when I was a teenager, and responded to my parent’s suggestion that I get a small job by starting a web development business. I think they were expecting me to deliver newspapers or something, but I hate mornings and I’m not too fond of being rained on. And I grew up in England, where it rains. Anyway, Perl was the go-to language for the backend stuff at the time, so I bought myself the book Programming Perl. That was a good read; along the way I learned regexes, object orientation, closures, and had my first exposure to automated testing too.
Jonathan speaking at PerlCon in Riga 2019
Fast forward some years. I graduated from university, and had built a small web development business on the side, powered by Perl. At university I’d taken an interest in compilers, runtimes, type systems, formal semantics of programming languages, and other such fun topics. I noticed the Perl 6 project, and thought contributing to the compiler would be a nice way to give something back to the community.
I expected to do a few patches here and there. Instead, I ended up rearchitecting the compiler, implementing the meta-object system, founding and leading the development of a new virtual machine, and serving as concurrency and parallelism designer. These days, I’m dealing with language design issues more generally, as we work towards future language versions. And, at the other end of the stack, I’m working on escape analysis related optimizations in the virtual machine, which should give some nice performance improvements.
So, about the rename. How did that come about?
At the start of the Perl 6 development process, there was a Request For Comments - that is, proposals for how the language could change. Perhaps a few dozen were expected. Hundreds were submitted. Of course, they were all over the map, pulling in different directions, sometimes contradicting each other, sometimes identifying real problems but proposing weak solutions, and so forth. It goes without saying that you can’t design a language just by piling different people’s ideas together. You’ll end up with a mess of inconsistent and over-specific solutions, whereas what’s wanted is a set of well thought out solutions that compose well together.
Thus started the long, long, language design process. From the start it was always to be a breaking change. With time, it became clear in order to meet the design goals, a lot was going to have to change, both in terms of syntax and semantics. Furthermore, Perl has always pushed the boundaries of language design and implementation. As a language designer, Larry Wall is ambitious and works in the realm of what’s possible for the language implementor, not what’s easy. Or, as it was jokingly put, “torture the language implementor for the sake of the language user”.
Combine these forces with everything being done by a group of volunteers, and it was always going to take a long time. Some way into the process, it was decided that rather than being a successor to Perl 5, Perl 6 would be considered a sister language. This made clear that Perl 5 could continue to evolve and develop, while taking the pressure off Perl 6 development to prioritize getting a language and compiler release out the door fast, so the focus could be on making it good. (This is the “cheap, fast, good: choose 2” principal at work, and “cheap” was decided for us.)
While the “sister language” narrative largely worked out inside of the Perl community, it didn’t work out so well in the wider world. It wasn’t entirely unreasonable to hope it would. After all, when the film Terminator 2 came out, it didn’t mean that Terminator was now an obsolete film that nobody should watch any more. Similarly, just because there’s a Rochefort 10 beer doesn’t mean the Rochefort 8 isn’t also delicious and worth considering also, and the Airbus A380 existing hasn’t stopped airlines buying the A320. There’s plenty of precedent for related, but different, products differing by a number. However, there’s not so much when the product is a programming language, and ultimately, having to have a conversation about the relationship between Perl 5 and Perl 6 became a drag for everyone.
Another problem is the Perl brand, which is widely recognized - a good thing - but also carries a lot of baggage - a bad thing. Once, Perl was the goto language for backend web development. Given this was the time that the web was taking off, a lot of developers started writing a lot of Perl. And a lot of that code was awful. That’s not really anybody’s fault; things that we largely take for granted today in the architecture of web applications today were simply unheard of back then, and web applications written in Perl today - 5 or 6 - are typically factored in modern ways and pleasant to work on. Alas, to this day the name “Perl” carries with it the scars of its time as top dog, when most of us (me also) building web applications were still figuring out how on earth to do that.
The hope was that Perl 5 and Perl 6 together could work to reclaim the brand. There was a lot of effort on that, and some progress, but it was always going to be difficult; people don’t like having to change their mind! It was, in hindsight, also made more difficult by the things Perl 5 and Perl 6 had to say about themselves being somewhat different.
There were various discussions of renaming Perl 6 over the years. The matter has gradually shifted from a rename being a minority position easily disregarded, to being enthusiastically championed and rejected in fairly equal measure, and most recently to being championed by some, tolerated by some, and opposed by relatively few. Thus, a sufficient consensus arose around a rename.
And how do you feel about the outcome?
On the one hand, optimistic. Raku is an incredible and modern language, but so often people would see the word “Perl”, and not look any deeper (or make a linenoise joke, or ask if it’s not a legacy language). There were even cases of talks being given that showed off the language under an alias to an enthusiastic audience - and only revealed at the very end that they’d actually been watching a talk about Perl 6! Now we’ll be able to talk about the language without first addressing a whole range of misconceptions.
Similarly, I hope that those who continue to keep Perl 5 alive and steadily evolving will find the task of improving perceptions around the language at least a little easier, thanks to there being a simpler message.
At the same time, there’s also a little sadness. The name Perl means a lot to me; it’s not just a language, but a community - where I have made a lot of friends over the years. Happily, there’s plenty of enthusiasm to continue having shared conferences, and to continue being a single community with two languages that have similar design values, even if the syntax and semantics they use to realize them differ.
Where did the name “Raku” come from? Does it have a meaning?
It means “comfort” or “ease” in Japanese, which nicely reflects the goals of the language to be a comfortable programming experience - as mentioned earlier, often at the expense of those doing the language implementation!
The most popular compiler for the language is named “Rakudo”, which approximately means “way of the camel” (the camel being a symbol commonly associated with Perl) and also “paradise”. Thus, we can see it as a way to “do” the Raku language.
Outside of programming, “raku” is also associated with pottery - fitting, given the Perl 6 design process was triggered by somebody, frustrated at the difficulties of evolving Perl 5 - smashing a mug against the wall!
Test running and coverage feature in Comma, the Raku IDE
Edument has a number of products aimed at the Perl 6 developer. Will those be adopting the Raku name? Will there be other updates reflecting the change?
Gradually, yes. The latest release of Comma, our Raku IDE product, takes the very first steps, by:
Starting to recognize the new file extensions associated with the Raku language
Starting to recognize a raku executable as the interpreter
None of these are in common use yet, but it means that as folks start to use them, we’ll be ready. We shall also, in a future release, be making a pass through Comma to change everywhere on the user interface that references Perl 6 to instead say Raku.
Comma can identify ways to make code simpler, and automatically apply them
Cro, a set of libraries and tools most commonly used for building web applications, will need very few changes. The Rakudo team generally work hard to make sure that upgrading the compiler to a new version will not break existing code - including running the tests suites of all published modules against release candidates in order to find regressions that were not caught by the language specification test suite. The language rename is being treated in the same way; for example, while there will be a time to start adopting new file extensions, the current ones will be supported for years to come. Generally, we want to minimize the inconvenience to those already using the language.
The rename aside, I guess there’s plenty more things for Raku programmers to be looking forward to? Can you tell us about some of the things you and your team are working on?
There’s indeed plenty of exciting things ahead. Let’s start with the Comma IDE. It’s already the most powerful development tool available for Raku developers, but there’s still so much more we want to deliver!
An animation showing how you can explore how time is spent in an application using logging in Comma
Raku’s parallelism and concurrency features have proven popular, and being able to visualize what’s going on inside of such programs can bring a lot of understanding. We recently developed a means to annotate programs with logging of tasks, which can then be visualized live in the IDE. Further, we also annotated Cro, so out of the box you can visualize how HTTP requests flow through the pipeline, and where they spend their time (in middleware, in the request handler, and so forth). However, this is not the end of the story! We want to make it possible to visualize even programs without such annotations, as well as have information about garbage collections and optimization-related events placed on the same diagram, if the programmer wishes. We also plan to enhance the debugging experience for parallel and concurrent programs.
We also have lots of ideas for the profiler, and expect to bring heap snapshot analysis to Comma in the next few releases. The range of program analyses and transformations we can offer will also continue to grow, to help people develop more correct programs and refactor more efficiently. Grammars - used for writing parsers - have also proven a popular Raku feature, and so we’ll be looking at how we can improve the development experience around using those too, perhaps with some kind of live preview.
Cro is already a popular choice for writing web applications in Raku, but there’s still plenty more to do there. Cro was always envisioned as a general library for writing distributed systems, and so we’ll be providing ways to write pipelines that work against a message queue rather than processing web requests. However, we know web services and web applications make up the majority use of Cro today, so there will of course be a lot of focus on making things even better for those use-cases. In fact, the service story is currently a good bit stronger than the application story. We weren’t really trying to be a “web frramework”, but have ended up being used as one anyway; in reflection of that, we recently added a template language (and naturally are providing support for it in Comma too!) and will be looking at other things we can do to make such development more efficient. For those building or consuming services, we also plan to provide various resilience patterns, such as retires and circuit breakers, as well as support for easily building various kinds of proxy.
As for Raku itself, lots of people are doing lots of great work. I’ve been focusing heavily on performance and reliability over the last couple of years, and in the coming months expect to merge a bunch of my latest work on escape analysis. Raku is very object-y, and having optimizations that can completely eliminate, or at least put off, allocations, and allow us to analyze inside the object boundary, should offer some nice speedups for quite a lot of applications. Beyond that, I expect to be looking into ways to compile and execute grammars more efficiently.
Another big upcoming chunk of work will be on macros, which in turn involves providing an API to the language itself. The design of this has already been explored in a small experimental language, and now the task is to bring it to the full Raku language. This will also provide an opportunity to revisit a lot of the compiler internals, potentially making them more efficient.
Wow, so many plans! And it’s not just Raku that your team at the Prague office is doing, right?
Correct, we’re involved in a range of other projects for Edument customers. Our specialization is in compilers, runtimes, language design, and developer tooling, and we’re always excited to take on challenges in those areas. Happily, we’ve been able to get some such projects of late. So, we’re keeping busy, and suitably entertained!
Good luck with it all, and thanks for taking the time out to tell us about it!
You’re welcome!
With Jonathan Worthington