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.
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.
[0] https://gist.github.com/raiph/849a4a9d8875542fb86df2b2eda892...
[1] https://thenewstack.io/larry-walls-quest-100-year-programmin...
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 initially thought this was about the programming language for roku and was a little disappointed it was about perl 6 changing names.
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
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.
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.
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.
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.
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.
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-...
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.
This guy is so amazing. Mad props to him.
[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
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.
https://www.rexify.org/ -- an automation framework
https://mojolicious.org/ -- amazing web framework
https://metacpan.org/pod/DBIx::Class::Manual - amazing ORM
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.
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...
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.
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.