Interest & Engage the Next 1000 Raku coders

[librasteve]

This Issue is inspired by ...

Crossing-The-Chasm

In Crossing the Chasm, a beachhead is the initial, narrowly defined target market a company focuses on to successfully cross from early adopters to the mainstream market.

Moore uses the military metaphor to mean:

• Pick one specific customer segment with a critical, urgent problem.
• Deliver a whole product that fully solves that problem better than anyone else.
• Win dominant adoption in that niche first.

Once the beachhead is secured, the company can expand to adjacent markets from a position of credibility and momentum, rather than trying to win the entire mainstream market at once.

---

This issue is for us all to discuss and hopefully to achieve consensus on a plan.

---

In today's weekly, I wrote the words below:

How many devs woke up this morning and thought "today I need an expressive, multi‑paradigm, Open Source language that works the way you think"?

I have set myself a goal for 2026: - "interest & engage the next 1000 Raku coders". My thesis is, we need to pool resources and focus on a small number (1?) of exemplar applications that can be a showcase for our fantastic language.

Note: This motto came out of a long discussion and I 100% support it as the best way to describe Raku as a general purpose programming language.... nevertheless I do not think that we will achieve the goal unless we take our story out there and show how it solves a real problem to a group of devs.

The results of my recent ad hoc Poll are in:

Initial thoughts:

