What's the package management tool for raku? The stuff like gem/bundle for ruby and cpanm for perl5.
Thanks. On Mon, Nov 22, 2021 at 9:43 AM Ralph Mellor <ralphdjmel...@gmail.com> wrote: > My 2c: > > On Fri, Nov 19, 2021 at 9:45 AM Marc Chantreux <e...@phear.org> wrote: > > > > > I like ruby and perl > > > > so do I but raku is by far my prefered interpreted langage now. > > Nit. It's compiled, in the same way Java or C# is compiled. > > Consider: > ``` > say 42; > constant foo = die; > ``` > If it were interpreted, the `42` would appear, and then the > program would die. But instead it dies at compile-time > (`constant`s are initialized at compile-time). > > That said, the usual way of using it is to run a program, > which compiles it, and then, if it successfully compiles, > immediately runs the compiled program. > > > I don't raku that much and most of the time, i read the > > doc more than i actually write code but when it's writen, > > it's always elegant and concise the way i never seen before. > > Many folk who like Ruby or Python or Lang X say much the > same thing about those PLs. > > > > Maybe perl6 is still not production-ready? > > Imo it's as production ready as Python. > > > > but why so few open source projects which were developed by perl6? > > It's all relative. Compared to most of the thousands of PLs > with less projects, there are lots of projects developed in Raku. > > But you presumably mean in comparison to the likes of Python and Ruby. > > There are many factors. Some I'd focus on are: > > * It's unusual. Few folk like that. > > * It has a large language surface area. Few folk like that. > > * It's very slow. Very few folk like that. > > * It has no widely recognized distinctive compelling use case. > > As a consequence of these and other factors there is minimal > interest in it so far, let alone adoption. > > So now, one can add another factor: > > * It isn't interesting to most, and has had minimal adoption so far. > Almost NO folk are OK with that. > > So now, one can add another factor: > > * Almost NO folk want to help develop it. And you can't attract > them either. Unless they get it. Because then they fall in love > with it. And so it rolls. For now. > > So, for now, it needs more work, as it has always done. > > > * raku shines on interpreted langages when people are > > moving to compiled langages > > It's a compiled language, so that's not quite right. Perhaps > you meant it's dynamically typed rather than statically typed, > but that's not quite right either. > > If one squints, it's an open source alternative to Oracle's > Truffle/Graal/JVM, but it's waaaay slower. > > > * raku is that rich it's hard to get it in a first view > > I'd say it's hard to *ever* get most of it. It's as ambitious > as Truffle/Graal/JVM, perhaps even more so. > > But it should and *will* be easy to get it a little at a time. > > But we're not there yet. > > There's a fairly obvious way to make it vastly easier. > > Which is to create mini languages that aren't Raku > but showcase selected parts of its talents. > > But that will have to wait until RakuAST lands. > > And perhaps a language version *after* that. > > So perhaps 3-4 years if we're lucky. > > > * raku is still way too slow to be taken seriously > > by a large audience > > Yes. For now. > > > * js or python developpers are legions on the market > > now so everyone choose this as an argument > > Yes. And ts devs too. > > > * we need more packages on raku.land > > I don't think that's important. We need better Inlines. > > We need to deflate the packages/modules/libs argument. > > > * i really think technologies are massively adopted when they are > > packaged in main linux distros because lot of people don't want to > > bother compiling an interpreter or adding extra repos to do it. > > I can see there being an opportunity to create a popular > package before this decade is out in the form of (a fresh > repackaging of) NQP as a "Raku Rules" engine / latter > day PCRE / new alternative to Truffle/Graal/JVM. > > -- > love, raiph >
