lizmat

or

raku -e 'say "etbjxntqrdke".comb.map(*.succ).join'

* No separate types of bytestrings versus sequences of unicode codepoints.

Fixed in Raku. You either have a string (Str) or a bytestream (Blob).

* Wherever there's strings in any non-trivially-sized real-word Perl 5 project, there is utter irreversible and irredeemable mojibake.

No mojibake in Raku.

* No canonical way to do object-orientation. (cf. blessed objects, Moo in different versions, and different conventions around how to use them) -- This stuff should be easy in 2026. Perl makes this easy thing really hard.

Raku has single object / type system.

* Regexes suck. Their brevity is a nice circus stunt for a computer science audience, but unless you follow very particular patterns for composing them from ergonomically named constants, etc. etc. (which "in the wild" I rarely see), they are very unergonomic.

Raku regexes allow arbitrary whitespace, can contain comments and are composable.

Grammars are collections of tokens / rules / regexes that can be used to build an AST, and actions that can take that AST and build another data structure of it. A grammar is used to parse Raku itself.

Grammars can be subclassed or have rules / regexes mixed in (slangs).

* The Perl 5/CPAN ecosystem has been left to rot and is no longer safe for consumption.

The Raku ecosystem, albeit much smaller, is growing and actively maintained: https://raku.land

And the original blog post from almost a year ago: https://dev.to/lizmat/towards-a-raku-foundation-3ne2

From a blog post, to a problem solving issues, to passing a lot of hurdles: The Raku Foundation is here!

https://dev.to/lizmat/a-year-later-a-trf-1lh0

The Rakudo implementation of the Raku Programming Language uses the MoarVM, which is pretty much a generic VM. All you need to do(TM) is write a grammar and associated actions to build the right bytecode out of the given Python source.

It also goes from source code to AST:

  $ raku -e 'say Q|say "Hello World!"|.AST'
  RakuAST::StatementList.new(
    RakuAST::Statement::Expression.new(
      expression => RakuAST::Call::Name::WithoutParentheses.new(
        name => RakuAST::Name.from-identifier("say"),
        args => RakuAST::ArgList.new(
          RakuAST::QuotedString.new(
            segments   => (
              RakuAST::StrLiteral.new("Hello World!"),
            )
          )
        )
      )
    )
  )

In the raku example, what if the elements were to be multiplied?

$ raku -e 'say (0, 1, 2, * × * ... )[^10]' # for readability (0 1 2 2 4 8 32 256 8192 2097152)

$ raku -e 'say (0, 1, 2, * * ... *)[^10]' # for typeability (0 1 2 2 4 8 32 256 8192 2097152)

Nothing stopping you from creating a L10N::LA module :-)

You mean like:

    my $a of Int = 42;
    say $a;  # 42

    my $a of Int = "foo";'       
    # Type check failed in assignment to $a; expected Int but got Str ("foo")

?

FWIW, cannot reproduce on Safari 18.6 on MacOS 15.6.1

Technically, no. As Rakudo is not a programming language, and Perl6 is a deadname.

But there are indeed plenty of people doing projects with the Raku Programming Language.

Please, stop deadnaming the Raku Programming Language :-)

There is a Perl 5 compatibility mode: it's called Inline::Perl5.

Maybe not the one that was originally planned. But that was only a real possibility if Perl 5 would be able to get rid of its XS addiction.

Ask yourself: how many of the up river Perl modules are Perl only?

Sadly, that's just Num.gist showing 1.0 as "1" though.

say (pi/pi).^name; # Num

Actually, a module can implement any export heuristics by supplying an EXPORT subroutine, which takes positional arguments from the `use` statement, and is expected to return a Map with the items that should be exported. For example:

    sub EXPORT() { Map.new: "&frobnicate" => &sum }

Note that the EXPORT sub can also be a multi, if you'd like different behaviour for different arguments.

Everybody is entitled to their opinion, whether they'd be Raku developers or not.

The Raku Programming language allows one to specify the required version, the required authority and API level:

use Foo::Bar:ver<0.1.2+>:auth<zef:name>:api<2>;