• Overall response was pretty meh - 12 votes from 760 views ;-(
• LLM did worse than I thought (even though I voted for it!), and DSLs better
• DSLs is the clear winner in this self selected sample of insiders

Thanks to Melezhik for proposing automation, devops and config mgmt

I think this is telling us that if we are to be successful getting the next 1000 Raku converts in 2026, we need to do much more to present the case for DSLs (the why?) and the strengths of Raku Grammars (the how?) to a wider audience. The sceptic in me asks 'how many devs out there wake up thinking: "I need a DSL to solve my problem, what's the best way to do that?"'. The optimist says (i) there must be a fair few, (ii) we can work on code and docs that show how Raku is a solution to that need, (iii) could well be a few thousand devs per year doing mini DSLs (and we only need 1000, eh?) and (iv) this is a well defined subset of devs where Raku has a clear, compelling, distinctive advantage.

Both LLMs and IaC (Infrastructure as Code) are large aspects of DSL tooling in general and we are fortunate to have both these key components in good shape.

Please bear in mind that this is a deliberate narrowing of the messaging of Raku to concentrate on a beachhead application, where Raku has clear and compelling distinctive advantages. This is a choice to not focus on the other applications, but in the words of Scott McNealy "put all the wood behind one arrow".

Always thankful to the wisdom of the community.

https://rakudoweekly.blog/wp-content/uploads/2025/12/screenshot-2025-12-22-at-10.44.35.png

[markldevine]

This case isn't likely to be a hot button for many, but it's mine. I routinely use two things in my computing life, and I probably will until AGI is in every wristwatch and we're governed by the ASI overlords:

(1) Programmatic flows in Raku
(2) Process flows in BPMN

I use these to communicate to AI for downstream outputs/outcomes. This appears to be my new career. Unambiguously and comprehensively communicating model/flow intent to the silicon genius seems to take most of my time nowadays.

Raku is astonishingly elegant with both WRITE-flow-velocity AND READ-instant-grokability. Being a deterministic programming language, it UNAMBIGUOUSLY communicates to AI. I write Raku services for my life/work, but when they're the 24/7/365 type, I tell AI to 'convert this to Rust'. BAM! The resulting daemon runs in a sliver of RAM, clocking a single CPU second per day -- set and forgotten about. I don't know Rust in the slightest. Attempting to achieve fluency in yet-another-language is not on my menu. No, I am fluent enough in what I consider the ultimate human programming language -- Raku. It is my choice as the last programming language that I will ever use. With such high expressivity, I use it directly & for downstream outcomes (thanks to our new friend, AI).

((BPMN/DRD/DMN to express a process flow. It's another slang with an aesthetic/art. Although it isn't as unambiguous as a well-defined programming language, it works well enough with the machines. Quite well, actually. Thankfully, AI usually intuits what I mean by it.))

We will be communicating to the machines for 15-20 more years, to hazard a guess. NLP is there, and I received A's in my native language courses in school, but NLP leaves a lot of specifications on the table unless you write long, onerous essays.

We need unambiguous tools to communicate our intent to AI and Raku is a great one.

"Communicate your model to AI with Raku".

[librasteve]

@markldevine - thank you very much for your feedback. To me, this is very interesting from a "how to make Raku attractive to the next 1000 users".

As a reminder (for others also), the items in the Poll were:

• LLM Prompt Engineering (eg LLM::Function on Jupyter) [2]
• Web Development (eg HARC stack and Air) [4]
• Grammars for Domain Specific Languages (eg Vixen) [6]
• Multilingual Product Documentation (eg Elucid8 / Rakudoc) [0]
• automation , devops and configuration management [1]

(the last one is a "write in" from Melehzik)

Would it be fair to characterise your model as "LLM Prompt Engineering..."? [or a subset of that, or that with a twist]
or
Is it a new "write in" item?

[markldevine]

@markldevine - thank you very much for your feedback. To me, this is very interesting from a "how to make Raku attractive to the next 1000 users".

As a reminder (for others also), the items in the Poll were:

• LLM Prompt Engineering (eg LLM::Function on Jupyter) [2]
• Web Development (eg HARC stack and Air) [4]
• Grammars for Domain Specific Languages (eg Vixen) [6]
• Multilingual Product Documentation (eg Elucid8 / Rakudoc) [0]
• automation , devops and configuration management [1]

(the last one is a "write in" from Melehzik)

Would it be fair to characterise your model as "LLM Prompt Engineering..."? [or a subset of that, or that with a twist] or Is it a new "write in" item?

(I think my personally frequent case is either a strange outlier or I'm early.) How about a write-in: "Rapid Prototyping", which is the primary characteristic of this activity, essentially. I make a blueprint in Raku spec, then either use it as is or send the blueprint to manufacturing.

[tbrowder]

I think a good step is to advertise how much better and easier it is to learn Raku as an early part of a young coder's life (as a stark contrast to Python3). I know there are many obstacles in the way--especially in most public schools in the US--but I see two or more separate parts:

1. Prepare a short summary of how Raku is better than Python when comparing the core language.

2. Prepare a longer document in two columns comparing how to do certain common tasks in Raku versus Python.

3. Prepare one or more PDF slide presentations to give to various audiences such as:

   • Parent Teacher Association (PTA) meetings
   • Senior Center presentations (get grandprents interested for their children and grandchildren)
   • Guest lecturer for middle and high school coding classes
   • Guest lecturer for college level coding classes

In all cases be prepared to address questions about speed and multiple ways to do things in Raku. I believe one of Raku's strengths is possibly being easier for autistic or ADHT or dyslectic people to use than Python.

And don't forget to mention the ability to use other languages with Raku.

[nige123]

Sorry I missed the poll.

Software supply chain attacks, a tsunami of AI slop code, and corporate liability for dodgy software (including open source) - is an itch that will only need scratching.

Love the idea of putting all the wood behind one arrow!

Riffing on the previous comments .... a would-like-to-have Raku utility to reach the next 1000 devs and beyond could be something like:

shell> zef install rakuref
shell> rakuref describe <github:repo/some-code-in-another-language>

Slurping code.

Translating to Human  + AI-ready spec.

           rakuref.rakudoc 
           rakuref.html

Please use this software contract in future LLM prompts. 

shell> rakuref status

The current project is 95% described.

5% of prerequisites are not yet described.

Please invite or add the following repositories/prerequisites to join:

<some-other-project>
<another-project>
<and-another-project>

Later, if things take off, The Raku Foundation could offer the use of a certification trade mark for an annual subscription fee.

[markldevine]

I haven't worked out a segue to this, so I'm just going to blurt.

I saw so many fantastic possibilities with Raku when I went through my one-big-cover-to-cover documentation read circa 2015. MOP, idioms, design. That's where I saw a giant leap forward. Serious show-off potential. I started my Perl6 journey by pulling Promises the hard way, then Johathon posted a Reddit response with a react idiom. "I have to write that down!". Cro router has a cool mechanism in 'route' that results in a stellar syntax, but I only understood it when I was reading about it years ago. A dozen of these things went by, and I lost most of them. I remember once I asked the mailing list for a way to intercept an accessor and modify the standard behavior (effectively a simple wrap operation via a trait), and someone graciously gave me the magic incantation -- worked great!

These magic incantations make Raku unbelievably malleable. The result can be unprecedented code elegance. But with traditional knowledge transfer, only those with great note-taking skills or eidetic memory (or core devs) can recall all of the mechanisms.

How about pretraining (or whatever "training" mechanism is en vogue) to create a Raku AI guru that can readily expose what makes Raku ridiculously extraordinary but is typically out-of-reach to most? I will be asking any/all AIs Raku MOP, asynchronous, parallelism, concurrency questions for the next two decades, whether they're good at it or not. If we had an AI that could unlock the super-features, that might open a hangar-sized door to the world.

[librasteve]

OK, that's a fantastic set of great ideas - thanks to all for your contribution.

I hope that I have made the case that it would be best for us to focus on one idea that we can get behind as a community - and then to create a critical mass of assets ... code, libs, examples, tools, case studies and so on .

I want to give each of the leading ideas proper consideration, since the hardest part is to choose a path. I believe that having a well-defined path is better than just spreading our efforts. I will commit my "2026 Raku tuits" to this and I would welcome you to join.

For this final selection, I have cut to a shortlist of 3 - those that got 2 votes or more in the poll. There were some write-ins (i) automation, devops and configuration management, (ii) SBOM tooling for all languages and (iii) markdevines AI things (more on that below). So I judge those to have 1 vote each. Sorry if your favourite did not make the cut, I hope that you will understand that we cannot focus on everything and that you will join the effort to get the final choice(s) to critical mass.

The advice from Crossing The Chasm is to pick a new emerging segment shortly after its inception and before the leaders get established, then ride the growth of the segment. This strategy sidesteps the "fight the noise" challenge. If you get in early, then you can shape the evolution and definition of the segment.

LLM Prompt Engineering

When I set up the poll, this option seemed like a strong contender to me. There is already a good base of Raku LLM oriented modules (LLM::Function) and so on, and we have some strong expertise working on this already (Anton). I voted for this in the poll and I was surprised that it did not come top.

In general, LLM is a very strong trend in the wider developer community. Raku is arguably well suited as a prompt engineering language. On the surface, a big market with high growth and a lot of attention. Our challenges would be to have Raku stand out above the LLM noise. Since we are now a couple of years behind the starting gun of LLM (eg the release of ChatGPT), establishing Raku one of the top 3 [1] prompt engineering tools is going to be practically impossible.

The advice from Crossing The Chasm is to pick a new emerging segment shortly after its inception and before the leaders get established, then ride the growth of the segment. This strategy sidesteps the "fight the noise" challenge. If you get in early, then you can shape the evolution and definition of the segment. In the light of this, my current feeling is that LLM prompt engineering in general is too large and that we are too late.

Web Development

About a year ago, I set out to write a new web application library (the Raku Air module) to combine HTMX, Red and Cro in a differentiated way (the HARC stack). The main driver was to scratch a personal itch to code websites in Raku in a functional style (like Elmlang), but I also had an eye on what could be the "Rails of Raku". This has always been a stretch, and the segment that this targets (HTMX for web development) is very centered on the most popular languages (Go, Python, Rust, etc). It was no surprise that this option did poorly on the poll (actually that it came as high as 3rd was a pleasant surprise).

After several months of promoting HARC stack to the HTMX community (ie a subset of web developers that self select to be interested in trying things other than React), I can report a modest interest. You may recall that I posted about once a week to both the Rakuland and HTMX sub-reddits. This outbound publicity resulted in about 300 unique visitors a month to https://harcstack.org. I don't have any correlation to existing Rakuteers or new Raku recruits from these metrics. And the materials are admittedly quite weak.

The target segment for HARC stack is "HTMX devs who want to code in functional style on the server", a sub-segment of "HTMX devs who want to code in their preferred language on the server". The main segment has competitive alternatives such as GOTHH (Go), HARM (Rust), FastHTML (Python), etc. The existence of competition is good - this proves that there is demand and that others are trying to serve it. The HARC differentiator is "code in functional style", in this IMO it is quite unique and sustainably differentiated (there may be a Kotlin or Ocaml HTMX stack at some point in the future) - we do have the opportunity to position HARC as the leader. So I think that this option is viable to continue - BUT noting that the interest levels need ot be more like 1000 new visitors a month with 10% conversion rate to achieve the goal. Also to note that the main friction appears to be coming from needing recruits to switch from their favourite language (Go, Python, etc) to Raku for stylistic preference only.

Grammars for Domain Specific Languages

DSLs is the clear winner of the poll. I was very surprised tbh. Of course, when you think about it that should be no surprise at all. This is Raku's most substantial differentiator from other PLs. The more I think about it and research it, the more obvious it becomes as a target segment.

What I like about this is:

• DSLs are a well known idea (that has been around for years)
• DSLs are a core strength and differentiator for Raku
• There are many examples of DSLs (Slangs) in Raku
• There is a clear path to make a Raku DSL (Slangify)
• There are indeed devs out there who wake up every day and think "I need a DSL to solve my problem"

What I am less sure about is:

• Are there enough devs who want DSLs to make a big enough segment
• What is the segment timing for DSLs --- it seems to have started some years ago, then faded
• What is holding back the emergence of a real DSL segment / opportunity

Of course, my friend ChatGPT provided a thorough answer

My answer is more extreme:

"No clear segment for a general DSL authoring language yet exists, because no one knows how easy it is with Raku."

Yes, there is real value in making and using DSLs - but these are awkward to write since they need a PEG library for your language and this is seen as very specialist and hard to maintain.

The message is "Raku is the best DSL authoring tool".

Conclusion

So far, we started with a shortlist of three and now we have stack ranked them:

1. DSLs
2. Web Development
3. LLM Prompt Engineering

My proposal is that we place all our bets on horse #1 - DSLs. The risk is that this may not turn out to be a horse. But I think that the benefits of focusing our 2026 Exemplar work on this segment beats trying to cover multiple options.

Please note that many of the other things discussed here - LLMs, markdevines workflow, SBOM stuff, devops, multi-lingual documentation, even web development can align with this DSL focus.

As usual, comments and feedback are very welcome.

[FCO]

Sometimes I feel like if many people build many different things and if/when some/one get a bit of traction, everyone start working together to improve that one(s) that got traction... no one know what could get traction, so I think that trying many different things may be easier to find something with some level of success...

[librasteve]

@FCO … I agree that this “random walk” is quite common in practice. I would say that Geoff Moores biggest contribution to humanity was to recognize this pattern, write it down and apply some science to which ones seem to get traction and which fail.

Actually I think Raku has been doing this for many years already and, regardless of the direction we set from this debate, random module experiments will continue. :-)

Good examples are Red and Cro. But these did not (yet) result in any traction. Applying Crossing the Chasm (CtC) guidance, the relative benefit of eg. Red vs Django is low, stylistic (as opposed to financially quantifiable) and needs to be made to a very large ORM user base with very established opinions about the leading alternatives. So you need to convince a large number of folks that they are mistaken. Virtually impossible.

I think the Exemplar 2026 reddit poll results were clear that DSL is close to traction, and I have shared the HARC traction numbers which are real and we could build on. So we could choose to work in both of these, or all three if we add LLMs. It is true that picking DSLs means less attention on the others. Based on CtC it is better to focus, especially if our advertising budget is near zero.

There is a case to say that the DSL segment is also mature … there are PEG libraries for most languages. But, in this case we are coming with something disruptive - a general purpose PL with integrated Grammars. So we need to find and convince the DSL folks (like Corbin) that Raku is worth considering as a better way.

[nige123]

DSL's can encompass a lot of potential scenarios - which is fab - as there needs to be a 'darwinian' process to arrive at DSL's that attract new users etc.

One thing to consider is the viral network effects of new DSLs being shared. The Cold Start Problem is an excellent book for understanding how products can spread via network/viral effects.

The product(s) here is not Raku per se - but the DSL(s) and supporting Raku tools etc.

[nige123]

One more thought. The first DSLs we focus on probably need to be painkillers, not vitamins. Painkillers are need-to-have and vitamins are nice-to-have.

Niche DSLs are lovely, but the ones that spread are the ones that remove real, everyday pain ($£€) — saving time, reducing risk, or replacing something fragile and manual. Those get shared / deployed etc.

From a Cold Start point of view, it's shared pain that creates momentum. That's why I mentioned some of the itches that need scratching above.

[librasteve]

@nige123 - some good points. I am struggling a little to see how to make a painkiller DSL for the itch you mention (which I have loosely called "SBOM" ... not sure if that is on the mark?)

Please can you show a sample of an idealized DSL for that to give us an idea?

---

Along these lines, I have been toying with the idea of a vitamin DSL based on Air, according to ChatGPT, it could go something like:

site "My Website"

page "Home" /
  hero "Welcome to My Site"
    subtitle "Simple. Fast. Clear."

  section "About"
    text "This site is written using a tiny DSL."
    image "about.jpg" alt "About image"

  section "Contact"
    list
      - "Email: hello@example.com"
      - "Twitter: @example"

page "Blog" /blog
  section "Latest Posts"
    card
      title "First Post"
      text "This is my first post."
      link "Read more" "/blog/first-post"

I thought this was quite a good way to showcase such examples... https://langium.org/showcase/

[nige123]

That's cool ☝️

I can imagine feeding that DSL to an LLM and have it generate HTML, CSS, PDF, slides etc - or rendering code (e.g., Raku Air, GoLang etc).

The SBOM pain for a CTO/organisation is having to prove that they know exactly what software they ship, where it came from, and how supply-chain risk is controlled - because under the EU Cyber Resilience Act and NIS2 Directive, getting that wrong can mean fines running into €millions or a percentage of global turnover - whichever is higher. 😱

A pain-killer DSL in this context might be some sort of "spec of specs". The DSL acts as a single, human-readable contract for devs, tools, and LLMs - with supply-chain / SBOM coverage as just one module alongside API, data, UX, etc.

At the top level it could be something like:

product "SomePossiblyInternalCorporateProduct" version "1.3"

include site "site.dsl"
include api "openapi.yml"
include supply_chain "supplychain.dsl"

outputs ["dev-docs","tests","sbom","board-pack","audit-checklist"]
block_release_if supply_chain.risk >= "high"

It's about collapsing a messy reality into something declarative and defensible.

From a Cold Start point of view, that’s why this spreads: it turns a shared, high-stakes pain (audits, board questions, enterprise sales blockers) into a single 'contract' that can generate developer + LLM artefacts and board-level proof from the same source of truth.

That's a painkiller, not a vitamin - and those are the DSLs/tools that get adopted.

That said, most of us are having fun working on our own $projects in Raku.

To scratch an itch closer to home we could start with a DSL-powered utility for extracting the 'software contract' out of our own projects. This contract DSL can then be used in LLM prompts - for your own $project - as a first step (e.g., rakuref above).

[FCO]

If that could be used to generate a Dockerfile/compose file, or a CI/CD or into something like Nix it would be very cool. It could be, instead of just random information that may or may not be used and/or up to date, it could the the recipe to how to build/release the piece of software.

[nige123]

Another itch DSLs can scratch is constraining LLM output - reducing hallucinations and making results more deterministic and "regular".

I’ve been using JSON schemas to do this recently (e.g., in dosh). It works, but it feels a bit brittle.

For more complicated LLM responses, Raku grammars feel like a much better fit: declarative, composable, versioned, and designed for evolving structure/semantics/function - not just validation.