> Since you mention it, I would say that raku is yet to find its killer app. [...] I for one would be happy to have a strategy for this - and would welcome your

> Since you mention it, I would say that raku is yet to find its killer app. [...] I for one would be happy to have a strategy for this - and would welcome your thoughts on what this should contain. Please take a look at Glamorous Toolkit (https://gtoolkit.com/ https://gtoolkit.com/). Whether that's warranted or not, the authors claim to have invented a new paradigm of working with software systems. GT is marketed as a "moldable development environment" more than as a "Smalltalk dialect with dynamic, customizable UI." Would finding a catchy phrase describing Raku programming help? I think it could. Or maybe there's already one that I'm not aware of? Even better would be to find something that Raku is unusually well-suited for, better than all, save for just 1 or 2 contenders. Advertising Raku through that could have dramatic effects. However, this is harder to achieve with a general-purpose language. Fortunately, Raku doesn't lack in interesting features and I'm sure there are (still undiscovered or not publicized enough) domains where a particular combination of Raku's features make it one of the best tools for a job. Once you manage to find a few such domains, it's only a matter of luck: at some point, any of these can become popular, elevating the language along with the use case. However, for luck to work, you need to have those domains thoroughly explored - the famous Rails video wouldn't exist without Rails. > Another effective strategy for breaking into the mainstream is to have the weight of a big/influential corporation behind you [...] that doesn't apply to raku either. You might try for corporate sponsorship or government grants. Both ways I know nothing about - I just notice that some work on Haxe is financed through industry grants, while some work on OCaml is paid for by the EU. In general, sustaining a project as large as a programming language is far outside of my expertise; I won't be of much help on that front :( > In the meantime, I guess the hope for breaking into the mainstream is to do a solid job with language development. Yes, that is a good strategy :) As mentioned above, getting into the spotlight and capitalizing on it is largely a matter of luck, and to make use of good luck, you first need a solid project. > Recently the focus has been on Raku AST (which is a forerunner to Macros). That's good - Raku has an infinity of ways for runtime metaprogramming, but almost none for compile-time metaprogramming. Standardized AST and macro support will be a very welcome addition to the language. This might be a good time to mention: are you familiar with how Elixir is developed? I'm not too close to that community, but it looks like the Elixir folks split the work between the language proper and a flagship project of the year (roughly). Those flagships are projects that, ideally, make use of Elixir's unique features to build "best in class" solution. I think Ecto - data persistence library interfacing with RDBMSes - was the first such project. I don't remember the details, but there was a project for IoT (Nerves?) and later Numeric Elixir (numpy equivalent?) - and some other things in between. Phoenix and LiveView, too. I think that's a pretty clever marketing strategy - everybody knows what an ORM (for example) is, so if you write a headline like "Ecto - the best non-ORM you never heard of" you have a chance to get an eyeball or two. > In addition to this, the community has actively taken over support for the raku IDE which was kindly donated by Edument ... Comma Plugin 2.0 is now available (IntelliJ IDEA plugin) along with several other tooling options. I didn't know, thanks for mentioning it. I'll definitely check it out. > Yes, there have been some (too many!) historic missteps - but the rakudo compiler / moarvm (runtime) combination has been the settled path since 2015. Agreed :) > I'm sorry to hear that `.assuming` was 1000x slower codepath for you and that issue was not fixed in a timely way. No, no, it wasn't that big of a deal at all! It was just an example of a "rough edge" that I think was left there because of a lack of manpower. > I choose to use raku in my business for small projects I don't have the luxury to use Raku in my day job, but I use it for small personal projects, mostly related to parsing things, and for general-purpose scripting. > I do contend that the raku community is sufficiently large and committed to deliver continuous improvement overall despite the high ambition and large surface area of the codebase Agreed - I'm sorry if it sounded too negatively, but that's what I meant by "keeping the lights on". Yes - Raku is moving in the right direction at a noticeable (non-glacial) pace. From the looks of it, the compiler and the VM are solid pieces of engineering and they are improving. However, without a concurrent effort in marketing the language, preferably with some "killer apps" already in place, "just" doing a good job implementing the language might not be enough for Raku to succeed. That's my main worry :( --- One thing that didn't fit above. Are there plans to improve static type checking in Raku? Raku looks gradually-typed, but actually isn't - most of the type checks happen on runtime, at least in my experience. This is very similar to Dylan language. Is there any work being done on strengthtening the type system and adding type inference, occurence typing, and (maybe) refinement types? It should be possible - I read a paper about adding gradual typing to Dylan, which also is based on multi-methods and multiple inheritance. So I think there's a lot of type-checking the compiler could (try to) do. IMO, going in this direction would help Raku codebases scale to larger projects. EDIT: if you'd like to continue the discussion, please shoot me an email (in my profile).