DEV Community: 2colours

Blessing the diamond problem - Raku's Allomorphs are a Bad Idea

2colours — Wed, 25 Mar 2026 15:03:41 +0000

In the recent Rakudo Weekly post, there was an illustration of the Allomorph type as an educational offtangent. This is the perfect inspiration to write a full post about the topic. TL;DR: Allomorphs are a net negative feature that could be easily and predictably removed from the language (given the intent, of course).

This topic has two advantages:

Raku knowledge is enough to understand it; in fact, knowledge of another class-based scripting language might also be enough
it's a plain high-level feature that could be implemented in user space so we won't be dealing with odd runtime considerations, just type theory and user-facing implications

The article states Allomorph classes should be considered a common raku scenario. I agree with this statement. Let's look into the reasons and consequences!

Why Allomorphs exist

This question is half sincere and half rhetoric.

Sincere question - a hypothesis

First let me recommend reading about the expression problem, my rationalization is related to this broader topic.

Perl as the ancestor of Raku, is strong on having dedicated operations for different types: as an example, it has . for string concatenation and + for numeric addition. This approach has certain merits: it's a fairly predictable system that works well with unstructured data.
Raku took this a step further: it encourages you to "bring your own operations" (to existing types), as exemplified by the ability to define new operators, and coercive type constraints. This allows for a fairly extensive (and extensible!) system of coercive operations (if you know another language that has this, please inform me).
Raku is, however, also a class-based object oriented language and this framework doesn't work well with coercions - you cannot just call a method on an unrelated object and have it coerced to your class because the method won't be available for starters... a class has to proactively plan for supporting unrelated types to be able to coerce into them.
Raku does take up on this OO challenge: by having very fat base classes (Mu, Any, Cool) - in particular, Any covers most of the interface of List and Cool covers¹ most of Numeric and Str.
Now, I think Allomorphs were envisioned to take these "object-oriented coercions" a step further, by using actual inheritance which means full coverage of the interfaces, utilizing inherited behavior and passing type checks.

Rhetoric question (you could answer regardless!)

... now, having said that, I don't know of a real life use-case of Allomorphs, other than being pretty much forced to deal with them ("common raku scenario"). If you have such examples, that would help estimating the costs and benefits. In my understanding, a string passing eg. an Int type constraint is unnecessary when you could have a coercive constraint Int() to allow for any sort of type to be coerced into Int, or Int(Str) to specifically allow this particular coercion.

I'm confident that decent alternatives could be suggested to all existing uses to Allomorphs but the only real way to know it is to see the use-cases. I for one basically only bumped into them when they caused problems for me (spoiler: it was a Bool coercion ("empty check") on a "string" obtained from prompt).

"Red flags" of the `Allomorph` class

These are properties of the Allomorph class that are more symptoms of an underlying issue than being issues on their own.

First, it's questionable why something of the name "allomorph" is tied to Str by inheriting from it - if these multi-faceted types are useful, why make one of the facets mandatorily a string?
Second, if we look into the Rakudo implementation of the class, we can observe that it prepares to delegate a whole bunch of calls to Numeric - so the hidden assumption is that the other type has to be some sort of Numeric.
Third, despite inheriting from Str, this type has to bring its own Str coercion method - actually, Str($allomorph) and $allomorph.Str don't even behave the same way. This inconsistency might be an issue in itself but it's not the fault of the hard-wired Str() coercion: indeed, why should something that "is a Str" return anything but itself when coerced into a Str? That odd feeling is probably because of...

The Liskov Substitution Principle

The L in the SOLID principles, the Liskov Substitution Principle (LSP) assigns semantics to subtyping, stating that a subtype of type T must be usable instead of T without breaking the program. We will see that Allomorphs break the LSP inevitably.

In a class-based type system, inheritance is a means of subtyping one can describe with the is-a relation. The LSP gives semantics to this relation: if a Horse is an Animal, then a Horse has to behave in our model exactly as an Animal would, fulfilling all invariants.

The Rakudo Weekly post highlighted an obstacle and provided an explanation to it. I think it misses the point and it shows no awareness of the LSP. (It's worth clarifying that something "that inherits from Int" is an Int.)
Posting the code example here:

class Animal {} 
class Horse is Animal {}
class Human is Animal {}
sub cantread(Animal $a) { "{$a.^name}s can't read" }
my $h = Human.new;
say cantread $h; #Humans can't read

It's not clear whether this is meant to be a good example, and if it isn't, what does it prove or illustrate. This code example is perfectly consistent with the LSP - we might find it subjectively odd that "humans can't read" but if it's an invariant of animals that they can't read, then our choice is to either a) not model humans as animals b) accept that by extension, humans also cannot read. This is a modeling question: the two commonsensical resolutions seem to be a) discard "animals cannot read" as it isn't an invariant b) don't model humans as animals.
Anyway, the code is easy to reason about and with a more practical interface (eg. a can-read method or subroutine), one could even sensibly define results for different subtypes.