would only work if the at least version 0.1.2 of the Foo::Bar module was installed, authored by "zef:name" (basically ecosystem + nick of author), with API level 2.

Note that modules can be installed next to each other that have the same name, but different authorities and different versions.

Imports from modules are lexical, so one could even have one block use one version of a module, and another block another version. Which is handy when needing to migrate date between versions :-)

Hi Perlgeek, long time no see!

I really wish more people would use Raku :-) Because it is all built in there already! :-)

those numbers show that Perl and Tcl, both "full featured" scripting languages, don't have the least issue on the matter.

Anybody using modern Perl will most likely also use Moose, and probably big integers as well. If you compare startup times with Perl / Moose / big integers with Rakudo (on the same Intel hardware as before):

% time perl -MMoose -Mbigint -e '' real 0.20s user 0.14s sys 0.02s

% time rakudo -e '' real 0.16s user 0.15s sys 0.04s

And suddenly, Raku starts up faster than Perl! Because Raku comes with a Moose like object system and big integers out of the box, it doesn't need to do anything special to give you those features.

So in a way, you're comparing apples with oranges when you're just comparing bare startup times. Because you are not considering the feature set you get with a bare startup.

So your remark was definitely NOT very nice.

Startup time is not the strong point of Rakudo. And it will be a long time before it will.

Beyond startup, performance definitely has attention of the core developers: that's when hot code gets inlined, and JITted to machine code if you're on Intel hardware. But before that, currently not so much.

The best possible startup time that could potentially be reached in the current implementation of Rakudo, is the bare startup time of NQP in which Rakudo is basically implemented. Compare NQP on an Intel 2.4 GHz i9 on MacOS:

% time nqp -e '' real 0.04s user 0.03s sys 0.01s

with:

% time rakudo -e '' real 0.15s user 0.15s sys 0.03s

With NQP taking about 16MB of memory.

Raku as a language is selected for its features, its community and possibly for its promise. Whether that is a disaster or not, is up to the user.

Finally, if you want fast startup, don't use a scripting language.

If this was about my former $work:

The company using Perl was able to double its turnover in 3 weeks.

The company using Java was still in the design phase.

Companies choose their tools depending on their internal culture. The company using Perl at the time was simply more agile.

FWIW, the company that was using Perl is now using Java mostly. And yes, the culture of the company has changed. Not sure about cause and effect.

Fundamentally, Raku regexes are very much like subroutines...

And if they're part of a grammar, they're essentially methods on a class. And a class that can be sub-classed. Or have roles mixed in, consisting of regexes.

Raku has the [Instant](https://docs.raku.org/type/Instant) class:

"An Instant is a particular moment in time measured in atomic seconds, with fractions. It is not tied to or aware of any epoch."

Not actively, not anymore.

Very occasionally (maybe once a year) he will post a comment on an issue. But that's about it.

In other words: (hopefully happily) enjoying his retirement.

You can program with APL density of you want. However, you don't have to!

Freenode is actually dead: the Raku IRC channels are on libera.chat!

Yeah, it was. Sorry, misread :-)

The current definition:

An ordinary identifier is composed of a leading alphabetic character which may be followed by one or more alphanumeric characters. It may also contain isolated, embedded apostrophes ' and/or hyphens -, provided that the next character is each time alphabetic.

https://docs.raku.org/language/syntax#Ordinary_identifiers

This means that '2-5-7' is NOT an identifier but the numerical value -10.

I think Raku is an interesting language and that people should check it out, to be clear

I agree :-)

That doesn't mean I agree with every choice the Rakudo implementation has made

Indeed. Some of these choices have their roots in the late 1990's / early 2000's. Some of them make less sense now than they did then. FWIW, these are continuously evaluated by the current core team, to continue to improve Rakudo.

It builds a lookup table of grapheme clusters, and represents them in memory as negative i32s.

Only for those grapheme clusters that do not have a representation in Unicode!

Also, these negative i32s are really an implementation detail.

but O(1) access to each grapheme is less important

Unless you want regexes to be a. correct in the unicode world, and b. be performant