They show it on the landing page, but having first class support for CTF grammars is such an interesting niche for a language. Perl (Rake was originally Perl 6 if I recall) always had solid tooling for dealing with text manipulation, but adding context free grammars in directly is another level. I have to imagine it ends up being seldom used for a lot of applications, but I wonder if you end up with a "see nails when you have a hammer" situation (and not necessarily in a bad way).
I personally have never used a context free grammar outside of writing a programming language parser.
I first came across something like this in janet, which includes a PEG system in the standard library. It definitely changed how I think about text processing. Very much of the time what I find myself doing with regex is defining a grammar, but I didn't realize that. I wish more languages included the tools for it, it's a core operation of practical programming.
Yeah, I've never really considered using a grammar like that for string processing like they suggest. And it's the first thing they show. Maybe I'm missing out and I just haven't had the tooling.
It seems like a really nice language but which niche should it occupy?
Edited to add, now that I'm at a computer:
for 1 .. 100 {
when $_ %% (3 & 5) { say 'FizzBuzz'; }
when $_ %% 3 { say 'Fizz'; }
when $_ %% 5 { say 'Buzz'; }
default { .say; }
}
The multi sub version is interesting. I'm not quite sure what multi subs are, they seem to be performing a pre-function-call validation to choose which sub to use?
multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' }
multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' }
multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' }
multi sub fizzbuzz(Int $number ) { $number }
(1 .. 100)».&fizzbuzz.say;
Non-interactive shell scripting. It's actually the best language in this niche, outclassing Perl and Tcl in terms of features and Python/JS in terms of expressivity.
General purpose scripting. Orders of magnitude fewer packages and batteries than in Python or Ruby, but it does have a package manager and a bunch of libs for typical tasks. It's also capable of calling Python code almost seamlessly. For small (1 file) scripts, the expressivity of Raku means often half the lines of equivalent Python code, unless you hit a package that Python has and Raku doesn't.
Everything related to text processing. The grammars parsed by Grammars don't have to be context-free. Parsing just about anything is a joy. Also, light data mangling - if it fits in RAM, you might not need any other tool (like R/Pandas).
It's also a general-purpose, gradually typed, JIT-compiled, multiparadigm (OO, FP, procedural, array) language, so you can use just about anywhere you want. It's less great for mission-critical things (error handling is peculiar) and shell one-liners (the JIT takes a toll on startup time). It has a REPL, instead.
Fantastic answer, actually made me enthusiastic for Raku!
Now I want to go mess with it to see what it can do with some of my standard use cases. (DevOps infrastructure code, various AWS Lambdas, lots of build pipelines)
If you want a quick overview of what you can do with Raku (as opposed to what it is/how it works), I found this book to be nice: https://leanpub.com/raku-oneliners
Also, make sure to hop on Freenode (or Discord bridge to it), the community is very welcoming :)
To me Raku represents small-scale data mangling/processing and glue language for small scripting. Hacker oriented, personal and individualistic, not something you'd push in corporate. In many ways similar role what Python had decade ago, and Perl had two decades ago.
multi subs allow you to declare multiple overloaded versions of a function (subroutine, sub). Dispatch between sub bodies happens based on either the type(s) of arguments or based on a truth value of a "guard" - a boolean expression or boolean function placed after `where` in sub declaration head.
`%%` is a `modulo == 0` operator, which is surprisingly commonly needed.
`fizzbuzz(Int $ where * %% 15)` can also be written `fizzbuzz(Int $x where $x %% 15)` - the difference is that you don't have to name the argument just for the check. When `fizzbuzz` is called, all known definitions' guards are checked to see which will be entered.
The `*` in `* %% 15` is "whatever star", you can think of it as a short syntax for creating lambdas. There are multiple ways of constructing anonymous functions and blocks, you can get the same effect with `{ $_ %% 15 }`, `-> $a { $a %% 15 }`.
`»` is a "hyper operator"; the next method-call will be performed on all elements of a collection on the left. Groovy uses `*.` for this I think. You could use a `.map` method instead, `(1..100).map(&fizzbuzz)` or `.map({ .&fizzbuzz })` (`{ .meth }` is equivalent to `-> $x { $x.meth }`)
`.&` is a "call as method" operator: `fizzbuzz` is a function, so you can't call `1.fizzbuzz`, however, you can call `1.&fizzbuzz`.
Also, in the first solution, `(3 & 5)` is a Junction. This is an important concept that introduces a degree of nondeterminism to the language - well worth reading about! :)
There is https://sparrowhub.io and Sparky - devops tooling with Raku API ( disclosure - I am - the author ) which enables Raku for various automation and devops tasks
Not my experience with it: the language is indeed rich, but not overly so. The number of concepts you need to learn is comparable to (modern) Python or less. Raku is also very consistent, choosing to apply already existing concepts rather than invent a new one (when designers are forced to choose) most of the time. While you still have many ways of accomplishing each task, no language elements are dedicated to a single task.
As for operators - most of them are simply aliases for method names, you don't have to use them. However, some operators are representations of concepts that are not available through other means (e.g., `...`[1], circumfix `[]`, infix `Z`) The page you linked to makes no distinction and dumps everything that is syntactically an operator on a single page, resulting in a very long list. In practice, you don't need to remember more than a small fraction of them.
I use Raku for production. It's great for orchestration, or writing a quick server. Text manipulation and processing is amazing. I'm shocked it hasn't gotten more adoption in the LLM space. You would think someone would make a really great library to create AI Agents using Raku.
> You would think someone would make a really great library to create AI Agents using Raku.
Maybe, you mean using Raku to make:
1. Standalone, web based LLM agents
2. Plug-ins for ChatGPT (or other LLM providers)
3. LLM Retrieval Augmented Generation (RAG) functionalities, or services, or objects
Points 1 and 2 should be Raku-addressed sooner or later, but Raku provides nice alternatives to them. (See below.)
## LLMs at your fingertips
I would say, with the Raku LLM packages one can create "AI agents" on the spot:
- Programmatic ways to configure and execute LLM functions and chat objects.
- Using easy to compose LLM functions and easy to access prompts.
- Via Jupyter based notebooks with LLM-ready magic cells, aka "chatbooks."
In one chatbook multiple, global chats can be held with multiple LLM personas.
Also, each of the LLM-service access packages provides a Command Line Interface (CLI) script. That is another quick, "on the spot" type of access to AI.
The community is tiny. The fact that it was called "Perl6" for 20 years (Raku is from after 2019 I think) absolutely doesn't help in anything, the least in adoption. The historical churn in terms of VM (experimental in Haskell, dead Parrot, JVM, current MoarVM), the lack of planned features (macros!) for long years, and the slow death of Perl over a similar time frame - all that (and more) means not many people use it, even if they happen to know about it.
On the other hand, there's a similarly tiny - or smaller - community around Glamorous Toolkit (a Smalltalk distribution) that managed to produce one of the most hackable and rich LLM clients out there: https://github.com/feenkcom/gt4llmhttps://gtoolkit.com/ Here, though, LLMs are so close a match for the community interests that it just had to happen...
rakulang reddit has 1.5k members ... it's not Python or Rust yet ... but the community is very open and friendly and its great to rub shoulders with such knowledgable and committed folks
Yes, it is - you'll see I said precisely that in another comment here. :)
However, I will not yield in that it's tiny. Emacs sub on Reddit has 63k users, half of whom are Emacs Lisp programmers (by necessity). That's 20x more community members than Raku, and we're talking about a) a Lisp; and b) one bundled as an extension language for a text editor...
Raku currently has a community comparable to Smalltalk, Racket, or Haxe - enough to keep the lights on, but not much more than that. Similarly to them, Raku doesn't have any strategy for breaking into the mainstream. In effect, these communities don't grow over time. There's an "old guard" - a few dozen people - who are passionate about (and invested in) the project, but the retention of other users rarely exceeds a year or two.
I like Raku as a language, but the lack of hands shows. Imagine my surprise when a partially applied sub (`.assuming`) turned out to be 1000x (really) slower than an equivalent block. It's a known issue, just nobody had the time to work on optimizing it. RakuAST work is still ongoing 5 years later. There are other rough edges and unimplemented features, all still there because there is not enough contributors.
In any case: Raku is great, and its community is warm and friendly. At the same time, the community is tiny and Raku adoption most likely won't shoot up anytime soon. That doesn't mean you shouldn't use it, but you should be aware of the situation so that you can decide if it offers a suitable trade-off for you.
I'm glad you like raku and I won't split hairs over small vs. tiny.
Since you mention it, I would say that raku is yet to find its killer app. I think for general purpose languages in general, it is hard to predict this zeitgeist - you know Ruby was around for 10+ years before the famous 15 mins Rails video. Another effective strategy for breaking into the mainstream is to have the weight of a big/influential corporation behind you - Java(Sun), JS(Netscape), Go(oogle), Rust(AWS), F#(MS), Swift(Apple) ... that doesn't apply to raku either. I for one would be happy to have a strategy for this - and would welcome your thoughts on what this should contain.
In the meantime, I guess the hope for breaking into the mainstream is to do a solid job with language development. Recently the focus has been on Raku AST (which is a forerunner to Macros). The number of passing test-files with the new RakuAST grammar are now 142/153 (make test) and 1158/1355 (make spectest).
In addition to this, the community has actively taken over support for the raku IDE which was kindly donated by Edument ... Comma Plugin 2.0 is now available (IntelliJ IDEA plugin) along with several other tooling options.
Yes, there have been some (too many!) historic missteps - but the rakudo compiler / moarvm (runtime) combination has been the settled path since 2015.
I'm sorry to hear that `.assuming` was 1000x slower codepath for you and that issue was not fixed in a timely way. I choose to use raku in my business for small projects and throw away scripts, data munging and notebook work where the power of the language and ease of quickly getting to working code saves time. While I think a medium-large deployment to make a productised service is viable, it may still have to watch for and step around some gotchas like this.
I do contend that the raku community is sufficiently large and committed to deliver continuous improvement overall despite the high ambition and large surface area of the codebase ... perhaps latest GH stats would be a fairer metric (and I have not compared to LISP EMACS ;-) )...
> Since you mention it, I would say that raku is yet to find its killer app. [...] I for one would be happy to have a strategy for this - and would welcome your thoughts on what this should contain.
Please take a look at Glamorous Toolkit (https://gtoolkit.com/). Whether that's warranted or not, the authors claim to have invented a new paradigm of working with software systems. GT is marketed as a "moldable development environment" more than as a "Smalltalk dialect with dynamic, customizable UI."
Would finding a catchy phrase describing Raku programming help? I think it could. Or maybe there's already one that I'm not aware of?
Even better would be to find something that Raku is unusually well-suited for, better than all, save for just 1 or 2 contenders. Advertising Raku through that could have dramatic effects. However, this is harder to achieve with a general-purpose language. Fortunately, Raku doesn't lack in interesting features and I'm sure there are (still undiscovered or not publicized enough) domains where a particular combination of Raku's features make it one of the best tools for a job.
Once you manage to find a few such domains, it's only a matter of luck: at some point, any of these can become popular, elevating the language along with the use case. However, for luck to work, you need to have those domains thoroughly explored - the famous Rails video wouldn't exist without Rails.
> Another effective strategy for breaking into the mainstream is to have the weight of a big/influential corporation behind you [...] that doesn't apply to raku either.
You might try for corporate sponsorship or government grants. Both ways I know nothing about - I just notice that some work on Haxe is financed through industry grants, while some work on OCaml is paid for by the EU. In general, sustaining a project as large as a programming language is far outside of my expertise; I won't be of much help on that front :(
> In the meantime, I guess the hope for breaking into the mainstream is to do a solid job with language development.
Yes, that is a good strategy :) As mentioned above, getting into the spotlight and capitalizing on it is largely a matter of luck, and to make use of good luck, you first need a solid project.
> Recently the focus has been on Raku AST (which is a forerunner to Macros).
That's good - Raku has an infinity of ways for runtime metaprogramming, but almost none for compile-time metaprogramming. Standardized AST and macro support will be a very welcome addition to the language.
This might be a good time to mention: are you familiar with how Elixir is developed? I'm not too close to that community, but it looks like the Elixir folks split the work between the language proper and a flagship project of the year (roughly). Those flagships are projects that, ideally, make use of Elixir's unique features to build "best in class" solution. I think Ecto - data persistence library interfacing with RDBMSes - was the first such project. I don't remember the details, but there was a project for IoT (Nerves?) and later Numeric Elixir (numpy equivalent?) - and some other things in between. Phoenix and LiveView, too.
I think that's a pretty clever marketing strategy - everybody knows what an ORM (for example) is, so if you write a headline like "Ecto - the best non-ORM you never heard of" you have a chance to get an eyeball or two.
> In addition to this, the community has actively taken over support for the raku IDE which was kindly donated by Edument ... Comma Plugin 2.0 is now available (IntelliJ IDEA plugin) along with several other tooling options.
I didn't know, thanks for mentioning it. I'll definitely check it out.
> Yes, there have been some (too many!) historic missteps - but the rakudo compiler / moarvm (runtime) combination has been the settled path since 2015.
Agreed :)
> I'm sorry to hear that `.assuming` was 1000x slower codepath for you and that issue was not fixed in a timely way.
No, no, it wasn't that big of a deal at all! It was just an example of a "rough edge" that I think was left there because of a lack of manpower.
> I choose to use raku in my business for small projects
I don't have the luxury to use Raku in my day job, but I use it for small personal projects, mostly related to parsing things, and for general-purpose scripting.
> I do contend that the raku community is sufficiently large and committed to deliver continuous improvement overall despite the high ambition and large surface area of the codebase
Agreed - I'm sorry if it sounded too negatively, but that's what I meant by "keeping the lights on". Yes - Raku is moving in the right direction at a noticeable (non-glacial) pace. From the looks of it, the compiler and the VM are solid pieces of engineering and they are improving.
However, without a concurrent effort in marketing the language, preferably with some "killer apps" already in place, "just" doing a good job implementing the language might not be enough for Raku to succeed. That's my main worry :(
---
One thing that didn't fit above. Are there plans to improve static type checking in Raku? Raku looks gradually-typed, but actually isn't - most of the type checks happen on runtime, at least in my experience. This is very similar to Dylan language. Is there any work being done on strengthtening the type system and adding type inference, occurence typing, and (maybe) refinement types? It should be possible - I read a paper about adding gradual typing to Dylan, which also is based on multi-methods and multiple inheritance. So I think there's a lot of type-checking the compiler could (try to) do. IMO, going in this direction would help Raku codebases scale to larger projects.
EDIT: if you'd like to continue the discussion, please shoot me an email (in my profile).
Not sure; he was involved in the design in the 2000s, but I haven't seen him while I was active in the community. Some other prominent Perl community members are there (the kinder ones, I'm told).
They show it on the landing page, but having first class support for CTF grammars is such an interesting niche for a language. Perl (Rake was originally Perl 6 if I recall) always had solid tooling for dealing with text manipulation, but adding context free grammars in directly is another level. I have to imagine it ends up being seldom used for a lot of applications, but I wonder if you end up with a "see nails when you have a hammer" situation (and not necessarily in a bad way).
I personally have never used a context free grammar outside of writing a programming language parser.
I first came across something like this in janet, which includes a PEG system in the standard library. It definitely changed how I think about text processing. Very much of the time what I find myself doing with regex is defining a grammar, but I didn't realize that. I wish more languages included the tools for it, it's a core operation of practical programming.
https://janet-lang.org
Yeah, I've never really considered using a grammar like that for string processing like they suggest. And it's the first thing they show. Maybe I'm missing out and I just haven't had the tooling.
In https://rosettacode.org/wiki/FizzBuzz there's a nice Raku implementation, with ever-more-compact varieties following.
It seems like a really nice language but which niche should it occupy?
Edited to add, now that I'm at a computer:
The multi sub version is interesting. I'm not quite sure what multi subs are, they seem to be performing a pre-function-call validation to choose which sub to use?Non-interactive shell scripting. It's actually the best language in this niche, outclassing Perl and Tcl in terms of features and Python/JS in terms of expressivity.
General purpose scripting. Orders of magnitude fewer packages and batteries than in Python or Ruby, but it does have a package manager and a bunch of libs for typical tasks. It's also capable of calling Python code almost seamlessly. For small (1 file) scripts, the expressivity of Raku means often half the lines of equivalent Python code, unless you hit a package that Python has and Raku doesn't.
Everything related to text processing. The grammars parsed by Grammars don't have to be context-free. Parsing just about anything is a joy. Also, light data mangling - if it fits in RAM, you might not need any other tool (like R/Pandas).
It's also a general-purpose, gradually typed, JIT-compiled, multiparadigm (OO, FP, procedural, array) language, so you can use just about anywhere you want. It's less great for mission-critical things (error handling is peculiar) and shell one-liners (the JIT takes a toll on startup time). It has a REPL, instead.
Fantastic answer, actually made me enthusiastic for Raku!
Now I want to go mess with it to see what it can do with some of my standard use cases. (DevOps infrastructure code, various AWS Lambdas, lots of build pipelines)
If you want a quick overview of what you can do with Raku (as opposed to what it is/how it works), I found this book to be nice: https://leanpub.com/raku-oneliners
Also, make sure to hop on Freenode (or Discord bridge to it), the community is very welcoming :)
Thanks for the recommendation, I immediately bought that book. I'm a huge fan of people publishing on leanpub or similar :)
Freenode is actually dead: the Raku IRC channels are on libera.chat!
To me Raku represents small-scale data mangling/processing and glue language for small scripting. Hacker oriented, personal and individualistic, not something you'd push in corporate. In many ways similar role what Python had decade ago, and Perl had two decades ago.
multi subs allow you to declare multiple overloaded versions of a function (subroutine, sub). Dispatch between sub bodies happens based on either the type(s) of arguments or based on a truth value of a "guard" - a boolean expression or boolean function placed after `where` in sub declaration head.
`%%` is a `modulo == 0` operator, which is surprisingly commonly needed.
`fizzbuzz(Int $ where * %% 15)` can also be written `fizzbuzz(Int $x where $x %% 15)` - the difference is that you don't have to name the argument just for the check. When `fizzbuzz` is called, all known definitions' guards are checked to see which will be entered.
The `*` in `* %% 15` is "whatever star", you can think of it as a short syntax for creating lambdas. There are multiple ways of constructing anonymous functions and blocks, you can get the same effect with `{ $_ %% 15 }`, `-> $a { $a %% 15 }`.
`»` is a "hyper operator"; the next method-call will be performed on all elements of a collection on the left. Groovy uses `*.` for this I think. You could use a `.map` method instead, `(1..100).map(&fizzbuzz)` or `.map({ .&fizzbuzz })` (`{ .meth }` is equivalent to `-> $x { $x.meth }`)
`.&` is a "call as method" operator: `fizzbuzz` is a function, so you can't call `1.fizzbuzz`, however, you can call `1.&fizzbuzz`.
Also, in the first solution, `(3 & 5)` is a Junction. This is an important concept that introduces a degree of nondeterminism to the language - well worth reading about! :)
They're nearing apl density :)
You can program with APL density of you want. However, you don't have to!
it is true, but i wasn't complaining ;)
There is https://sparrowhub.io and Sparky - devops tooling with Raku API ( disclosure - I am - the author ) which enables Raku for various automation and devops tasks
For those who didn't know and read comments first:
Raku was originally known as Perl 6.
https://en.wikipedia.org/wiki/Raku_(programming_language)#Hi...
The main implementation is called Rakudo: https://en.wikipedia.org/wiki/Rakudo
"Raku" is Japanese for "camel" which is named after the O'Reilly book cover.
Raku is like the everything language. Reading its docs is a wild ride.
https://docs.raku.org/language/operators
Not my experience with it: the language is indeed rich, but not overly so. The number of concepts you need to learn is comparable to (modern) Python or less. Raku is also very consistent, choosing to apply already existing concepts rather than invent a new one (when designers are forced to choose) most of the time. While you still have many ways of accomplishing each task, no language elements are dedicated to a single task.
As for operators - most of them are simply aliases for method names, you don't have to use them. However, some operators are representations of concepts that are not available through other means (e.g., `...`[1], circumfix `[]`, infix `Z`) The page you linked to makes no distinction and dumps everything that is syntactically an operator on a single page, resulting in a very long list. In practice, you don't need to remember more than a small fraction of them.
[1] https://docs.raku.org/language/operators#infix_%2E%2E%2E
I've doing some text processing in Raku for the past two weeks. It has been a pleasant and efficient experience.
I use Raku for production. It's great for orchestration, or writing a quick server. Text manipulation and processing is amazing. I'm shocked it hasn't gotten more adoption in the LLM space. You would think someone would make a really great library to create AI Agents using Raku.
## Clarification
Can you clarify what do you mean by:
> You would think someone would make a really great library to create AI Agents using Raku.
Maybe, you mean using Raku to make:
1. Standalone, web based LLM agents 2. Plug-ins for ChatGPT (or other LLM providers) 3. LLM Retrieval Augmented Generation (RAG) functionalities, or services, or objects
LLM RAG (point 3) is supported in Raku, see: "Raku RAG demo", https://youtu.be/JHO2Wk1b-Og .
Points 1 and 2 should be Raku-addressed sooner or later, but Raku provides nice alternatives to them. (See below.)
## LLMs at your fingertips
I would say, with the Raku LLM packages one can create "AI agents" on the spot:
- Programmatic ways to configure and execute LLM functions and chat objects. - Using easy to compose LLM functions and easy to access prompts.
- Via Jupyter based notebooks with LLM-ready magic cells, aka "chatbooks."
In one chatbook multiple, global chats can be held with multiple LLM personas.
Also, each of the LLM-service access packages provides a Command Line Interface (CLI) script. That is another quick, "on the spot" type of access to AI.
## References
Please see these Raku LLM packages: https://raku.land/?q=LLM
The community is tiny. The fact that it was called "Perl6" for 20 years (Raku is from after 2019 I think) absolutely doesn't help in anything, the least in adoption. The historical churn in terms of VM (experimental in Haskell, dead Parrot, JVM, current MoarVM), the lack of planned features (macros!) for long years, and the slow death of Perl over a similar time frame - all that (and more) means not many people use it, even if they happen to know about it.
On the other hand, there's a similarly tiny - or smaller - community around Glamorous Toolkit (a Smalltalk distribution) that managed to produce one of the most hackable and rich LLM clients out there: https://github.com/feenkcom/gt4llm https://gtoolkit.com/ Here, though, LLMs are so close a match for the community interests that it just had to happen...
rakulang reddit has 1.5k members ... it's not Python or Rust yet ... but the community is very open and friendly and its great to rub shoulders with such knowledgable and committed folks
> but the community is very open and friendly
Yes, it is - you'll see I said precisely that in another comment here. :)
However, I will not yield in that it's tiny. Emacs sub on Reddit has 63k users, half of whom are Emacs Lisp programmers (by necessity). That's 20x more community members than Raku, and we're talking about a) a Lisp; and b) one bundled as an extension language for a text editor...
Raku currently has a community comparable to Smalltalk, Racket, or Haxe - enough to keep the lights on, but not much more than that. Similarly to them, Raku doesn't have any strategy for breaking into the mainstream. In effect, these communities don't grow over time. There's an "old guard" - a few dozen people - who are passionate about (and invested in) the project, but the retention of other users rarely exceeds a year or two.
I like Raku as a language, but the lack of hands shows. Imagine my surprise when a partially applied sub (`.assuming`) turned out to be 1000x (really) slower than an equivalent block. It's a known issue, just nobody had the time to work on optimizing it. RakuAST work is still ongoing 5 years later. There are other rough edges and unimplemented features, all still there because there is not enough contributors.
In any case: Raku is great, and its community is warm and friendly. At the same time, the community is tiny and Raku adoption most likely won't shoot up anytime soon. That doesn't mean you shouldn't use it, but you should be aware of the situation so that you can decide if it offers a suitable trade-off for you.
I'm glad you like raku and I won't split hairs over small vs. tiny.
Since you mention it, I would say that raku is yet to find its killer app. I think for general purpose languages in general, it is hard to predict this zeitgeist - you know Ruby was around for 10+ years before the famous 15 mins Rails video. Another effective strategy for breaking into the mainstream is to have the weight of a big/influential corporation behind you - Java(Sun), JS(Netscape), Go(oogle), Rust(AWS), F#(MS), Swift(Apple) ... that doesn't apply to raku either. I for one would be happy to have a strategy for this - and would welcome your thoughts on what this should contain.
In the meantime, I guess the hope for breaking into the mainstream is to do a solid job with language development. Recently the focus has been on Raku AST (which is a forerunner to Macros). The number of passing test-files with the new RakuAST grammar are now 142/153 (make test) and 1158/1355 (make spectest).
In addition to this, the community has actively taken over support for the raku IDE which was kindly donated by Edument ... Comma Plugin 2.0 is now available (IntelliJ IDEA plugin) along with several other tooling options.
Yes, there have been some (too many!) historic missteps - but the rakudo compiler / moarvm (runtime) combination has been the settled path since 2015.
I'm sorry to hear that `.assuming` was 1000x slower codepath for you and that issue was not fixed in a timely way. I choose to use raku in my business for small projects and throw away scripts, data munging and notebook work where the power of the language and ease of quickly getting to working code saves time. While I think a medium-large deployment to make a productised service is viable, it may still have to watch for and step around some gotchas like this.
I do contend that the raku community is sufficiently large and committed to deliver continuous improvement overall despite the high ambition and large surface area of the codebase ... perhaps latest GH stats would be a fairer metric (and I have not compared to LISP EMACS ;-) )...
https://github.com/rakudo/rakudo/pulse/monthly... Excluding merges, 11 authors have pushed 146 commits to main and 258 commits to all branches.
> Since you mention it, I would say that raku is yet to find its killer app. [...] I for one would be happy to have a strategy for this - and would welcome your thoughts on what this should contain.
Please take a look at Glamorous Toolkit (https://gtoolkit.com/). Whether that's warranted or not, the authors claim to have invented a new paradigm of working with software systems. GT is marketed as a "moldable development environment" more than as a "Smalltalk dialect with dynamic, customizable UI."
Would finding a catchy phrase describing Raku programming help? I think it could. Or maybe there's already one that I'm not aware of?
Even better would be to find something that Raku is unusually well-suited for, better than all, save for just 1 or 2 contenders. Advertising Raku through that could have dramatic effects. However, this is harder to achieve with a general-purpose language. Fortunately, Raku doesn't lack in interesting features and I'm sure there are (still undiscovered or not publicized enough) domains where a particular combination of Raku's features make it one of the best tools for a job.
Once you manage to find a few such domains, it's only a matter of luck: at some point, any of these can become popular, elevating the language along with the use case. However, for luck to work, you need to have those domains thoroughly explored - the famous Rails video wouldn't exist without Rails.
> Another effective strategy for breaking into the mainstream is to have the weight of a big/influential corporation behind you [...] that doesn't apply to raku either.
You might try for corporate sponsorship or government grants. Both ways I know nothing about - I just notice that some work on Haxe is financed through industry grants, while some work on OCaml is paid for by the EU. In general, sustaining a project as large as a programming language is far outside of my expertise; I won't be of much help on that front :(
> In the meantime, I guess the hope for breaking into the mainstream is to do a solid job with language development.
Yes, that is a good strategy :) As mentioned above, getting into the spotlight and capitalizing on it is largely a matter of luck, and to make use of good luck, you first need a solid project.
> Recently the focus has been on Raku AST (which is a forerunner to Macros).
That's good - Raku has an infinity of ways for runtime metaprogramming, but almost none for compile-time metaprogramming. Standardized AST and macro support will be a very welcome addition to the language.
This might be a good time to mention: are you familiar with how Elixir is developed? I'm not too close to that community, but it looks like the Elixir folks split the work between the language proper and a flagship project of the year (roughly). Those flagships are projects that, ideally, make use of Elixir's unique features to build "best in class" solution. I think Ecto - data persistence library interfacing with RDBMSes - was the first such project. I don't remember the details, but there was a project for IoT (Nerves?) and later Numeric Elixir (numpy equivalent?) - and some other things in between. Phoenix and LiveView, too.
I think that's a pretty clever marketing strategy - everybody knows what an ORM (for example) is, so if you write a headline like "Ecto - the best non-ORM you never heard of" you have a chance to get an eyeball or two.
> In addition to this, the community has actively taken over support for the raku IDE which was kindly donated by Edument ... Comma Plugin 2.0 is now available (IntelliJ IDEA plugin) along with several other tooling options.
I didn't know, thanks for mentioning it. I'll definitely check it out.
> Yes, there have been some (too many!) historic missteps - but the rakudo compiler / moarvm (runtime) combination has been the settled path since 2015.
Agreed :)
> I'm sorry to hear that `.assuming` was 1000x slower codepath for you and that issue was not fixed in a timely way.
No, no, it wasn't that big of a deal at all! It was just an example of a "rough edge" that I think was left there because of a lack of manpower.
> I choose to use raku in my business for small projects
I don't have the luxury to use Raku in my day job, but I use it for small personal projects, mostly related to parsing things, and for general-purpose scripting.
> I do contend that the raku community is sufficiently large and committed to deliver continuous improvement overall despite the high ambition and large surface area of the codebase
Agreed - I'm sorry if it sounded too negatively, but that's what I meant by "keeping the lights on". Yes - Raku is moving in the right direction at a noticeable (non-glacial) pace. From the looks of it, the compiler and the VM are solid pieces of engineering and they are improving.
However, without a concurrent effort in marketing the language, preferably with some "killer apps" already in place, "just" doing a good job implementing the language might not be enough for Raku to succeed. That's my main worry :(
---
One thing that didn't fit above. Are there plans to improve static type checking in Raku? Raku looks gradually-typed, but actually isn't - most of the type checks happen on runtime, at least in my experience. This is very similar to Dylan language. Is there any work being done on strengthtening the type system and adding type inference, occurence typing, and (maybe) refinement types? It should be possible - I read a paper about adding gradual typing to Dylan, which also is based on multi-methods and multiple inheritance. So I think there's a lot of type-checking the compiler could (try to) do. IMO, going in this direction would help Raku codebases scale to larger projects.
EDIT: if you'd like to continue the discussion, please shoot me an email (in my profile).
please try googling "raku llm" ... there is a lot of excellent thought leadership work from folks like antononcube
is larry wall at all engaged with raku?
Not sure; he was involved in the design in the 2000s, but I haven't seen him while I was active in the community. Some other prominent Perl community members are there (the kinder ones, I'm told).
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.