The problem with Allomorphs isn't the mere fact of the subtyping but, as we will see, the subtype of Int that we get (IntStr) is indeed not quite an Int as per the LSP - and even more notoriously, it "is a" Str but doesn't behave like a `Str.

The diamond problem and its incompatibility with the LSP

There are many variants of the diamond problem even within OO - for our case, this is the important part:

If there is a method in A that B and C have overridden, and D does not override it, then which version of the method does D inherit: that of B, or that of C?

Raku is not unique in the regard that it allows users to "invent" this problem for themselves and uses the C3 algorithm to resolve these conflicts - Python does the same (Perl as well). However, Raku specifically encourages this problem by introducing it to the core language in a somewhat custom way, bringing utilities to create values like this.

For simplicity's sake, I'm going to talk about IntStr in particular - the conclusions apply to other allomorphic types as well.

What we ignored so far is that there is in fact an overlap between the interfaces of Int and Str, and since they do behave differently, there is absolutely no way there could be a type that is simultaneously an Int, a Str and respects Liskov's principle. The previously mentioned Rakudo sources don't make it a secret where the overlaps are: the overlaps will be typically resolved² in the numeric direction.

This means that you can have a Str - really, something that passes all type checks, coercive or not! - that will

boolify to False even though it's not empty (<0>.Bool, <-00>.Bool etc. - worse yet when you have RatStr, NumStr or ComplexStr!)
just work different altogether when iterated with .succ or .pred (<-1>.succ, <042>.succ - different value and length and return type)
smartmatches against strings that don't eq to it (<1> ~~ <01> and vice versa - again, worse yet with eg. <1e-1> ~~ <10e-2>)

It would be easy to downplay these issues³ as "who would do something like that" but as I said, after a bunch of type checks, you wouldn't know where the value came from, and built-ins like prompt don't ask twice to give you these incompatible values.

If we take the LSP a little bit more seriously, IntStr isn't a proper Int either: you might expect for Int value 10 <= $x < 100 to get $x.chars == 2 but $x.chars can be any number when you have an IntStr with leading zeroes⁴.

Now we can see why Allomorphs bring their own implementations of coercion methods, forcefully upcasting them into Str, Int, Real, and so on: this is a way - actually, the only way I know about - to forcefully opt out of Allomorphs and restore the invariants of these types. You got a string? Next time, remember to either call .Str on them, or take notes: you aren't supposed to boolify them, smartmatch them against each other, or step them. I'm not sure, though, if this list is exhaustive...

Apropos upcasting to Str. This modification hints that certain methods of Str pay attention to be invariant (return instances of Str rather than the subtype). This is not only a "red flag" (why was this necessary if Allomorphs are so great?) but also a deliberate breaking change for sure - one more to the list in my previous post.

Bonus one issue `<>` doesn't even always call `val()`

This is a random thing I observed: while <i> is a Str (fair enough I suppose) and <1i> is a ComplexStr (the usual val() scenario), for some reason, <0+1i> is outright Complex, unlike both val('0+1i') and qw:v<0+1i>, as taken from the calendar post linked in Rakudo Weekly.

This is on Ubuntu 24.04 with Rakudo 2025.12 and it seems like a mere bug. I don't know whether it's better be a bug or a feature.

Conclusion

I think there is plenty of reason to not have Allomorphs in the core language, or at least avoid them, ranging from the fact that they are trivial to implement outside of the compiler, and that you really don't want strings that don't always behave like strings scattered around in your code, coming from external sources.

The conclusion highly depends on some sort of benefit or legitimate use cases of Allomorphs - if you know about those, let me know about them in the comments, and maybe we can iterate this post, or at least point out some irreconcilable difference of value judgements.

This in itself is not a problem as long as there are no overlaps between the interfaces (method signature clashes), although I think it could have been implemented better: instead of de facto covering interfaces, these interfaces should have been separated into some sort of mixins, possibly roles. ↩
I'm not sure why so much code needed to be written but the point would stand with automatic, C3-based method resolution as well. ↩
I'm not sure if this downplaying is probable, though: I don't see much reason to take something for granted that makes the language harder to implement, specify, document, learn. There would have to be strong positive evidence in favor of it. ↩
At this point you may wonder whether Allomorphs allow for alternate numeric formats from Unicode. They do, although in my experience less than the actual source code would allow. This would be another story but it does mean that there are in fact many more strings that have the same values. ↩

Raku community(?) in 2026 - how my permanent ban came to be

2colours — Tue, 17 Mar 2026 06:58:28 +0000

Or: what matters and what doesn't.

When I received my second ban from the Raku community, just a little over a month after my first ban
expired, I can't say I was terribly surprised by the fact that to a large extent the same people wished to see me out of the project in some shape or form,
but it came to my surprise that they wouldn't settle for anything less than a permanent ban, effective immediately.

Since we aren't talking about an organisation in the legal sense, there is nothing that would make such a ban illegal, and I doubt the involved parties
would ever agree whether the decision was just or not. However, I would really like to know at the very least whether the actual Raku community - as in people
involved with Raku either as users or contributors - consider it legitimate and how they feel about the supposed permanent order the Community Affairs Team
seeks to represent.

Let's see how this ban manifested, and then also the background from my perspective - after all, not being a legally recognized procedure, there is essentially
no defense or no medium for the accused to represent themselves in any way. Given the terse announcement, there are plenty of things to interpret.

"What do I care?" - If there is one part you read

I can't expect anybody to read long discussions and take sides in something that is essentially a cluster of personal conflicts. (I don't mind it if somebody does, though. :P)

However, how a procedure like this happens is the concern of the whole community, and the following aspects definitely deserve attention:

from the CoC incident response guide, one can clearly see that under the premise of "it hurts the entire community", the accused really has little to no rights and the idea really is to prevent any proper publicity or any transparency about the decision-making process itself (it also contains some ironic notes, like the RSC members, who are in large apparent overlap with the CAT members, should be held against even higher standards)
the whole repository misses any details about how somebody becomes a CAT member, or what the structure even is (I only learned it from email that apparently there is such a thing as a secretary of the CAT)
the list of CAT members is certainly outdated (another example of RSC members serving as CAT members which surely helps them hold themselves against the highest standards)
the public announcement also doesn't clarify who is making the decision and based on what evidence (in fact, the implication expressed in background conversations is that the CAT does have some sort of evidence but isn't going to disclose it in any shape or form, it seems)
when asked by others for clarification on IRC, @lizmat, a member of the RSC (but to our best knowledge not the CAT) links a conversation she was deeply involved in, saying "it made me realize (...)" in the explanation. Three red flags:
- not a CAT member to have any authority over the matter
- a highly involved participant in the cited conversation
- an RSC member supposedly held against even higher standards in the conversation
- an odd note: "it's all in the irc logs" is even contradictory to "the CAT has evidence that we aren't going to disclose" sentiment communicated towards me later on
given how entangled the RSC and the CAT are, some concerns about the RSC also apply here

Since the resulting decision is a permanent ban, one might be curious what I have done to earn it. The reason given is: "the interactions on line are similar to those which led to his two-year ban".
More about what led to my ban later on for those who are interested - let me just say, since we are not talking about criminal activity (I'd argue it's not clear which
point of the Code of Conduct is even being violated), it sounds dishonest at the very least to ban somebody for 2 years under the expectation that their convictions have to change,
and then almost instantly extend that ban to infinity, as if to tacitly say "if you don't come back with regret, you might as well be gone for good".

"A frustrated, egotistical person" - bad patterns?

It's a reasonable assumption that somebody who has been banned twice might not be a reliable narrator of the events - in fact, it seems logical that somebody who has "hurt the community on multiple occasions" would also want to stir up some drama, as a new, creative way to cause harm, right?

Well, perhaps with the frustration, you would be right: I may be frustrated. However, my bad record is, to an extent, an illusion: it actually has been mostly the same people, even stretching beyond my presence or activity in the community, who steered (pun not intended - not yet) conflicts in a certain direction:

as we have seen, without knowing the exact state of the CAT, we have to assume it was mostly the same people making the decision as 2 years ago
it was mostly the same two people explaining and defending the ban (who have by the way showed great conduct and not-so-subtle hints of a bargain scheme) who already played dubious role around my former ban (this latter message got cited as evidence of my misconduct - see later - by the way, coming from somebody who admitted, perhaps multiple times, to know the language less than I do)
I had two head-on political/ideological conflicts in my "early Raku days" in 2022: one about the Code of Conduct itself (fairly involved and borderline aggressive messages from "leaders of the community", to borrow this phrase) and one about the whole 'master' vs 'main' polemy (to be fair, this debate seems like one of my big mess-ups in retrospect - more about that later* - still I have no idea what @japhb (still RSC member) was on about or how this kind of behavior demonstrates good leadership) Now, I'm not saying I eventually got banned because of this, but I do think these early and fundamental conflicts and the role of the leadership largely determined the attitude towards me.
and now we get back to 2020 when a certain member of the Raku Steering Council @AlexDaniel got removed from the Steering Council and the "core team", just a few months after the election - this might be interesting not only because of the people involved, but the general patterns/mechanisms working in this community
only for completion's sake: you may see some familiar names, or why did one of the most active members leave shortly after releasing 6.d

(*I promised to reflect on the 'master' vs 'main' polemy. The situation is a bit subtle.

I still think that the name 'master' for git branches being made an issue is a very bad case of manipulating people into performing a ritual of "being a good person", and thus simultaneously unpragmatic and psychologically intrusive.

I still also think the opinion expressed in the previous sentence should ideally be accepted (tolerated, if you will) in a diverse, technical-focused community, and possibly even (re)presentable as well.

However, I used to think that this was a hill for me to die on, and as time went by, I realized it just wasn't. In the Raku community IRC and across the core members - just like many of the FOSS spaces - this opinion is not welcome. It's a pity I guess but I can live with it.

And as I re-evaluated the importance of this "challenge", I realized that perhaps I shouldn't have been so combatant about it, and not roll with these implications, or outright chosen narrative, that this is a "battle to fight". It really wasn't the time, the place and the way to bring this whole topic up. I wish the pushback hasn't been so aggressive, especially on Geoffrey's side - but I certainly didn't help my case by completely lashing out at a behavior or mindset that many of these people held dearly or were empathetic towards.

On the other hand, one thing to keep in mind is that we were only 3 weeks after my first ever Raku (online) Conference - I felt very much like an insider or comrade, a respected member of the community and as such, never anticipated this much frustration or outright anger about a rather abstract matter.)

The first RSC ejection

It's best to start with the context and a disclaimer in particular: @AlexDaniel has no personal role in any part in this compilation or report, I am fully responsible for it. We are on decent talking terms I would say, mostly because back in 2023 I reached out to him to learn about his story, personal opinions about Raku, whether he would ever be interested in the language again, and so on. I'm using no information from personal conversations with him, and I didn't even consult him about this writing because it's neither his duty, nor his business really, to be summoned in an uncomfortable situation like this, and it's not about him personally at all. My point is simply that it was a bizarre methodical removal of him from the community and it shares important similarities (including people involved) with my ban.

It's also worth mentioning that we actually disagree about a lot and are quite unlike each other in many ways. Alex was a highly influential member who had big ambitions for the Raku language and wanted to radically reform it - I on the other hand just got side-tracked as an over-excited user and started doing chores by myself, as much as a somewhat outsider member could, and really just wanted to see order and internal consistency, or at the very least some sort of convergence towards something, as a project. Alex had a very direct, explicit communicational style - I'd like to think that I never used that sort of language and I for one certainly don't find it appealing. Having said that, in our personal conversations we never upset each other too much and could respectfully disagree about things, which in itself contradicts much of the narrative promulgated by the de facto leadership...

His ejection announcement also doesn't contain a lot of substance, it could be summarized as "he has done a lot of good but dissatisfied with the project, he has become a liability in the long run" (one might ponder who runs the project, or who voted him in so easily with this nomination). The only thing that strikes me as seriously manipulative is this @lizmat's self-eviction proposal: this is something nobody proposed and the mere implication that somebody can have all earned permissions revoked essentially "just because" is harmful in itself. In reality, it's a bargain at plain sight and probably her most explicit hint to just leave that I have come across.

Things only get more concerning in this - ironically, problem solving - issue, the linked discussion is also interesting, in particular because it does very minimal and voluntaristic effort to reconcile Jonathan Worthington's announcement with the narrative. I wouldn't want to accuse Jonathan of saying one thing to the public and another in private - or should I? Oh well. Curiously, my famous last words also came to be criticism of him...

(A longer intermezzo: I can't help it - a lot of people have good memories of the days when Jonathan Worthington was still around but the picture that I got wasn't so rosy: not only because of the tantrum given as context for his leaving, or his helpful attitude - immediate block to me for that comment, by the way - to the person creating Rakudo Star releases, or his super casual attitude to the work that left everyone without a language release even 5 years after Liz first predicted the new release - but also because he had the rare luxury to be financially (@lizmat paid) invested (@lizmat paid again) in the language and has since simultaneously divested from Raku and left it, never having done anything resembling a project handover. You are free to choose your Personal Jesus but maybe don't put all your money on a project lead like that.)

These "what exactly follows from that" remarks will return at my first ban. The "you state your opinions as facts" is a weirdly popular sentiment that I'm quite familiar with (it came up a bunch of times at other places as well, even in the last couple of weeks). This is actually a relativizing false dichotomy that keeps people from evaluating claims because observations and analysis of them are lumped together with personal preference and gut feelings.

The "trying hard to break things" sentiment goes way beyond either of us in a community where DIHWIDT is an established abbreviation to essentially mean "you weren't supposed to write this code", like it's always this easy. (In general, something that is actually hard to illustrate by examples, is that there is a tendency to focus on examples without seeing the patterns - maybe this PR could or this design issue. Interestingly, @niner could relate the issue to existing principles and got upvoted by people who were more hooked up in the world of DWIM's and DIHWIDT's.)

The personal remark about importing frustrations also seem to have a set place in these debates, even though one could argue that it must be much more frustrating to be stuck in a project that you believe to have only external problems (basically just funding) that don't seem to be getting better, then to think of a way forward.

Something that resonates with me a lot is that whenever something comes up that needs intent and a decision, the triangle of "we just don't want this"/"this doesn't belong here" (also here) — "do it yourself, prove it" — "why don't you just fork the whole thing and do whatever" comes up, which is a very contradictory stance and usually has the same commonsensical answers:

proposals and suggestions are turned down without giving much thought to them or evaluating interest/risks/benefits ("this is sealioning" is the response I hear in my head)
why feel encouraged to implement or research an already-turned-down suggestion (in my opinion, this is what should be considered sealioning: asking you to keep yourself busy for a while with something already turned down)
forking Raku is tremendous unprecedented work that is certainly not for a single person; the suggestion is either dishonest or expresses doubts about the self-image of the leadership of Raku

Here is one of my last conversations - it went through the very same cycles: "don't agree about the premise", "go ahead and implement it regardless", "nevermind, just fork the language instead".

I think all this demonstrates that the deflective mentality that reframes internal criticism as the "toxic influence" of whoever makes them (or is there a good example of how to actually have impactful yet "nice" criticism?), and resolves the supposed personal conflicts one-sidedly, not shying away from blackmail-ish remarks - and this mentality typically even comes from the same people. Food for thought from an eventual RSC member: it only took 3 months.

My first ban

As announced here.

One can see the announcement is much more like what you would expect for something serious. Let's dig into it:

whatever other accounts or identities he creates seems bad faith but to be fair, it is precise
stating a violation of the Code of Conduct but it's still not clear what exact point of the Code of Conduct has been violated (to my knowledge, there was no CoC during the time of @AlexDaniel's ejection but it doesn't seem to make a big difference, if not for the fact that he wasn't formally excommunicated as a mere member of the community)
it's not clear what the remark about my "immediate" formal issue is meant to demonstrate (it's a recurring point that these people "listen to me" and "give me chances", just by happenstance disagree about everything)
the length of the ban is largely in the eye of the beholder - on this rare occasion, there was one remark expressing concerns (anyway, I find it a bit funny to say that my contributions have been taken into account at the decision)
if the decision was based solely on IRC logs (which seems to be the case), one may wonder why the solution was a global ban that made it impossible for me to continue with my - supposedly welcome - other contributions. Was this a punishment - in contradiction to the CoC response guide - or what was the concern about my other activity that it need to be shut down?
it doesn't seem to follow from anything that the same actions can be used to justify a permanent extension of the ban
CAT members noted that these are not the only interactions they have noted over time is barely better than hearsay
various funny things in the citations ranging from plain misinterpretation to what others state about me and this mind-breaking claim that somebody "left the community" by sending a /me IRC command.

There was a lot of tension on IRC, and most of it indeed involved me. Three things in my defense:

First and foremost: when I came back, I made the effort to tone down a lot, and stayed much more careful on my end, which might be the reason the best (only) explanation cites an argument where the same person was trying to mischaracterize and discredit my complaint and there was a borderline hysterical remark from somebody who, after admitting several times to know Raku less than I do, had objectively estimated that I had been 30% right...
I was - by far - the most vocal member during my stay: I totalled (to the date of my ban) 25 555 messages on Discord, most of which happened before my first ban, and most of which was bridged to IRC. (I'm not counting IRC separately now.) Of course this doesn't explain conflicts per se but it does put them into perspective: it was really hard for any conflict to happen without my involvement when I was just basically involved in everything, good things and bad things alike.
most of my conflicts have been with people close to the heart of the project: RSC members, CAT members and Steve Roe (@p6steve and later @librasteve - current author of raku.org and the Rakudo weeklies, and with an unexplained permission to close RSC issues). The overlap with the people who ejected @AlexDaniel (including the ones that agitated for it) seems considerable - anyway, it's not a surprise that the people who have the power and responsibility to change the trajectory of the project, would be involved in conflicts sparking from technical debates.

Regardless of the (in my opinion, not particularly convincing) IRC logs cited, I admit that a lot of times I was harsh, insensitive/borderline provocative or simply impatient. (In particular, a recurring pattern is that I often engaged combating a perceived unfairness or passive-aggressive tone in a clearly frustrated manner, and only clarifying my position later on.) However, I do believe that I have been fair pretty much always, and you won't find me running around dragging people into unsolicited discussions (people feeling like chiming in is not dragging them in), calling them names, or harassing them in any other way. In the case of melezhik, for example, I think we both had responsibility in stirring the frustration up but there were no grudges and he was certainly among the people who welcomed me at my return. Bartolin wasn't a regular on IRC but from all we can tell, the interaction carried on to DMs in a respectful manner (unfortunately I don't keep IRC logs and don't remember the conversation). By the way, Bartolin is somebody who had sided with me earlier in a discussion where two RSC members' main contribution was persistent discrediting in dubious ways (this one is even dishonest to just make a point about it). (By the way, this really highlights the perpetual "everything is just an opinion and yours is not worth a lot" mindset of these people, not at all concerned with the pragmatics of the situation but allocating lots of unsolicited resources for humbling the one who brings criticism.)

Other great interactions with RSC members include this and this (the irony of talking about "this has worked for decades for Perl" in a passive aggressive tone, ignoring arguments, when there are acknowledged issues of actual dependency manager implementors and the very discussion sparking from an actual problem.) @ugexe in particular is an RSC member who hasn't had the best track record with the kind of passive-aggressive remarks that somehow don't bother anybody. (For what it's worth: no, neither the article dump, nor the added code snippet actually addressed the problem that installed modules cannot really be moved around, and the so-called CURFS suffers from both lack of pre-compilability and degrading performance when used in a larger folder.)

@tonyo's overall behavior is below worth commenting on. When I'm the problem with this sort of arrogant tone present, maybe it's not hard to feel like stuck in a corner. (Seems like he didn't start with me either: lots of big words for a supposed bystander in the Zoffix witch hunt.) Anyway, maybe it's not the best leadership to boast with not giving your users and potential contributors your time (quite a regular sentiment but I did bump into it here, for example), and at the same time regularly demand contributions. Anyway, if somebody cares that much - after a discussion that didn't get referenced at my second ban at all, I wrote quite a lot about my contributions and how a lot of it goes wasted already.

Anyway, I admit that diplomacy is not my strong suit and one can definitely find conflicts where 20 passive aggressive messages go back and forth before returning to the technical subject. I regret not handling them better, I'm not proud of them. What I can neither find nor recall is any case in which the people who have "warned me and given me chances" a lot of times would acknowledge or validate my perspective in any meaningful way. Anything that doesn't immediately excuse the other participant some way, or doesn't outright presuppose that since I was involved, it could only be my fault. (One of the best examples is this conversation-let that ended in this troll lashing out against the whole (FOSS?) community and lowkey declaring war on humanity in a long tirade. End result: the Discord side ousted from #raku-beginner, and another one of the few occasions with visible third-party backlash and reverting the ban.) These messages outline the same attitude: "we had a meeting", "you were heard" - too bad that apparently all my points got disregarded both in the meeting and the given thread. The essence of the complaint (that somebody uses moderational powers for their own benefit while simultaneously making bigger violations of conduct) barely gets a "yes, but..." remark immediately steering the conversation towards "the merits have to be compared" and that "the ban seems alright, nobody vetoed".

(I can't help but point out Richard Hainsworth: I have no reason to assume he wouldn't act in good faith but all my "affair related" interactions with him seem to have been very polite ways of him to disregard/disapprove my point of view just as much as the others did in often much less polite ways. The "extrapolation from one example" seems particularly ironic - I truly hope it doesn't seem like I extrapolated from a few examples here, and also, it would be one of my main technical criticism of the maintainers is that they are obsessed with handling issues on a case-by-case basis and refusing to see patterns. The mere fact that the language is "specified" by a bunch of tests written in Raku and you are supposed to extrapolate from them, is just the most extreme example of that.)

The RSC

To come in a full circle, I think now there is nothing else left than to talk about another important aspect of the story: where the community is headed and how it's run. (Reading the whole code of governance is recommended.) A few takeaways:

minimal governance was an explicit goal - also expressed in the first election announcement
the RSC does have the formal power to enforce or update the Code of Conduct
a fairly transparent decision process was envisioned
The Steering Council is, among other things dedicated to the stability of the language and tooling around
the mandates last until the next language version, with no term limits
during the term, the main way of replacing RSC members is an internal RSC vote

First let me address the stability question, especially since there is such strong confidence and dedication expressed. I will skip over the theoretical problems and just bring examples of actual visible breakage in Rakudo, not tied to any language version - mind you, most examples won't exactly be bugs in the classic sense, more like reinterpretations of what was "meant to happen".

a design discussion unfolded under an old issue, concluding that the original idea was wrong. Honestly, this is an almost pathological example of things that shouldn't happen:
- design discussion under a random bug report
- ruminations about what the spec tests are supposed to ensure, leading to a Roast change
- no version gating
- with the best intentions, this still broke the [»+«] [[5, 6, 7],] case, as pointed out here (as explained in the issue: I think the principle of the new behavior is simply wrong for the hyper case - the 0/1-arg case of >>+<< is simply not meant to be delegated to +)
- bug introduced on the way in an optimization
- breaking a community module
an issue that I opened myself with an accidentally misleading title led to a commit (ironically, after my ban) that down the line caused behavior like 10 mod 1.9 == -9 (undocumented and still in production at the moment, from what I know)
something as basic as the smartmatch semantics of a Pair "was borked for 6 years", basically right since release, even being specified behavior and appearing in the docs
another suspicious-looking regression after Rakudo 2024.04 that nobody tracked down or clarified but could easily be more than a bug
$string ~~ S/a/b/ worked for some time and then it didn't - this was more a bug (that I considered a potential feature at some point, then was told was a bug in fact); anyway, I'm noting this because it's such a basic breakage lying around for almost a year
I myself lobbied for DateTime numeric coercions which broke at least one module which just got patched (quite a usual workflow - if Blin catches regressions, first try to just patch those modules to the new release... not very dedicated to stability, is it)
smaller breaking changes like this happen regularly - similarly .min and .max used to be endpoints of a Range, now they are kinda-sorta repurposed into Seq "find minimum/maximum" and (0..^10).max(by => {$_}) != (0..^10).max will certainly bite somebody

Make no mistake, there are more plain bugs (I don't know, this last one is somewhere inbetween a bugfix and a design change) - I wanted to specifically bring examples for this very lax attitude to stability, making breaking changes and respecifying the language on the fly, without giving much thought to the consequences.

With the Code of Conduct situation, it's not clear what the idea with having a separate CAT is, when it's mostly (completely?) filled by RSC members, or how this situation is going to help hold Steering Council members (or even the "core team") to the highest of the highest standards of conduct.

The promised transparency is nowhere to be found: I think the best example came when during the 2022 Raku Conference, current RSC member Richard Hainsworth outright asked what the Steering Council has been doing to begin with. (Actually, the answer is also worth listening to, to give you an impression of how the RSC is, or at least was, actually taken.) Actually... the next question was also like that. The whole video might be worth a watch for whoever who feels like there isn't much of an idea of "where we are going", and - I'm afraid - find very few answers besides commonplaces. ("when we move on to the next Steering Council (...)" aged horribly.)

It may be my ignorance but to my knowledge, the community has only gotten further from knowing what the "core team" is and who are its members. (Based on the description, I was certainly not a member so that's clear at least.)

Anyway, it never has come to matter. The last language version released, to this date in March 2026, is 6.d, released in November 2018, still managed and announced by Zoffix Znet, under the name "Raku Perl 6", almost 2 years before the Steering Council came to be. People came and go (including the ejection of 2 RSC members and the quiet departure of Rakudo's main architect), the Steering Council kept refilling itself, and we still don't have a release date for language version 6.e. Maybe we will get it this year. Maybe next year. One could have technical questions.

One could also ask governance questions (as I in fact did at the 2023 conference - great that these are recorded; "I don't think it was ever the intent that it would be taking this long (...)" - is it 2024 yet?). In a project that is largely getting nowhere for so long that I could name 5 (five - talking about a group of seven; if the announcements have been good for something, it's to track this) Steering Council members offhand who have left (either by themselves or by force), with little to no governance structure, and very little effort going into resolving actually stalled issues, maybe the model was too susceptible to something resembling usucaption, and that seems to have indeed happened: a small casual community of people remained, either indifferent or actually receptive to this type of leadership, not even having the fantasy or any kind of precedent to a change - either in transparency or in the seriousness of the project. After all, they really just don't get to know a lot, and have no reason to feel involved in Raku at a project level. (Just as much as they didn't need to know my ban, besides reaching out to the administration of the Discord server on IRC.)

The minimal governance and intervention to community process the Raku Steering Council did deliver on, as exemplified by the resolutions and the minutes that actually take minutes to read for every year, seemingly less and less.
Yet somehow, when "the community is in danger" by "bad people" like myself (or @AlexDaniel earlier), then the decisions go swiftly, and only the transparency is minimal.

I was trying to fix the latter in this report. Comments are more than welcome.

Appendix: Acknowledgements

... or "credits", if you really will.

It won't stop amazing me how it has become my epithet for the old guard that I'm selfish or egoistic when of the 4 talks/presentations I had on Raku Conferences, 2 were about how I maintain or renovate old projects and "you can do it, too" and 1 was outright a round of applause to great ecosystem authors. Sorry that I can't give credit for things that I don't find any good, like zef, or the years-long stagnation of raku.land.

I never minded giving credit where I thought it was due, and this was never meant to depend on personal opinions or conflicts. Yes, Liz has invested more into Raku, probably for 15 years if not more, than anybody else in all accounts, and she probably does what she believes is the best for the project. Yes, Richard pushing forward with the doc website and RakuDoc v2 are probably the best examples in the few years of actually designing, planning and executing something within the Raku community. Yes, Steve Roe's new raku.org site is way better and more inspiring than the old design (and my gradual maintenance plan for that) and the whole perspective he is taking is quite laudable. Geoffrey is a TUI wizard, Stefan (@niner) is perhaps the main reason RakuAST can even be completed, and so on.

Still I wanted to specifically thank those people who may not have necessarily liked me (who knows, maybe some of them even "reported" me - anyway, the way things get handled is the responsibility of the CAT) but stood out of the publicly dismissive, defensive, personal communication style:

Anton Antonov: We actually had some beef early on on Discord but in the long run, we learned to tolerate or even appreciate each other's peculiarities. We are still on pretty good terms to this day - I wish I had half of his wisdom, both technical and commonsensical.
CIAvash: alternative raku.org site, doc search bar, syntax highlighter, and probably the best approach to constructive criticism - I think Siavash was even under-appreciated for the kind of input and proficiency he brought to the project, and demonstrated the same calm attitude towards me as well
@ab5tract (John Haltiwanger): I don't think the RSC has unanimous collective guilt, and I think it is good to acknowledge that some people could stay more focused on the substance of issues and in general found better means and ways to interact. I would like to believe, if the vocal members were mostly like him, not only our interactions would have looked better but the trajectory of the project as well.
@Kaiepi/@morfent (Ben Davies): the kind of person I think all sides and all participants wished the community had more of. They were the last bastion of the JVM-based runtime, pretty much, and also somebody who really went ahead and experimented with rather large core and documentation changes, without making a big deal out of it. I think they also handled disagreements very gracefully with me - I wish there was a way to exchange more conflicts for bringing them back to life and the Raku community. Rest in peace.
@coke (Will Coleda), @arkuiat (Eric Forste): I think for a couple of years, the documentation team is the best managed corner of the Raku project, and this is true with or without me. Here, the "needs more (wo)manpower" seems fair. I think the recent times have shown nicely that people who might not like each other personally can still work together in a sensible manner - but anyway, I'm not worried about the doc team managing without me around just fine.
Patrick Böker: let me just say this: if there were 3 or 4 more people like him attitude-wise, dedication-wise and competence-wise, then the spirit and the output of the Raku community would be twice as good. Who am I to criticize a patient, humble and persistent member (quite surely a core developer) for not taking a bigger role in leadership? But one can wish there were more people like him around the heart of the project