Ask HN: Perl 6: Do you use it, how do you like it, what do you do with it?
I'm sort-of intrigued by Perl 6, but a curiosity of mine, which I believe that I share with some other people, is how it's used in the real world, be it in little scripts or commercial software. What are your feelings and comments on Perl 6, and if you use it, how and where you use it (I'd be glad it people shared links to published projects and actual code out in the internet). Thanks in advance!
162 comments
[ 2.8 ms ] story [ 246 ms ] threadAlso, perl 6 is effectively a completely different language from 'normal' perl (i.e. perl 5.x). The difference between the two is far far bigger than say python 2 -> 3.
As a perl programmer, I see no obvious benefit from switching from perl 5 -> 6, it would be the same as switching from perl to a completely different language. You're not going to be able to take your existing code and familiar libraries with you.
To be clear, Inline::Perl5 (and the other inlines like Inline::Python) automatically marshal data.
And exceptions. And classes (so you can sub-class a Perl 5 or Python etc. class in Perl 6). Etc.
The project has mostly stalled since Inline::Perl5 became so effective. v5 had the issue of being unable to easily support binary XS type modules. Which means it could never support CPAN, unlike Inline::Perl5. It was meant for people to be able to copy their high mental cost algo code into a new Perl 6 project without fuss.
It has signature, and subsignature parsing, built-in concurrency, not to mention over a dozen other features that are not in Perl 5. The main reason it is called Perl 6 is how the project began. It started out as Perl 5 minus a few warts.
As someone who well versed in both, they are very similar, and very different at the same time.
I like to categorize the differences like this:
Perl 4 is to C, as Perl 5 is to C++, as Perl 6 is to Haskell,Scheme,C#,D,Go,BNF...
That is Perl 6 brings in features from many diverse programming languages, and combines them in such a way that it feels like they have always belonged together.
Mojolicious is a much younger project than Catalyst, started by the original developer of Catalyst several years after he left the project, So the chronology doesn't work out - by the time Mojolicious showed up, Catalyst was already very well established as the serious Perl web framework.
Although for devs who wandered back to Perl from Rails, Node, Python or elsewhere, Mojolicious has a lot to offer.
1. https://github.com/dnmfarrell/Perl6-One-Liners
Let's say that I'm glad that Perl 6 is there as an option.
Traits and roles are really neat - they feel like a natural conclusion to what Ruby started building upon with respect to metaprogramming natural syntax and encouraging developer happiness over strictness.
On the whole, however, many small parts of Perl 6 feel immature. There's no core JSON/YAML module, and there's no "official" module manager yet - just panda[1] and a few others.
Overall I'd recommend tinkering with it, but I don't think it's ready (as an ecosystem) for larger development. Hopefully soon, though!
[1]: https://github.com/tadzik/panda
https://github.com/ugexe/zef
http://modules.zef.pm/
The ecosystem is still young, and "not ready" is a perfectly reasonable point of view, but you're using definitions of core/official that don't really apply - rakudo is the base compiler, not a complete release.
No. We only include things as part of the language where the design of it is immediately obvious, and is useful for many applications. It also helps if it has been proven in other languages. So Promises(Futures) are in there, but many other things are not. You can do anything in a module, so write an external module for it instead.
Otherwise we would have the problems where the best module for the job is not in the runtime, but everyone uses the one that is in the runtime.
I have heard that Python has this problem with HTTP. Think of it like this, a module for doing X is included with the first version of a language. That means it is a module that was not written by an expert, because at that point in time there was no expert in the language. Everyone uses it though; as you don't have to install it, because it is already there.
We don't have an official module manager, because we want all of them to be equally as official as every other one. It is a good thing too; as most people in the know use zef currently, rather than panda. If we had one that was official, it would have been panda.
That's also why there is not, nor will ever be an official implementation. Any implementation that passes the test suite is just as official as every other one. (although there is only one currently)
Basically you are asking for things to be included, that are specifically not included for very good reasons. The way that this is dealt with is by using the idea of distributions like "Rakudo Star" for Perl 6, or "Strawberry Perl" for Perl 5 on windows. That is an implementation of Perl 6 along with a set of useful modules.
* Users don't have to worry about inconsistent distributions. Following a test suite is one thing, but test suites are (almost) never comprehensive and will not catch programmer errors with respect to particular systems (e.g, LP64 and LLP64). Everything will work until it doesn't, and programmers will have to provide edge-case workarounds until individual distributions fix their implementations.
The same goes for module managers. It's good to provide an open spec and encourage multiple frontends, but it's also good to provide a uniform interface for system administrators who just want to automate module installation for an application or framework. Python's easy_install wasn't ideal, but it provided exactly that sort of common denominator.
"Batteries included" makes it sound like I want my language to come with a playground, which I think is an unfair way to characterize the expectation that Perl 6 provide feature parity with the languages it competes with (i.e., Ruby 2 and Python 3).
There are 9 chapters out there already, which you get you started nicely. Feedback would be very welcome!
I had issues finding the right modules to use, like which webserver to use, with which module to make http requests. But the biggest issue was that the hoster I initially wanted to use doesn't have perl6 pre-installed, and compiling it fails because the compilation itself uses too much memory. I then moved it to a bare metal server, where compiling Rakudo Star succeeded.
The whole Rakudo Star thing, that there are different VMs (that there are VMs in the first place), that there are different module manager, all that was totally confusing. But I liked the language itself a bit, it was nice testing something else.
I hadn't even realized Perl 6 was out! I remember years ago it kind of being labeled as the "Duke Nukem Forever" of programming languages versions. I don't personally use it but I'm glad to see it is out (even if I found out a year late).
To put it mildly.
"In the 20th century I followed the development of perl 6"
Aiui there's some merit to the notion of The Lisp Curse[1] and he wanted to avoid it. Do you reject the notion of the curse, or think it doesn't apply to P6, or think he overdid it, or...?
Do you recall any specific features you felt went over the top?
[1] eg https://news.ycombinator.com/item?id=2450973
For those not familiar, The Forth Curse is what happens when you make a language trivially easy to extend but don't write a large enough standard library of functions or procedures for it. Then your extensible language indeed gets easily extended at every site where it's used. The problem is that it's extended slightly differently in each place to do quite common things slightly differently and in wildly incompatible ways.
I have no plans to try and ship software written in it.
Personally I think the optional typing looks interesting.
While CPAN hosts a vast archive of nearly 35,000 modules[1], many are aging. Fewer than 800 modules are known to exist for Perl 6.[2]
[1] http://www.modulecounts.com/ [2] https://modules.perl6.org/
I'm not sure what you find archaic about CPAN, the package/distribution distinction is a huge win that the rest of the world still hasn't caught on to, and the file-based nature means it scales stupidly well (npm's scaling issues simply can't happen to us).
Unless by archaic you mean "built as simply as possible, and built to last", which is basically why I love it :)
Why do you say that? Is this a theoretical point, a reasonable conclusion based on reading about Perl 6, or something based on trying and failing to do something with Perl 6?
> IMHO, CPAN is anything but vibrant by today's standards.
Have you encountered problems that aren't being addressed? What do you make of the river cleanup effort[1] and the new metacpan?[2]
> many [CPAN modules] are aging.
Do you agree that "aging" that's due to modules continuing to work without needing to be changed (due to careful maintenance of backward compatibility and mass testing[3]) is actually a good thing even if it looks bad?
Do you agree that the same "aging" point can reasonably be made about the module archives of Python, Haskell, Fortran and Rust? If not, what is/are the key difference(s)?
> Fewer than 800 modules are known to exist for Perl 6.
Do you agree this might be a good sign, reflecting the "lots built in" aspect of Perl 6?
Are you aware that it's possible to use ordinary Perl 6 code with modules from Python, Ruby, Lua, Perl 5, etc.?[4]
[1] http://neilb.org/2015/04/20/river-of-cpan.html
[2] https://metacpan.org/about/meta_hack
[3] http://stats.cpantesters.org/
[4] http://modules.perl6.org/#q=inline
This isn't all old code churn either, from some brief clicking around new CPAN distributions in January peaked in 2005 at 251, whereas January 2017 saw 187[3].
Sure, Perl has been surpassed to a large extent proportional to other languages, but what tends to get forgotten in these comparison between language popularity is that even languages that have "fallen from grace" are comparatively going just as strong as they were 10 years ago, because computing has grown in the aggregate.
Which means that while your language of choice may not be as well known to your typical programmer as it was 10 years ago, the likelyhood of finding an existing module to perform some task is about the same.
1. http://stats.cpantesters.org/trends.html#stats12
2. http://stats.cpantesters.org/newdistros/2005.html
3. http://stats.cpantesters.org/newdistros/2017.html
Here's a link I found on Reddit showing an example of using Python's matplotlib from Perl 6.
https://gist.github.com/awwaiid/ef3f0abcfa96e34977b4
[1] https://github.com/colomon/ABC/blob/master/lib/ABC/Grammar.p...
Edited to add: I think originally based it on https://web.archive.org/web/20120201072612/http://www.norbec...
https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292...
https://media.ccc.de/v/32c3-7130-the_perl_jam_2
There I said the same as the presenter in the videos about his preferred language. In one line.
Really. There's lots of things wrong with Perl (all versions) and the same can be said about any other language. Alas these talks are among the worst put together criticisms I've seen so far.
Which are good points, but you probably knew that anyway. The rest is just a lot of pictures from the web and some guy screaming "wtf!!" a lot.
It has very little to do with Perl5 the language. The part where he touches on that subject is based on misunderstandings on what contexts and references are.
I'll pass -- if it was just a troll (both times?), well I can't stand trolls anyway.
I didn't find it at all entertaining or funny. Mostly it just sounded sanctimonious.
Capital letter keywords etc.
Wish it was more like Perl 5 and more performant.
But we shall see, it might change a lot the next years as it matures.
Unless you mean capitalized built-in classes, or the infix meta operators.
Certain parts are faster than Perl 5, for example this finds the sum of a range in less than a millisecond. ( of course it cheats by calling the sum method on the Range object )
That was the syntax for a left fold using the infix numeric addition operator. ( You can use just about any infix operator there and it will be a right fold if the operator says that is what it should do )There are other places where if you write your code carefully knowing the ins and outs of the implementation, where Perl 6 is faster than you could get in Perl 5.
Then there is the fact that a lot of optimizations that are known about aren't being done, and a new JIT is in the works for MoarVM.
If it's in ALL CAPS then it's drawing some attention to the fact that something VERY UNUSUAL is going on.
For example, `WHAT`, `HOW` etc. are special compiler macros, not at all ordinary routines. Fortunately there's little or no need to use these in typical Perl 6 programs.
Another example are the "phasers" CATCH, LEAVE, UNDO, etc. These are unusual because they are executed according to execution phases rather than the sequential order of code.
Another convention is use of initial caps. All built in object type names use initial caps. Hence `Int` for the arbitrary size integer type. (Use `int` for the native machine oriented alternative.)
This all may sound weird but I find it works well for me in practice.
Note that this has more to do with familiarity and syntax than the new features etc. I very much hope for a "Java killer" in the Perl family but that means performance must be a first priority.
Thanks for explaining, at least I can view examples with a little more understanding of the syntax choices going forward.
As far as speed is concerned - with the modern approach to concurrent programming, it does not really make a difference which of the above languages you'd choose, as long as your architecture is right. IO::Async may in many scenarious be faster than Node, Perl devs are probably 2x the price of a JS guy...
So the question for Perl6 is really - when, if ever, is it going to have tools like npm, make, pip to simplify the maintenance of a project. Not to mention proper debugger (i.e. Perl6 debugging plugin for VSCODE).
Perl6 is a lot of syntax even for Perl5 oldies like myself, and I'll need a very long list of assurances to convince any client/manager/colleague to take this road. Because chances are I end up being the only living soul on the planet able to maintain my Perl6 code.
After all - R&D is not only about the initial writing (that'd be 15-20% of all time), but also debugging (huge part), CI (some 15-20%), and post-release support.
Unfortunately languages like Scala and ES6 are presently way more appealing with already-complete ecosystems of tools and editors. They also provide pretty much the same performance for likewise non-enterprise projects. On the contrary - in order to introduce Perl6 in an enterprise (where Perl5 is still considered an option), one would have to have a very convincing set of arguments...
1) Node did not invent concurrency, Hoare did (if a single person should ever be credited on this), others understood the concept some 20 years.
2) Node was originally based on a library by a very-controversial, still largely acclaimed Perl contributor
3) 'use strict' is indeed a Perl idea, but (to a certain extent) is the JSON format
4) The first JS repository was not npm, but JSAN, and it was started (guess) by Perl guys back in 2005 (if I remember), now long abandoned.
Basically - after teaching JS and Perl for many years (10+ Perl, 4+ JS) I can confidently say that JS has always had a thing about Perl5 while Perl5 devs knew very well how to express stuff in JS from day 1, as both languages are originally very lexical, very dynamic and lazy, etc.
In fact the languages Perl / JS / Python are quite similar by nature. So what? We don't have Python in the browser, even though transpiling would've been so straightforward.
I fail to understand how it was not so-obvious-for-everyone that devs would spare syntax for cleaner source code. Its a very broad statement, but ES*, Python and Scala - all these have very clean syntax, and are very likely here to stay (probably Go should be in this list also). In fact - universities started using Python to teach introductory classes, rather than C. Guess why - strict rules, clear syntax, easy learning curve.
The motivation for this is that DEVs get easily replaced as a resource. And that's big in terms of planning and HR. Back in the 90's, Perl5 was a definite power-horse, because no dynamic language combined different coding phenomena so well. With all due regards for all the great minds that worked on Perl6 - nowadays, there are many smart languages. And Perl needs to do more than syntax/context/name-it magic to win back confidence.
"Update on 11/24/2016: Dan Shaw, one of the founders of Node Source and NodeUp podcast said at SFNode that Ryan Dahl is into AI and machine learning."[1]
[1]https://www.quora.com/What-happened-to-Ryan-Dahl
Though, I'm more or less surprised that things are as you say in France.
Unfortunately (as I happen to be a relatively big fan of Perl5) the market for even "core" Perl developers (e.g. a core perl/module/framework developer with name recognition and solid track record) is less than half the going rate of the equivalent in Node.js for example. Perl unfortunately (as a hiring manager) seems very stratisfied too - there is a whole lot of exceptional talent, and a whole lot of horrible talent - and not a lot in the middle.
I don't know if there is really a market for "below average" Perl programmers these days like there is for JS or PHP - so entry level and other code janitor positions likely do pay more simply due to there being a lack of junior devs learning Perl these days. Those left taking those lower paying Perl jobs are likely not exactly the team of the Perl crop, much less programming crop.
That is the harsh reality of being a Perl shop these days, for better or worse. However the language is much stronger and much more modern than most on HN give it credit for. Properly written Modern Perl in 2017 is much different than the Perl you wrote as a 17 year old making $300 on his first CGI app. It may however be a case of too little too late.
https://perl6advent.wordpress.com/2015/12/23/day-23-macros-a...
Hang on. Python 3.x is an interpreter with a GIL. So, strike one lang from your list.
> C3 resolution
Perl 6 uses C3 by default for its own default object model but it's carefully designed to also interop with languages whose MRO is NOT C3.
That strikes out another couple of langs on your list (unless you don't care about nice lang interop).
> reasonable regex engine
Perl 6 parses itself with its rules engine. Try that with a reasonable regex engine. :)
Just as significant, most "reasonable regex engines" are tuned for dealing with codepoints, not characters[1]. In 2017, that's looking increasingly unreasonable.
> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
[1] http://www.unicode.org/glossary/#grapheme
Speaking of C3 - Python is C3 by default, and while others are not, JS guys figured mixins, which give pretty much the same expression of "horizontal-composition". Besides, all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Reasonable REGEXP engine means, that every sane language out there has some level of Perl5 (or PCRE) support. That is reasonable, as long as you don't get to parse mini-langs with grammers everyday. Don't get me wrong - I'm huge fan of Perl6 BNF-like notation for grammars, but see - grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing. Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
And, please, don't give me the Booking.com example, as its a bastion of Perl devs, that was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
UPDATEL Just for the record - I've been waiting/following Perl6 news for ages, shaked Larry's hand at FOSDEM when he announced it, and still fail to find a reason to move to language with no CPAN, no BOOKS, with a very complex and comprehensive syntax and (as many pointed) no big enterprise to back its adoption...
The good news for Perl 6 is that books are incoming. O'Reilly has taken on both Learning Perl 6 (by the formidable teacher brian d foy) for a summer 2017 release, and Think Perl 6 (a translation of Think Python by Laurent Rosenfeld and Allen B. Downey; unedited draft available now). Moritz Lenz is developing his manuscript of Perl 6 by Example publicly on his blog (perlgeek.de), and Ken Youens-Clark has released an e-book on doing metagenomics in Perl 6, which includes a substantial Perl 6 tutorial.
As to CPAN, with Inline::Perl5 the entire Perl 5 CPAN is available to Perl 6 -- and if you call now, we'll throw in Inline::Python for no additional cost!
I misread what you wrote. My apologies.
> concurrency is ... not about multi-threading
Agreed.
(Fwiw, I think part of what threw me is that almost all proglangs can do some concurrency -- folk have been forking with Perl for nearly 30 years -- but that reminds me of the notion that most proglangs are turing equivalent.)
> all dev moves towards functional programming, and people care less about MRO's as functional paradigms replace some complex OO paradigms.
Agreed.
> Reasonable REGEXP engine means ... PCRE
OK.
> grammars, FSMs, regexpes, so forth... these are different names/views/uses for the same thing.
(Agreed in a sense analogous to forking and SIMD being different names/views/uses of concurrency/parallelism/async.)
> Most important is to understand the tools in a toolbox, not just to be happy about how shiny a particular screwdriver is.
Agreed.
> I'm prepared to not take offense by your last comment. Its been days and I don't see a single comment of s.o. using Perl6 for enterprise stuff.
Apologies for the confusion but please note that I simply agreed with you and closed with a hopeful parting:
>>> I'll need a very long list of assurances to convince any client/manager/colleague to take this road.
>> I think it'll be another few years before the list can get long enough for your situation. Maybe we'll see you further down the road?
> Booking.com ... was started as Perl5 one, when Perl5 was big in a very different sense that Perl6 is today.
Agreed.
> still fail to find a reason to move to language with no CPAN
I think "no CPAN" doesn't do justice to where things are at.
1. In "IRC::Client: Perl 6 Multi-Server IRC (or Awesome Async Interfaces with Perl 6)" the author shows this code:
Are you not willing to count this sort of use of CPAN's Perl 5 Mojo::UserAgent as part of Perl 6's virtual CPAN as it were?2. Yesterdays blog post about the Perl Toolchain Summit[1] includes this:
> there are people looking to leverage Perl 5 and CPAN in Perl 6, which is why we also invite Perl 6 toolchain developers
I don't think it'll be helpful to get into details in this comment, but from my vantage point the Perl community is not remotely as fractured as some folk seem to think. Perl 5 and Perl 6 are two very distinct and individually great languages that have been moving towards working with each other since the 2012 Perl Reunification Summit. (It's just gonna take time to make sure it's done in such a way that the language combination is worth more than the sum of its parts.)
> no BOOKS
One just came out and two O'Reilly titles are due this year, 'Think Perl 6' due in a couple months and bdfoy's 'Learning Perl 6' driven by his kickstarter campaign which raised $40K. Others are in progress too.
> with a very complex and comprehensive syntax
Well, that's a thing.
While I had a great time with Perl in the 90s, I have long struggled a bit, and sometimes more than a bit, with Perl 5 when going beyond real basics. It seemed to me to have a very complex and comprehensive syntax overall even after I'd begun reaching up to the 3rd and 4th levels of Perl mastery.
Perl 6 seems sooooo simple in comparison!
> and (as many pointed) no big enterprise to back its adoption...
Yes.
One bit of good news is that this hasn't and won't stop t...
Hi! Why so?
and the code quality of modules in CPAN is usually higher.
A lot of the npm growth is just the JavaScript ecosystem catching up to where CPAN was ages ago.
Then there are the npm packages that add functionality that's typically included by default with Perl, so there would never really be a need for equivalent CPAN modules.
I think there is much less duplication within CPAN, while it's not unusual to find several similar npm packages that more or less do the same thing.
CPAN modules also tend to be larger and include more functionality, while it's not unusual for npm packages to include just a single function, or otherwise limited functionality. Sometimes several npm packages are needed to approximate the functionality of individual CPAN modules.
That module count graph should perhaps even be treated as worrying. Npm is clearly an outlier compared to every other package management system listed. There's not much suggesting it's inherently better than all of the other systems, either. So it's likely more negative factors, such as an excessive need for functionality, and many duplicate packages, and unreasonably small packages, and so on causing such inflated numbers.
OTOH while I'm mostly a perl hacker, there's a metric fucktonne of duplication on CPAN too, so I'm not sure that comment necessarily applies (there may be more duplication on npm, but I don't have data for that).
I'm still interested in it, but it just doesn't work for me as an ecosystem yet.
I've used Perl 6 for IRC bots. The ease of writing parallel code, nice OO model, multi dispatch, and subsets make it very pleasant to do them in Perl 6. Here's a bot I wrote that listens for GitHub webhooks and reports new commits and PRs: https://github.com/perl6/geth and here's another one that's just a bunch of random features: https://github.com/zoffixznet/perl6-buggable/
I also heard people say grammars are the most note-worthy feature of Perl 6 and people basically use them to quickly hack up a nice little micro-language in which they then attack their problem. Before I came to Perl 6 I was dumb as shoe when it came to writing parsers, but I find it trivial to do with Perl 6 grammars.
Do I like it? Although I'm obviously biased, I love the language. It lets you write beautifully concise, yet still readable, code. It even lets you use much more readable syntax for regexes. Somewhat regretfully, it made it very difficult for me to learn other languages, as in them I end up writing 3x, 4x, 6x the amount of code and I keep getting reminded of Larry Wall saying Perl 6 would be the last language you'd learn. In Perl 6 I can "talk"; in other languages, I write "code".
However, while the language is fantastic, the implementation still has a lot of work to be done to polish it off. It's basically a 1.0 release. Unlike Go, Rust, or Swift, there isn't a giant corporation behind Perl 6 that can just throw money at problems until they disappear. Compared to other languages, some things are still unoptimized and are much slower. I spotted some leakage that makes it problematic for very-long-running (months) programs. About 65 new bug tickets are opened per month. The test suite is pretty sparse in some areas (which is the likely reason for many of the new bug tickets). But... three new core developers joined this January, so hopefully all that will get improved pretty fast.
Someone in the comments also mentioned the baby-sized ecosystem... Since Perl 6 lets you use C libraries without needing to compile anything, people wrote stuff like Inline::Perl5 and Inline::Python that let you import and even subclass stuff from Perl 5 and Python. And that's a bit of a double-edge sword: yes, it's trivial to use libraries from Perl 5 and Python, but it also stunts the ecosystem; no one has enough motivation to re-invent the wheel in Perl 6 when the wheels from other languages are reasonably usable.
"Group of named regexes that form a formal grammar"
Are Perl 6 "regexes" as powerful as a context-free grammar? I guess they use the same kind of backtracking algorithm and ad hoc recursion as Perl 5? That is, does the algorithm for regexes differ from Perl 5, or only the syntax?
I think the syntax is a big improvement BTW.
So it's basically a mix of paradigms, which muddies the waters in terms of what computational complexity guarantees you can get. Pure regular expressions can be matched in linear time; CFGs in cubic time and some subsets in linear time; packrat parsing in linear time, and backtracking PEG in exponential time. Perl 5 regexes are exponential time in general.
I've used regexes extensively on big data so I don't like this mix of paradigms. I'd rather have separate dialects for each paradigm than having to guess what it's using underneath.
Backtracking causes real problems in production: https://news.ycombinator.com/item?id=12132045
I would bet money that Perl 6 uses backtracking, because it has a mix of paradigms that makes it harder to do anything smarter.
Backtracking is also bad for adversarial input, which is essentially always a concern nowadays.
Please do have a play some time and assuming that I got the above right, donate however much money you would've been willing to bet to the Perl Foundation or the Enlightened Perl Organisation as you prefer :)
I'm not saying nobody wants Perl to work like that... but I am saying I wouldn't use such a tool. It's not right for the problems I need to solve.
I also think it's good if programming languages use algorithms with well-known behavior, rather than a mish-mash of heuristics. Heuristics are OK if there is nothing better known, but these problems have been studied.
Basically: Perl 6 tokens and rules imply :ratchet, which means no backtracking. You can use raw regexes if for some reason you do need backtracking, but otherwise it looks like a Perl 6 grammar is backtracking-free (and grammars in the real world hopefully use tokens/rules exclusively).
So it might actually be at least tolerable for the problems you need to solve (though it's hard for me to say without knowing the problems in the first place (: ). The main remaining question is the exact algorithm in use; I'd be very surprised if Perl 6 grammars didn't compile down to at least some variation on packrat parsers, which would mean linear complexity, but this is probably - again - implementation-dependent in the "we don't care what you do so long as it passes the Perl 6 test suite" sense. I've yet to find a definitive answer by spelunking through Rakudo's code, but it's reassuring that even Rakudo's grammar for Perl 6 itself seems to be devoid of backtracking (meaning that it's clearly possible to do without it; there are quite a few generic subs/methods in there, though, which could prove me wrong here).
With tokens another nice thing to note is there is longest token matching and the concept of "proto" tokens and regexes. This lets you have simple decision making between similarly defined tokens without backtracking. For example the grammar I have for biological sequences can simultaneously identify and parse DNA/RNA/Protein without back tracking. Even if a file has a mixture of data I can instantiate the correct subclasses on the fly whilst parsing! https://github.com/MattOates/BioInfo/blob/master/lib/BioInfo...
And yeah, proto regexes are pretty sweet, and they seem to be a natural fit for what you're doing. I'm always surprised by how popular Perl seems to be in biology / life sciences, and projects like BioInfo (and BioPerl, of course) are a great reminder as to why that happens to be.
In Perl 6 regexes are seen as a type of method (that is they are literally implemented as a type of method in Rakudo)
Grammars tend to look like a cross between BNF, and well Perl. https://stackoverflow.com/a/41770672/1337
Perl 6 regexes have longest term matching using |, or sequential matching like Perl 5 using ||.
Since regexes are methods, they can take arguments as well.
TL;DR If you can code it, you can code it using Perl 6 grammars.
Perl 6 is designed as a collection of "slangs" (short for sub-languages) that recursively embed each other. (There are about a half dozen slangs in standard Perl 6 but you can add more.)
So the full power of the "main" Perl 6 slang is available within the regex slang (and vice-versa). During execution each slang automatically tracks the interesting state of the other slangs.
So, while the compiler is free to analyze a given rule and generate a suitably optimized DFA or NFA, they are, in general, capable of turing complete power.
> I guess they use the same kind of backtracking algorithm
The main answer is No.
There are four types of "rule". Only one of these, using the `regex` declarator, backtracks in the usual regex way.
Most extant grammars contain nothing but `rule`s, `token`s, and occasionally `method`s.
The fact that the latter are just ordinary methods hints at what's going on; the "regex slang" is really just a built in recursive ascent/descent parser generator with a convenient DSL (slang) for writing grammars.
What is Perl6 now?
It's a very basic (primitive ?) CGI/perl design made performant with mod-perl, etc.
I started my career building shopping carts based on what I learned from _The CGI Book_ (and the web forum that sprung from it) ... 23 years later we're building a modern startup based on the same workflow.
[1] https://0x.co
[2] https://0x.co/hnfaq.html
Another thing - you may start a brand new code with Perl6, it is always a green field in automation / ops tasks.
Do I use a Perl6 in production? Yes I do. Recently I have updated ~ 500 servers with the help of Sparrowdo - http://sparrowdo.wordpress.com/ - a configuration management tool written on Perl6.
So for sure - Perl5 folks please look at Perl6. Other people as well :) It's neat, modern language.
Regards
Alexey
Python does a few things much better than perl 5. The obvious ones are the REPL and support for C bindings. However, I still find it miserable to work with.
Hopefully, perl 6 learned from python's mistakes (as well as from perl 5's mistakes).
I honestly have no idea why Python got so popular in that space. Those Python guys are always amazed when I show them a much more elegant Perl solution to their problem.
That said, frankly your comment is a bit off-topic and irrelevant--and you may get downvoted for that--because the question was not "Why use Perl 6 or not" but literally "What you do with it".
Also, Perl 6 makes it easy to write short and concise code that will also be very readable.
The project I wrote is a command line tool[1] for fetching football(soccer) data, which uses a module[2] I wrote for getting the data from http://football-data.org
[1] https://gitlab.com/CIAvash/App-Football
[2] https://gitlab.com/CIAvash/WebService-FootballData