Has Larry Wall joined the development team of raku? I can't think of the case if Matz was not in the new Ruby development team.
On Mon, Nov 22, 2021 at 7:19 PM Aureliano Guedes <guedes.aureli...@gmail.com> wrote: > Some time ago I found an example of how to integrate C++ through > NativeCall, but it is not straightforward. > If we have the advantage of using C and *C++* libs, we will just need one > more step: "convert legions of dev to our sect". > > As more devs became a rakoon, more the language became popular and > populated of tools and libs. > > Imo, the first thing we need to think about is writing really good > documentation. > Easy to navigate. Easy to understand. Easy to find practical examples. > > Few months ago I was trying to adapt the C++ lib xframe< > https://github.com/xtensor-stack/xframe>. > But I missed everything because I didn't put it on github and my HDD died, > sorry about that. > Anyway, I'm quite limited in knowledge about Raku. > > > On Mon, Nov 22, 2021 at 12:33 AM Clifton Wood <clifton.w...@gmail.com> > wrote: > >> 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 >>>>> >>>> > > -- > Aureliano Guedes > skype: aureliano.guedes > contato: (11) 94292-6110 > whatsapp +5511942926110 >
