What is the philosophy of the Raku project?

We reference this in the draft RSC document, but as @jnthn has pointed out, there is nothing of that written down anywhere.

TMOWTDI in a word, I guess.

TIMTOWTDI is a result of the broader philosophy. As far as I understand, it never was discussed as such in the early days of Perl6 design, unless @thoughtstream or anybody else involved objects to my statement. But looking at how things were happening back then and matching to the outcome, I'd say that the corner stone of Raku philosophy is the freedom of expression. This could serve as a starting point to formulate something more solid.

As far as I understand, it never was discussed as such in the early days of Perl6 design

My recollection is that, in the original design team, we talked a great deal about philosophy over the years. Possibly too much. ;-)

However, it was predominantly design philosophy, not language philosophy. For example:

- "Optimize for the common case"
  (a.k.a. "Huffmanization")

- "Find the unifying metaphor"
  (a.k.a. "Simplicity")

- "All is fair, if you pre-declare"
  (a.k.a. "Explicitness")

- "Things that look the same should act the same;
   things that act differently, should look different;"
   (a.k.a. "Intentionality")

I recall that we did not feel that the overall language philosophy of (what was then intended to be) Perl 6 would differ in any significant way from the overall philosophy of (what was then) Perl 5. Rather, that this new language would refine that philosophy and express it more perfectly.

I would not, however, categorize that overall philosophy as "TMTOWTDI". At least, not for Raku.

In fact, we deliberately departed from the original laissez-faire Perl approach (a movement we are now starting to see in the Perl community as well).

This was because we had finally recognized that:

"There's Always More Than One Way To Do It
 ...But Some Ways Are More Equal Than Others."

Or, to put it another way, we wanted to continue to support the classic virtues of Laziness, Impatience, and Hubris, but we also wanted to encourage the modern and complementary virtues of Diligence, Patience, and Humility.

So, in designing Raku we aimed to create intrinsically better tools. We sought to ensure that the clean, efficient, robust, maintainable way to achieve something in Raku was also the shortest, easiest and most "natural" way to do it.

In particular, that often meant replacing imperative step-by-step mechanisms with approaches that were either entirely declarative, purely functional, or cleanly object-oriented. And ensuring that these better approaches were also safe to use together and simple to compose.

I would say that the guiding philosophy of Raku–and indeed of all the "Mural" languages–is that we strive to help each each developer (and each development team), to code well in whichever style and paradigm bests suits their current problem...and their current skill set.

In Perl that ideal of easing the developers' burden is sometimes encapsulated as:

"Easy things should be easy;
 Hard things should be possible."

For Raku, I believe we aimed a little higher:

"Easy things should be trivial;
 Hard things should be easy;
 Impossible things should be (merely) hard."

And the key to making hard things easy is to allow developers to think about problems flexibly, in their preferred paradigms, and with an extremely broad range of built-in functions and data types.

Overall, then, I guess I would characterize Raku's philosophy as something like:

"In Raku we seek to support developers without getting in their way,
 by giving them clean, efficient, and robust tools that adapt easily
 to however they prefer to think about problems and code solutions."

Damian

I am extremely new to the Raku community, and I don't have nearly enough hubris to think that I can speak to what Raku's philosophy actually is. But I thought I'd share what I, as an outsider, perceived Raku's philosophy to be – which is a big part of what drew me here.

In short, I perceived Raku to have the philosophy that code can be art.

In this philosophy, programming languages, like natural languages, are not attempts to standardize on a single "correct" way expressing an idea; they are ways to facilitate expression and clear communication. There isn't just one correct and standard way to say "I love you" in any natural language – there are dozens, or hundreds. But, importantly, each of those ways is unique, and expresses something different than any of the others. So, too, with Raku: There's More Than One Way To Do It, but not because the language designers were indecisive or because Raku is a "kitchen-sink" language. No, there's more than one way to do it for the same reason that natural languages have so many near synonyms – to allow expressions that exactly capture subtly different meanings. I write very differently when writing a formal paper than a quick text to a friend; Raku language features like gradual typing allow similar shifts in register between quick scripts and large, multi-person projects.

