8 ms·
Larry Wall's Perl 6 Release Talk [video]
- esaym 11y agoCool. I am glad there has been enough support and supporters over the years to push it to the finish. Compiled native executables, concurrency, async code blocks, and much more. I look forward to learning as soon as I get a chance. Hoping that companies adopt as well.
- Scarbutt 11y agocompile native executables How does that work? is the moarvm bundled in the executable?
- cygx 11y agoIt doesn't, no idea where the OP got that idea from. 'Fakecutables' bundling interpreter and bytecode might arrive in the future, though.
- esaym 11y agoI got it from here (page 33): http://www.liz.nl/C-DayIsComingYAPCEU.pdf http://www.liz.nl/C-DayIsComingYAPCEU.pdf So probably not "native" executables, but compiling and optimizing nonetheless.
- cygx 11y agoThat refers to precompilation to MoarVM bytecode. You can do that manually right now, but eventually, a precompilation cache will be managed by Rakudo.
- WizardlySquid 11y agoWow, the entire Perl community is there.
- visarga 11y agoHow fast is Perl 6 nowadays?
- rurban 11y agoFaster than Perl5 with Moose, but slower than similar languages with similar features. But there are not many with this impressive feature set.
- stesch 11y agoWith all these different implementations how hard is it to access C libraries and/or make modules that use C?
- cygx 11y agoAs simple as writing a Perl6 signature for your C function. A proper solution for deploying your own libraries has yet to arrive (you can look up library names at runtime and compile code via the module manager, but imo it's still rather ad-hoc).
- hahainternet 11y agoNot very (hard): https://github.com/jnthn/zavolaj https://github.com/jnthn/zavolaj
- Geert_Wilders 11y agoperl6 is gay
- perlgeek 11y agoNot very difficult, see http://doc.perl6.org/language/nativecall http://doc.perl6.org/language/nativecall
- chrisseaton 11y agoShame it's slower than existing work. We know pretty well how to optimise dynamic languages these days.
- drwoland 11y agoI have to work with a legacy Perl codebase most weeks and I've been ignoring Perl 6 because upgrading our interpreter version is difficult for a bunch of reasons to boring to go into. I'd been naively holding out a hope that Perl 6 would improve things so I clicked on the Perl 6 for Perl 5 programmers link from perl6.org. They added code block interpolation to strings: #!/usr/bin/env perl6 my $number = 3; say( "{ $number * 4 }" ); # prints 12
- leejo 11y agoYou can do that already in perl 5: > perl -E 'my $i = 1; say "@{[ sin $i ]}";' 0.841470984807897 perl 6 will improve things, it has a huge feature set.
- Mithaldu 11y agoThis is little different from something like: #!/usr/bin/env perl6 my $number = 3; printf( "%s\n", $number * 4 ); # prints 12 What is your complaint?
- ab5tract 11y agoReally? printf is cool and useful for it's own domain. But there is a reason that languages provide interpolation. And the simplest possible example above is not one of those reasons.
- cies 11y agoI'm really interested in this. Perl6 is so jam packed with interesting novel features, that it serves as an amazing testbed for future languages. I always feel that Ruby was a language that came out of Perl; a subset of it's features, carefully selected and implemented with the knowledge of what did not go too well with Perl. Thanks Larry and co!
- codeflo 11y agoSo, like probably many people, I was very hyped about Perl 6 in the early 2000s, followed the mailing lists and so forth, but became disappointed and stopped caring when it became painfully clear that there had been no net progress for a decade. So please excuse my skepticism, because I'm still fascinated by Perl 6's ideas and potential. But is this another "Rakudo Star" where they just take whatever current mess they have and label it "release", or is Perl 6 really finally ready now?
- giancarlostoro 11y agoI keep wondering the same, especially when perl.org mentions nothing about Perl 6. It would be really nice if they showed some sort of sign there about Perl 6. Instead all we get is Perl 5.
- perlgeek 11y agoPerl 6 is mentioned on http://dev.perl.org/ http://dev.perl.org/. I hope to get it to the perl.org front page after or on occasion of the release.
- Mithaldu 11y agoPerl.org is a completely different organization than the people around Perl 6, just how Perl 6 is a completely different language than Perl 5.
- cygx 11y agoJust to clarify, what happens at Christmas is the first proper language release (as specified by the test suite) that will be accompanied by a conforming compiler release, ie the main focus is still semantics, not 'production readiness'. That said, Rakudo of today is more usable than Rakudo of days gone by, though there are still issues (my personal pet peeve: parsing speed; hopefully, automatic precompilation will land in the not-too-distant future, which, would mitigate the problem).
- codeflo 11y agoThanks for the clarification. So what does it mean to release "a language"? Is there a specification in addition to the test suite? Is the specification frozen from that point on? Or will it change, but only in backwards compatible ways?
- kriro 11y agoSo much good stuff. I really like the kernel+distribution idea and thinking about lexer/parser and "just adding stuff to that" like the example of adding Ruby ?! syntax.
- rockshassa 11y agoWhere was this video a month ago? I looked all over for it when Perl 6 was released!
- epoch1970 11y agoWhen will a traditional interpreter written in C and running just about everywhere be available for Perl 6? All of the successful scripting languages have one: Perl 5 and earlier, Python, Ruby, Tcl, Lua, PHP, and even UNIX shell scripts. Yet when it comes to Perl 6, we just don't see that. The Perl 6 community has spun its wheels time and time and time again with half-baked interpreters written in an obscure language like Haskell, or written in Perl 6 itself using half-baked Perl 6 to 5 converters, or targeting the .NET CLR or JVM, or targeting very obscure and limited VMs like Parrot or MoarVM. It's no wonder that Perl 6 hasn't really gone anywhere after 15 years. They've done everything but the one thing they should be doing if they want success: implementing a traditional interpreter using C that runs just about everywhere!
- mrxenu 11y agoI don't quite get your point. MoarVM was created specifically for Perl 6, it is written in C and just works. JVM support in Rakudo is just added bonus and you are free to ignore it (like most users do). For 99% users "Perl 6" will mean just "Rakudo + MoarVM" which seems to be exactly what you're asking for. Note that MoarVM is nothing like Parrot. Parrot was a failed project which intended to bring universal VM for all dynamic languages. Obviously, too wide project scope resulted in broken and unmaintainable implementation. MoarVM is made just for Perl 6 and intends to avoid repeating its predecessor's mistakes.
- epoch1970 11y agoI'd like to use Perl 6, but after 15 years of waiting there still isn't an implementation ready for production use. Rakudo and MoarVM clearly aren't what we, as potential Perl 6 developers and users, want. They look far too similar to the many other similar Perl 6 failures we've seen. How are we to trust that Rakudo won't go the way of Pugs, or that MoarVM won't go the way of Parrot, leaving us in a lurch? Even if they do remain viable, we don't want to have to deal with separate VMs, regardless of whether they're specific to Perl 6 or not. We don't want to deal with the bugs and compatibility issues that invariably pop up when dealing with separate compilers and VMs. Like I said, we want the Perl 5, Ruby, Python, Lua, and Tcl type of experience. We want there to be one consistent implementation that's widely used and trusted. We want something proven and familiar. Unfortunately, we aren't getting that with Rakudo and MoarVM, nor from the many other unsuccessful attempts in the past.