Ralph: It has *two* compelling use cases, and it's the ones that brought me to Raku in the first place:
- First class C integration without the need for C (NativeCall) - Grammars I have gone through over 20 C libraries with at least a modicum of success. All in Raku. All easily done to get the basic support (C stubs). I've written utilities that make much of the work of porting an .h file as simple as running a single script. Hopefully I will be able to get these projects out the door, but I have to overcome the CURI output limitations first. I'd really like to have a custom installer built to handle output to the user while pre-compiling, but I've decided that's something that can wait for the future. I guess I'll be releasing the first lib sometime soon. - Xliff On Sun, Nov 21, 2021 at 10:28 PM Clifton Wood <clifton.w...@gmail.com> wrote: > Piper: That would be zef > > https://github.com/ugexe/zef > > On Sun, Nov 21, 2021 at 8:51 PM Piper H <pott...@gmail.com> wrote: > >> 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 >>> >>