To make this view more concrete: many languages have automatic code formatters that impose (or nearly impose) a uniform style on all code written in that language. That has benefits – it makes the language more uniform, and lets a new developer more easily jump into an unfamiliar codebase. From the point of view I'm articulating, however, Raku is philosophically opposed to that sort of standardized code formatting. Code shouldn't always follow the same guidelines; format should follow function, and appropriately varies with the meaning being expressed and the context it's expressed in. The clearest writing, in code or in prose, does not come from conforming to a standard style or vocabulary but rather from tailoring the expressions you use and the format in which you present those expressions to the content of the idea you're attempting to communicate.

Or, at least that's my view, as an outsider. I could be entirely off base (although, if I am, I'll be pretty disappointed – as I said, my perception of Raku's philosophy is a large part of what draws me so strongly to the language).

@codesections I firmly believe that programming is a creative form of writing. If it were not, all programmers should be replaced by small shell scripts. And perhaps that will happen at some point. But meanwhile, Raku is my favourite language because it can actually allow me to write good code and be creative as well, with an appropriate amount of -Ofun.

@lizmat it's a wonderful thread. However, I'd advise to use less buzzwords that sound nice but don't mean much in practice, at least when talking about the philosophy and not marketing (that said, I'm also for clear and honest marketing too). @raiph's detailed answer is somewhat related to that – using cool-sounding words that people relate to differently.

@thoughtstream's answer here is nice, but maybe a bit too focused on the language design. I'd say that Raku as a whole is not strictly limited to language design decisions, and we should be thinking a bit wider (it's just now I'm starting to understand that getting the best language possible does not seem to be one of the primary goals).

Overall, then, I guess I would characterize Raku's philosophy as something like:

"In Raku we seek to support developers without getting in their way, by giving them clean, efficient, and robust tools that adapt easily to however they prefer to think about problems and code solutions."

Cross out efficient, and we're left with clean and robust tools that adapt easily. What tools and how do they actually adapt? Of course, I can kinda see what people are trying to say, but there is very little substance.

For me, Raku provides concise yet readable syntax that is pleasant to work with. That's about it, other languages are not frozen in time, there's a lot of cross-pollination so everyone is taking the most usable bits from each other. Maybe another possible angle is to focus on the specific combination of features that Raku has, but that ideally should be related to some practical purpose. For example, if you say “glue”, then what kind of glue, and why doesn't it include a convenient way to run and pipe external programs. But that sort of gets back to my questions – what is Raku today? And what do we want it to be in the future?

@AlexDaniel

it's just now I'm starting to understand that getting the best language possible does not seem to be one of the primary goals

What gives you that idea?

Cross out efficient

Why would you cross out "efficient"?

other languages are not frozen in time

What gives you the idea that Raku is frozen in time?

For me, Raku provides concise yet readable syntax that is pleasant to work with. That's about it.

Then why are you not satisfied by that?

What gives you that idea?

I see no discussions anymore on how to improve the language and fix the existing traps, yet this used to be very common. Any time I bring attention to design mistakes it is greeted with a very defensive attitude. I think if it was a primary goal, devs would be more eager to discuss how things could've been done differently. Deciding whether it is worth actually fixing something or not is only reasonable after it is clear how something could be done differently, but right now people bring “too hard to change it now” as the first argument even though there are relatively painless paths to changing some features once you think about it.

Why would you cross out "efficient"?

Mostly because it is very ambiguous if not downright misleading. Some may understand it as if it's talking about performance, but Raku is definitely not designed for that (maybe in the far future with some major changes). If we're talking about dev experience, then efficient in what way? For example, Raku definitely requires high mental load when writing the code (because of all the edge cases), so what is this about? Keystroke efficiency is also hopefully unrelated because it is not a golfing language after all. Just choosing a better word will be OK, but I don't know what was meant.

What gives you the idea that Raku is frozen in time?

