One way you might arranging programming languages in a 2D space is with two axes: 1. How much should the language surprise you? 2. When the language does surprise you, should it delight you or horrify you? surprising ^ | | | delight horrify | | | v unsurprising Only a sadist would deliberately design a language for the top right quadrant, but there are many esoteric languages in there. I think most people tacitly ass…
I clearly remember reading through the synopsis and exegesis documents around fifteen years ago and being excited for what was to come, but I also remember the first bits that gave me pause. Like unspace[1].
I also clearly remember when it started dawning on me that Perl 6 (as it was still called at the time) would never see any real adoption by people that were interested in other people working with them on things, whether that be some open source project or at a company with coworkers. It was when I was reading through the advent calendar exercises for some year and realized that while I couldn't recall half the features used to solve the problems, I had been exposed to them all multiple times before. The reason I couldn't remember them was because there were so many ways to solve the problems, that it felt like just keeping up with the features and syntax was overwhelming, and that unless you used a very strict subset of the language, it would be near impossible to limit the effort requires to understand what you read from others, or even yourself some time previously.
To many detractors of Perl, this won't be an unfamiliar complaint, but I've always felt that while Perl (5) projects could easily devolve into a mess if some care wasn't taken, it wasn't that hard to exercise some restraint and still take advantage of the extra capabilities when more power was needed. Put another way, while there was definitely more than one way to do it, it didn't feel like there were tens of vastly different ways of doing it that might have been sourced from random inclusions anywhere in the codebase because of numerous ways to insert entry points into every block, leaving you scratching your head when you encountered odd behavior.
Now, it's not a problem for a language to want to reside squarely in the "this is for screwing around and trying any feature you can imagine and how they interact together", but that's not necessarily great when you are trying to accomplish something with someone else and you need to have a shared base of understanding to work from. The real problem is that many, many people in the Perl6/Raku community obviously really hoped for it to take over for Perl 5 or at least be useful for projects which might have multiple people working on them, whether they be through github or for some commercial work entity with coworkers, so they could spread its use and have a reason to use it on a regular basis. I think once it became clear that it wouldn't serve that purpose as well, many people lost interest. I know that was the case for me. I was an avid lurker on the project for well over a decade, but eventually I just couldn't convince myself it was a good idea to use the language for anything other than small test programs to satisfy my own curiosity, and eventually not even there, since if I didn't already have it installed the overhead for a small test was quite high.
In the end I guess Raku found its niche, and it's doing okay where it is (I assume, I've fallen so out of date I'm not sure), but it's sad that it seems they had to shed a lot of their original community (as someone who identifies as part of their original community) to do so, whether that's through any concerted effort on their own part or not. That is, I don't think Raku changed to be what it is, I think most people eventually realized what the bundle of features that was originally proposed really means in reality, and realized it didn't fit what they actually wanted.