- optional, well-integrated gradual typing system.
- perl6 is the first mainstream(ish) dynamic language to not suffer from a GIL of some kind. You can do real concurrency and parallelism in perl6.
- perl6 is both equally as powerful, and much more simple than previous versions of perl.
- a bunch of good ideas stolen from other languages. go-routines are in there, pattern-matching, gradual typing, classes, etc. Plus, functional programming is a first-class-citizen of perl6. There's so much good stuff in there.
- overall, I think perl6 has the potential to become a very powerful (and yet robust and well engineered) hacker language, where you will not be constrained by implementation details of the VM the language runs on (I'm looking at you, GIL).
I'd also recommend reading Curtis Poe's answer to a similar question:
https://www.quora.com/Perl-programming-language-1/Should-I-b...
I went digging to try and understand what this meant, and seems it's referring to syntactic support for promises, which in at least the Rakudo implementation amount to a wrapper around a forking multiprocessing system (like the Python multiprocessing module).
From my perspective this concurrency isn't any more "real" than equivalents available in existing languages, but maybe I'm looking at the wrong thing - you mention global interpreter locks, and usually they refer to threading.
Does some implementation of perl6 have non-GIL threading?
edit: from <https://perl6advent.wordpress.com/2012/12/11/day-11-parrot-t...:
> The solution for these problems implemented in hybrid threads is to sidestep them altogether by disallowing write access to shared variables. The programmer (or in most cases the compiler) is obliged to declare a list of all shared variables before a newly created task is started. The interpreter would then create proxy objects for these variables which the task can use to access the data. These proxies contain references to the original objects. They use these references to forward all reading vtable functions to the originals. Write access on the other hand would lead to a runtime error.
> In other words, all data is owned by the thread creating it and only the owner may write to it. Other threads have only read access.
> For threads to be able to communicate with their creators and other threads, they still need to write to shared variables. This is where green threads come into play. Since green threads are light weight, it is feasible for a thread to create a task just for updating a variable. This task is scheduled on the interpreter owning this variable. To reduce latency, the task is flagged to run immediately. The data-owning interpreter will preempt the currently running task and process the new write task. Put another way, the data-owning interpreter is told what to write to its variables, so other threads don’t have to.
It's pretty clear the GP knows what a GIL is, he's wondering if Perl 6 is truly GIL-free, or if it "just" abstracts out the GIL using language primitives for a forking multiprocess system (already, that's a nice step, but it's not "GIL-free").
I'd like to know the same thing.
Rakudo's had more testing since it's been around forever but MoarVM is where my hopes lie. Here's hoping user adoption isn't fractured that badly like D's Tango vs Phobos debacle (which only now it's recovering from, I'd argue largely due to Andrei Alexandrescu's charismatic persona, haha.) Perl 6 is a really interesting language and I'd encourage you all to play with it, but it's an entirely different beast than Perl 5. They should have just renamed it entirely.
Is that wrong? If not, did you mean "Rakudo on Parrot" or "Rakudo on the JVM" when you wrote just "Rakudo"?
It's like this: Rakudo -> NQP -> MoarVM
or like this: Rakudo -> NQP -> NQP-JVM implementation -> JVM
Want to get Perl 6 running on the .Net CLR? Implement an NQP interpreter (which is supposed to be fairly easy) and you're 99% done (at least that's my understanding).
Sure, MoarVM is by design semantically close to NQP, but if you look at
$ nqp-m --stagestats -e ''
Stage start : 0.000
Stage parse : 0.003
Stage ast : 0.000
Stage optimize : 0.000
Stage mast : 0.005
Stage mbc : 0.000
Stage moar : 0.000
$ nqp-j --stagestats -e ''
Stage start : 0.000
Stage classname : 0.045
Stage parse : 0.067
Stage ast : 0.000
Stage optimize : 0.009
Stage jast : 0.145
Stage classfile : 0.010
Stage jar : 0.000
Stage jvm : 0.003
The current VMs are MoarVM, JVM, and some are working on a JavaScript backend.
Parrot isn't wholly abandoned, but Reini Urban is the only person still hacking on it. On the other hand, he is the person most likely to bring Parrot back around to being a good backend for Perl 6, so it has that going for it.
Currently no implementation of Perl 6 targets Parrot. Rakudo used to (indeed, was born on Parrot), but suspended support for Parrot in connection with the push to get Rakudo-on-MoarVM up to 6.0.0 quality by Christmas. The Rakudo team were careful not to say they were writing Parrot off, but they also gave no particular criteria for when they would unsuspend it.
(I in no way speak for Rakudo or anyone else, but I suspect the implicit criteria for unsuspension are three: Parrot must demonstrate, in code, that being a good backend for Perl 6 is a higher priority than being a good backend for entirely hypothetical other clients; it must undertake, survive, and complete a major decrufting if not re-architecting; and of course, it must be more interesting, for enough people, to target Parrot than to hack Perl 6 on Moar, JVM, JS, Mono, the perl5 VM, p2, WebAssembly, native code, the Factor VM, or whatever else.)
There are also those who view MoarVM as the new Parrot -- Parrot as it would have been if its implementation hadn't started until it was clear what Perl 6 would really need under it. (Aaaaaand without the technical or political fallout of "let's make a VM for ALL the dynamic languages!")
Aaaaaand without the technical or political fallout of "let's make a VM for ALL the dynamic languages!"
I remember Larry being really keen on that idea. The quote went something like "If everyone complains that CPAN gives Perl an unfair advantage, let's give everyone access to CPAN."
Why would I think that? I am aware of your recollections. I have read everything you blogged about the collapse of Parrot.
I have also read everything several other people wrote about the inception of MoarVM and the suspension of Parrot support, including key figures from both sides and several third-party observers. I have read the IRC logs of Parrot design meetings, including negotiations with the Rakudo leads, for the period leading up to the rupture. I have read key announcements by Parrot and Rakudo lead designers from earlier than this, wherein I think I see the seeds of the breakdown sown.
I made a detailed study of all this last spring, when I learned about the suspension. I have also been checking in intermittently on Parrot since 2002, and on every Perl 6 implementation I could find since the post-Pugs revival. And since last spring I have been kept aware of your position in particular through sundry comments here and on Reddit; you are a reliable presence whenever someone mentions Perl 6 or Rakudo without condemning it.
I can't speak to specific differences between my opinions and your recollections, since you did not see fit to say what those were. But I am hardly uninformed and I know of no error in what I said (viz., the actual words that I typed).
[1] If I wanted a document to make my point for me, I could hardly do better than the 2003 State of the Onion. Here's where Larry's head was in 2003: Yes, he thought a multi-language VM was just what Perl needed. He also thought that the Perl 6 design was basically done. He clearly didn't think there would be too much difference in kind between Parrot and the p5p runtime, as shown by his speculating that Ponie could be ready to support 5.10 and could entirely replace p5p by 5.12. He had not yet written the Apocalypse on the object system; its release in 2004 is really when it became clear how deep and structural the changes from 5 to 6 would be, and consequently it's also when it really became clear what a VM would need to provide to be good for Perl 6. Heck, in 2003 Larry thought "slow progress" meant a couple of major redesign documents a year, and he thought slow progress was just coming to an end. About the only thing that address was right about is that Larry didn't know very much. (Well, that and the switch statement.) If I'm saying reality disproved early conceptions about the realization of Perl 6, SotO 2003 is Exhibit A.
I think that's part of the problem--there are too many post-hoc justifications for why things happened the way they did that ignore what actually happened and why people made the decisions they did.
Dan's Parrot postmortem is still accurate: there just wasn't the will to turn P6 into a real, stable, shipping product, and there wasn't the honest acknowledgement that P6 wouldn't be a realistic replacement for Perl until far too late.
Admittedly, not everyone would define it as mainstream... but Tcl doesn't have a GIL and has had threading for a good, long time.
GILs are features of implementations, not languages; Ruby has implementations (most notably JRuby) without a GIL. And Clojure doesn't have a GIL, and seems to be approaching mainstream.
And Perl 6 isn't mainstream yet (it hopes to be, but then so do most languages.) And there's plenty of not-currently-mainstream dynamic languages without GILs in their primary implementations; many in the Lisp/Scheme family.
Initially it was used to extract tables from text documents, and its always had a strong focus on text manipulation and regular expressions.
Its implicit variables and syntax mean you can write very, very concise code. Yet by following stylistic guidelines of your choice, you can write code that looks sane and maintainable.
I really like the fact you can import os commands and call them as a part of the language. It makes writing scripts a breeze. In fact writing anything in perl is a breeze. Check rosetta code, you'll see Perl 6 is one of the most concise at every turn.
As much as I really like python, I find that calling system commands is a pain.. calling os.system is obviously far from great, and calling subprocess can get cumbersome.
I haven't played with perl in a while, but my past experiences with perl was always getting a lot done, with very little work.
I worked with Perl for 4 years, and while it's not the gauntlet of pain that people make it out to be, there were several annoyances (like needing to always hit the docs for that stuff).
What did you use it for, if I may ask? What how big a project are we talking about?
I would have thought hitting the docs wouldn't be a part of the annoyances list. Did you feel you had to hit the docs more than with any other language?
I understand it's a trade off. We don't have a large standard library in Perl like Python does, and that means there's a bit of searching required to find what to use, but that's often a benefit as well as a drawback. Would we have Path::Tiny if we had something that provided some but not all of the capability, and not as well? Would we have DateTime (or would it be popular) if we had a core DateTime-like module that was problematic, but mostly worked? Part of the beauty of having a small core set of libraries and an large and vibrant set of extended libraries is that the constant churn leads to newer and better things. Really what I'm lamenting, is that while there are these benefits to the churn, it still does lead to some painful situations where you find you've been using a poor choice for your needs just because you didn't know of the better choice that was out there. It's acceptable if it leads to DBIC, DateTime, Path::Tiny, etc, but it still sucks some times.
Having a LARGE core does as well, and mostly that any modules in the Perl core seem to also have their API and features frozen in time. Even if those features and API are not so good - it's in core! So, there's a reason to keep them how broken they are for backwards-compatibility sake.
I've also felt the burn of a core module that's then removed, and the new maintainer now going absolutely wild changing things. I understand exactly why they want to change things, and would not disagree with their ideas in a vacuum, but it causes great grief to me when I'm supporting apps that relied on in-core modules that have been upgraded out of core.
I wanna say that this problem is being used as a lesson for Perl 6 - that the core for the, "official/main/whatever" distro is going to be kept very spartan, but it's going to be encouraged to build upon that distro for your own Perl 6 releases. So, if you want the, "Web Framework" release, it'll come with all the bits and pieces you need to get that going - however editorialized that selection will be.
Moritz talks about this concept, here:
http://perlgeek.de/blog-en/perl-6/how-core-is-core.html
Although this post is pretty old, and I'd hate to say that their line of thinking now.
Have a look at the 'sh' python module to ease your pain: http://pypi.python.org/pypi/sh
For me the greatest advantage of the Perl5/shell integration is that you can use Perl's sane data structures, flow control, and code organization features instead of their bash equivalents which have endless pitfalls and can be less portable than basic Perl5.
To me the most unique aspect is Perl 6's unicode string handling which is probably the best unicode support of any language out there. I could see it catching on in niches that need to do heavy cross-characterset text processing.