I never said that. I'm saying other languages are progressing too, and that perhaps some goals of the Raku project are not very defining anymore and are just the new normal now. Just as an example, unicode graphemes used to be a rather unique feature, but it is now commonplace. In fact, other languages even tend to provide better dev experience by default because they don't implicitly mangle the data.

Then why are you not satisfied by that?

That's not enough. You like to point out that it's just me being unhappy about something and that others see no issues, but you know, the majority of people are also not flocking to Raku, and I'd say it's because it doesn't bring enough value. I already had to choose another language for one of my projects because of performance reasons alone, and looking back, dogfooding and syntax were the only reasons I chose Raku for most of the things I did, which I regret now (mostly for performance reasons but definitely not only because of that).

I see no discussions anymore on how to improve the language and fix the existing traps, yet this used to be very common.

I get an odd feeling with this. In an issue on MoarVM you stated "Raku project had 20 years of happy mindless progress in no particular direction." Are you now saying you're missing that?

Any time I bring attention to design mistakes

Again, you could have said this like: "Any time I bring attention to issues that I think are design mistakes". You could consider some feature a design mistake, but others may not share that opinion. Whether something is a design mistake, is an opinion, NOT a fact, like you appear to be implying.

it is greeted with a very defensive attitude

Yes, you have that effect on people, when you claim that your view of the world is reality and fact. Other people may have different views, yet you clearly disregard these views as incorrect, because your views are, you think, the only and correct way to see things, and are therefor fact. And you do not seem to understand that. And people, who are doing a lot of work on Raku, therefore start to not take you seriously anymore. And with each interaction, this becomes more and more aggravating.

there are relatively painless paths to changing some features once you think about it

And there you go again, implying that people didn't think the effects of changing some features through.

but Raku is definitely not designed for that (performance)

And there you are so wrong. The implementation is not complete, but so were the initial versions of the JVM either. And they had a lot more people working on that. The DESIGN is there to become the VM of choice for dynamic languages. Most of the work that @jnthn is currently doing, is worthy of a PhD project: the newdisp work being one of them. The RakuAST work will not only allow things like macros to become available in Raku, it will also make introspection for static and runtime optimizations easier, and make the work on Partial Escape Analysis (pea) much easier. Personally, I've been able to port my work on making sprintf faster to RakuAST, so that it no longer needs to do a string EVAL. Same applies to assuming. All of these would not have been possible without a good design.

Raku definitely requires high mental load when writing the code (because of all the edge cases)

Is this about ... again? Or about Junctions in lists, which I have proven on IRC that .max on a list with Junctions provides a predictable result. Or some other edge case you seem to have sunk your teeth into and will not let go?

other languages are not frozen in time What gives you the idea that Raku is frozen in time? I never said that

To me "other languages are not frozen in time" means you're implying that Raku is frozen in time.

better dev experience by default because they don't implicitly mangle the data.

I have no idea what you mean by this. And I think Comma is actually a pretty cool dev experience. If you're so inclined, which most of the younger people are. And which is @jnthn is dogfooding all of the time for their company projects.

I already had to choose another language for one of my projects because of performance reasons alone

I'm sorry to hear that.

which I regret now (mostly for performance reasons but definitely not only because of that).

Well, I think for you the solution is easy then: port your work to a more performant programming language and you will never have to deal with the idiosyncrasies of Raku again. Or you could work with people to make Raku more performant, as that appears to be your main beef. Or if you feel you're not capable of that, stop telling core developers Raku should be faster: we all know it needs to be faster. Stop being a timesink and start being constructive. Make a choice. Don't linger in pain.

Concise - good Readable - a bit woolly Pleasant - a bit woolly

Raku aims to be a powerful all-purpose programming language with syntax that is both intuitive and concise in order to facilitate smooth and productive coding workflow aided by precise syntax error messaging and comprehensive and accessible documentation.

That's my take on it.

I get an odd feeling with this. In an issue on MoarVM you stated "Raku project had 20 years of happy mindless progress in no particular direction." Are you now saying you're missing that?

What do you mean? Are you saying that not being open to rethinking language design decisions is a good direction? I don't understand.

Again, you could have said this like: "Any time I bring attention to issues that I think are design mistakes". You could consider some feature a design mistake, but others may not share that opinion. Whether something is a design mistake, is an opinion, NOT a fact, like you appear to be implying.

In my opinion, everything is just someone's opinion. Do you think it is useful to constantly mention that whatever you say is just your opinion? In my opinion it is not useful, especially considering that the language allows to express a level of confidence. I don't just say that something is a design mistake if I'm unsure.

Yes, you have that effect on people

No, it has been the case for quite a while, no matter who expressed the idea. It is aggravating because it is hard to frame me as an outside troll, which worked very well with others in the past. Although, you're doing a great job at framing me as an inside one.

there are relatively painless paths to changing some features once you think about it

And there you go again, implying that people didn't think the effects of changing some features through.

Yeah. Well, this discussion is somewhat in the context of a recent mention of Junctions, in which we had this interaction:

\<lizmat> so: if $foo == $a | $b would not work anymore \<AlexDaniel> it will

So, yes.

The DESIGN is there to become the VM of choice for dynamic languages

You can believe that, it's your opinion. In my opinion it is highly unlikely, I'd even say it is rather ridiculous to suggest that.

Most of the work that @jnthn is currently doing, is worthy of a PhD project

I have heard this idea many times around here and could never understand how it is possible to equate the efforts. But it'd be nice to see some papers, yeah, with evaluation of the results and everything.

Raku definitely requires high mental load when writing the code (because of all the edge cases)

Is this about ... again? […]

Not sure if I will be able to explain the issue of mental load in this discussion. Any edge case contributes to it, the ones you mentioned are part of it, yes, but there are many more in Raku (and less in some other languages). It seems like you tend to ignore all of them so that you can get things done, which is actually right, in some sense there is no other choice in Raku. But I believe this also why we've done rounds and rounds of reviews where on each step we had a different issue raising from edge cases. It is also a good example, because IntStr's are part of an issue, although in this case I'm not calling it a design mistake yet because I don't know of a solution. But let's see, say, as a user, you want to write a correct sub that doubles (by concating) the digits of an int and returns another int:

sub twice(UInt:D $x --> UInt:D) { ($x ~ $x).Int } # or “$x$x”, doesn't matter

Note that I mentioned “correct”. Of course, you could've went with a shorter variant that doesn't check for the types, but hey, we are getting an int, doubling it as a string and converting it back. No biggie, right? We even used the UInt to make sure we don't get negative numbers. But the code, technically, is not correct. For example:

say twice <+5>

Cannot convert string to number: imaginary part of complex number must be followed by 'i' or '\i' in '+5+5⏏' (indicated by ⏏)
  in sub twice at -e line 1
  in block <unit> at -e line 1

Note that it didn't fail when checking the argument types, it failed when converting a String to an Int. It even suggest that it could've created a Complex number in that process! Although, it would've only used the integer part of it. Also note that I didn't event use IntStr.new with custom arguments to trigger the issue.

Point is, if you want to write correct code and be able to “see” the issues, you have to keep all these things in mind. Some of them are inevitable, but please don't downplay it as just me being grumpy about a particular feature. The whole mental load (or should I be saying cognitive load?) issue is very real in Raku, and anything we can do to improve the situation can really help.

To me "other languages are not frozen in time" means you're implying that Raku is frozen in time.

Don't put words in my mouth. I'm not saying that.

Well, I think for you the solution is easy then: port your work to a more performant programming language and you will never have to deal with the idiosyncrasies of Raku again. Or you could work with people to make Raku more performant, as that appears to be your main beef. Or if you feel you're not capable of that, stop telling core developers Raku should be faster: we all know it needs to be faster.

As I already mentioned before, performance and language design choices go hand in hand. It's my opinion, sure. I think you can't just take any language and make it fast. And Raku is not designed to be fast, unfortunately. In some aspects, the language needs to be simplified or changed, but that is somehow not an option. Or is it?

I have more thoughts on Raku's philosophy than will fit in a GitHub issue (I've started a blog post). But I want to make a point that's less focused on Raku's philosophy:

AlexDaniel wrote:

I see no discussions anymore on how to improve the language and fix the existing traps, yet this used to be very common. Any time I bring attention to design mistakes it is greeted with a very defensive attitude.

Raku is a mature, post-release language that's used in production. Before release, it spent a long time as a pre-release language with a design that was under active development. So of course it "used to be very common" to discuss what aspects of the language design were mistakes – that was the goal in that phase of development. Now, in the period when the Raku has been released, it is (imo) inappropriate and unhelpful to spend time discussing whether design decisions were mistakes – whether or not they were, we're past the point where the language design is in flux and rethinking basic design decisions makes sense.

This isn't to say that no mistakes were made, by the way. I'm sure Raku's design has some mistakes – even when proposing the language, Larry Wall never said Perl 6 would be a perfect, mistake-free language. If I recall correctly, he said the goal was "to make different mistakes" than the ones Perls 1–5 had made. So I'm confident that Raku's design has mistakes.

I'm also confident that different people, acting in good faith, can disagree about which decisions were mistakes and which weren't. I'm even more confident that Raku's future success depends on our ability to put aside debates about what past decisions were mistakes and focus on implementing Raku's design (and extending the design in measured ways that don't break existing code or change previously settled aspects of the design).1

Raku enjoyed a long period of refining its design, where everything was up for debate and no decision was final. It emerged from that phase with what I view as an excellent (though not error free) design [insert your own "emerged from its cocoon" joke here]. It's now in a different phase in its life – the implementation phase, where many decisions are settled and no longer open to revision. In my view, anyone who feels that Raku's general design is strong should work hard to implement that design, and to extend it in reasonable ways. Anyone who views Raku's design as generally poor should accept that Raku is (from their point of view) doomed: even if it perfectly implements its poor design, it won't be a good enough language to improve on existing options. And people who view Raku as doomed ought not, of course, spend their time trying to develop Raku; doing so would be a waste of their time, and upsetting to those of us who view Raku as a promising language in need of more implementation work.

1: I realize that this is a bit of an overstatement: Unlike the JavaScript and Rust (the two other languages I've primarily programed in) Raku doesn't have an absolute commitment to backwards compatibility. We could, in theory, rethink major design decisions in Raku 6e; we could even remove core functionality such as junctions. But making such major changes would, in my view, be a deep mistake. I believe that there is consensus on the point that we ought not re-litigate previously decided/implemented design decisions; if significant controversy exists on this point, we may want to open a problem-solving issue on the topic – in my view, it's essential that we agree about which aspects of the language are settled, and which are still under active discussion.

Anyone who views Raku's design as generally poor should accept that Raku is (from their point of view) doomed

Why is this pessimism necessary? Any design is fixable. Especially if changes are done in a well-thought-out way.

Raku is a mature, post-release language that's used in production

Let's be honest there. Not a lot. Almost not at all, actually, considering the scale of things.

@AlexDaniel can we please keep the discussion on topic? If you don't have an answer to the original question, there are many venues where you can express your opinions, and you're very welcome to do so.

@AlexDaniel

What do you mean? Are you saying that not being open to rethinking language design decisions is a good direction?

I'm saying that in a released, more or less stable language you work on fixing the warts. And if you don't want to do that anymore because you think there are too many intertwined warts, you start a re-design process, such as happened with Perl 5 and Perl 6. You appear to want to do that again. I think the majority of the Raku developers are against that.

In my opinion, everything is just someone's opinion.

WOW. The Von Neumann bottleneck is just an opinion?

I don't just say that something is a design mistake if I'm unsure.

Ah! So the fact that you're saying that something is a design mistake, makes it one?

Although, you're doing a great job at framing me as an inside one [troll]

FACT is that you have been responsible for at least 2 people leaving Raku related #IRC channels, and one of them is @jnthn . Just because they were fed up by your harassment and sealioning. And I fear that you also were responsible for one person having left the Raku community because of an interaction with you (they haven't reported in since that interaction afaik). And that's only in recent months.

And now you're saying that I'm framing you to be a troll? You're doing that quite well by yourself, thank you.

I know you blame me for Zoffix leaving Raku. And yes, I'm at least partly responsible for that. I should have realised earlier that TimToady was burned out and incapable of making a decision with regards to the alias or the name. And I should have realised earlier that Zoffix was right. But in the end, I'm pretty sure Zoffix left because of TimToady not being true to his promise of coming up with a decision on the alias: Zoffix waited three months for that, and then left. If I hadn't proposed the name change a year ago, we'd still be waiting for a verdict.

The DESIGN is there to become the VM of choice for dynamic languages

You can believe that, it's your opinion. In my opinion it is highly unlikely, I'd even say it is rather ridiculous to suggest that.

Then you should be glad that you have been banned from MoarVM.

say twice <+5>

You're trying very hard to find edge cases. The error's first part is correct, the second part could use improvement. Still, would you rather prefer this?

$ perl -E 'sub a { my $a = shift; +($a . $a) }; say a("+5") + 3'
8

No error, no nothing, just a result? Whenever there are strings and numbers involved, you will find edge cases, is my point. In whatever language you're working with.

performance and language design choices go hand in hand

I think that's not true. My opinion. But if that's really your opinion, again, you want to go to another language that is foremost geared towards performance.

other languages are not frozen in time

Don't put words in my mouth. I'm not saying that.

That is what you said. If you would have said "some other languages are not frozen in time", then you would not have said that. Simple logic, I'd say. Words have meaning, you know.

You appear to want to do that again. I think the majority of the Raku developers are against that. [Redesign process]

Most of the things I propose simply need a deprecation cycle and won't affect most of the existing code.

WOW. The Von Neumann bottleneck is just an opinion? […] Ah! So the fact that you're saying that something is a design mistake, makes it one?

My point was that anything people say is usually just their opinion, having to mention that all the time is just redundant. Even in science, technically, nothing is ever proved, but that doesn't stop people from using confident and assertive language when describing everything.

FACT is that you have been responsible for at least 2 people leaving Raku related #IRC channels, and one of them is @jnthn

My last interaction with @jnthn was when he popped into a relatively interesting discussion with his passive-aggressive remark. Somewhere around here:

\<AlexDaniel> codesections: see, when you get your string it's probably just a bunch of bytes. Most languages do nothing or close to nothing with it, so they don't waste any time on touching any character \<AlexDaniel> codesections: now, Raku wants to get unicode right, which is great. Except that it does that by going through the string and forming graphemes and stuff \<AlexDaniel> codesections: Swift does that too, but differently. Counting the amount of characters there is O(n), same as indexing I believe \<AlexDaniel> codesections: so people here say “oh hey look, we have O(1) indexing, isn't it great!” yeah it would've been great if the performance in general didn't suck that much :) \<AlexDaniel> it's hard to beat another language in terms of performance when that other language does nothing. No operations \<AlexDaniel> or at least that's my basic understanding of things, I could be wrong

BTW, @lizmat, you should appreciate that last message.

Anyway:

\<jnthn> All the extra work Raku does is why if you benchmark looping over the lines of a million line UTF-8 file, then Raku comes out a good bit faster than Perl 5 with :encoding(UTF-8). :P

I don't mind people being smug about the technical achievements. However, using the provided benchmark:

Benchmark	Raku	Perl	Julia
ASCII strings	0m1.819s	0m1.285s	0m0.703s
Strings with non-ASCII characters	0m7.714s	0m1.656s	0m0.846s

\<jnthn> AlexDaniel: You're nicely illustrating why I have private benchmark suite. :) \<AlexDaniel> jnthn: then don't bring it up as an argument for raku tradeoffs \<jnthn> AlexDaniel: Don't worry, I won't bother engaging with you on anything else in the future. I only wish I hadn't each time I do. :/

Of course, feel free to see the full log, it wasn't a short discussion.

That said, my point stands. Ahead-of-time grapheme processing just won't work fast enough, and moreover in most applications you don't even need random access to string graphemes (or graphemes at all!).

It's unfortunate that people leave when they're slapped with a reality check while they're being cocky. Should I leave so that the devs can continue to live in this alternate reality? I thought so too, then some people (even if not majority) voted for me in the election. Don't know what they liked, the idea of having someone with different opinions or what. Anyway, here we are.

I know you blame me for Zoffix leaving Raku. And yes, I'm at least partly responsible for that. I should have realised earlier that TimToady was burned out and incapable of making a decision with regards to the alias or the name. And I should have realised earlier that Zoffix was right. But in the end, I'm pretty sure Zoffix left because of TimToady not being true to his promise of coming up with a decision on the alias: Zoffix waited three months for that, and then left. If I hadn't proposed the name change a year ago, we'd still be waiting for a verdict.

Your timeline differs from mine. It's a long story so it is somewhat inevitable that it will get distorted. However, some things you say are just blatantly false. TimToady did come up with a decision, and it was “Raku” for the alias. Zoffix seemed to be happy with the decision and started using it. You know what happened next. The verdict was there, it was just different (less radical than a full rename).

Then you should be glad that you have been banned from MoarVM.

Don't care. I never misused my privileges anywhere, and my admin rights were removed from MoarVM before I was removed from the org recently. My contributions were rare anyway (mostly just reviews and merges), so no big deal. But if jnthn considers MoarVM to be his personal project, then he can as well remove me from the rakudo org too, I don't see a big difference between them.

performance and language design choices go hand in hand

I think that's not true

Right. Anyway, food for thought (more).

You're trying very hard to find edge cases.

Not trying hard at all, Raku just has so many of them. Being able to find edge cases is very important for security audits, and on the other side knowing where the edge cases are is required to write correct code that doesn't have security holes. Again, this will ring bells for some people, but I don't know if I'll be able to explain it in this discussion. Thing is, surely a single edge case somewhere is maybe not creating ground for a vulnerability, but having a wide variety of them (especially deep in the language) presents a nice attack surface that you can potentially abuse in clever ways.

Speaking of the grapheme processing, I remember reading a comment somewhere wondering why would anybody want that by default, cuz you almost never need that kind of handling of text. Back then it drove me nuts, like what do you mean, most programs work with text in one way or another, surely having full unicode support is something you'd want. Today, looking back, I realize that yeah, almost none of my programs actually needed to work with graphemes, and more often than not the default behavior was actually the cause of issues. Whoops. I think this comment is spot on.

Anyway, abusing graphemes is kinda fun. Create a string with 1023 or more combiners, pass it to any Raku application, an exception will be thrown:

Died with the exception:
    Too many codepoints (1024) in grapheme

You can rely on string concatenation and other issues to “probe” different parts of the application. For example, pass the combiners alone and let them cling to the nearest codepoint to explode:

my $x = slurp ‘combiners’; # ← that's a file with 1023 combiners
say ‘OK for now!’; # ← no problems so far!
say ‘a’ ~ $x; # ← still no problem! I'm using COMBINING DIAERESIS, so it combines with a and turns into a different normalized character!
say ‘:’ ~ $x; # Too many codepoints (1024) in grapheme

Maybe not that big deal of a deal, it's just an exception. But knowing that I can likely trigger an exception in different parts of the code just from user input alone excites me in a wrong kind of way.

Another example: do we even have a JSON parser that is not broken? It's not like making a JSON parser is a very easy task, but doing one in Raku seems to be so much harder.

Point is, even basic data types like strings in Raku have so much depth and are riddled with so many edge cases. Others would probably throw a lot of WATs at that, but the community markets it as a proper way of handling string. Meh.

Simple logic, I'd say. Words have meaning, you know.

Words have meaning which you seem to reject and substitute your own.

Anyway, it's probably my last reply here. Rereading some of the criticism about Raku, it looks like a lot of people who haven't even used Raku are able to identify a lot of fundamental issues. In some way, it's not like I'm saying what hasn't been already said, so what's the point.

I'm closing this issue, since it's gone so far away from its initial purpose it's not really worth the while to continue here.

Raku-Steering-Council / Papers

What is the philosophy of the Raku project? #3