
Ask HN: Perl 6: Do you use it, how do you like it, what do you do with it? - gkya
I&#x27;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&#x27;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&#x27;d be glad it people shared links to published projects and actual code out in the internet).  Thanks in advance!
======
melezhik
Hi there! I used Perl5 for about 10 years. Web programming, sys admin tools,
parses, so on. It's true (IMHO) that Perl5 tends to be a language "with hard
to find job". So, recently I tried something new. I had some experience with
Ruby/chef but I wanted something I feel more familiar in my background and I
noticed a Perl6 a halve year ago, it was just around a time when first stable
release appeared ( maybe 1-2 years before, but anyway ... ). Well what I can
say? Perl6 is certainly proper choice for former Perl5 developers ( not only
for them, but I am looking from my perspective ). Yeah there is lack of
modules in comparison with CPAN but I don't treat this a big issue, all great
projects started in the past with little eco system, so I guess it is only a
question of nearest 5 years. Take a look at
[http://modules.perl6.org/](http://modules.perl6.org/) \- new modules get
added weekly!

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/](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

------
larodi
Substantial amount of Perl6 goodness is already baked one way or another in
ES6/7, Python 3.x, Scala and even the modern C# and C++14/17\. Speaking of
stuff like concurrency, C3 resolution, object proxies (a.k.a AUTOLOAD),
introspection/reflection, promises, reasonable regex engine, etc.

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...

~~~
tootie
I chuckled the first time I saw 'use strict'; at the top of the javascript
file. Node.js seems to be morphing more and more into Perl 5 with every new
release.

~~~
larodi
I still chuckle, and try to remind everyone in the room that:

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.

~~~
gkya
Whenever Node comes up somewhere, I wonder what happened to the original
author of it, he was called Ryan, IIRC.

~~~
tyingq
Ryan Dahl.

 _" 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](https://www.quora.com/What-happened-to-Ryan-Dahl)

------
ajb
I followed the development of perl 6 for a bit. I was quite impressed for a
while, as Larry Wall disolved most of the warts, corner cases, and ad-hocisms
of perl 5 into a language which was cleaner and more abstract. Then he used
the cognitive space thus provided to load up the langauge with as many
features as he could pack in, and I gave up on it.

~~~
logicallee
>I followed the development of perl 6 for a bit.

To put it mildly.

~~~
b3h3moth
:-)

"In the 20th century I followed the development of perl 6"

~~~
labster
The mug hit the wall on 2000-07-18, which means there was less than 5 months
of Perl 6 history in the 20th century. Apocalypse 1 didn't even come out until
2001.

------
avar
I write Perl 5 for a living, we have Perl 6 installed here and I occasionally
use it for one-liners[1] that are much less verbose than Perl 5 or most other
languages. But nothing else.

1\. [https://github.com/dnmfarrell/Perl6-One-
Liners](https://github.com/dnmfarrell/Perl6-One-Liners)

~~~
jkeks
Cool Perl6 oneliners .. I like it. Put it more

------
zoffix222
Biased core dev here...

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](https://github.com/perl6/geth) and
here's another one that's just a bunch of random features:
[https://github.com/zoffixznet/perl6-buggable/](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.

~~~
chubot
Do you know what algorithm grammars use under the hood? I don't see it
mentioned in documentation like this:
[https://docs.perl6.org/language/grammars](https://docs.perl6.org/language/grammars)

"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.

~~~
yellowapple
IIRC, Perl 6 grammars are parsing expression grammars (PEGs). I don't know if
these are compiled down to recursive descent or packrat parsers; my guess
would be the latter (since that's typical for PEGs).

~~~
chubot
The sibling post says that they have both || and |. The || operator sounds
like ordered choice from PEGs, and | sounds like a non-deterministic choice
from regexes and CFGs.

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](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.

~~~
yellowapple
Aside from perhaps protecting against adversarial input, the general
philosophy of Perl has always been for programmers to not need to worry
themselves about underlying implementation details. The exact algorithms (and
with that the exact computational complexity bounds) might very well be
implementation dependent.

~~~
chubot
Right, but the point is that you don't need to worry until you do. See the
post I linked.

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.

~~~
yellowapple
So I actually found an answer to your question re: backtracking:
[https://docs.perl6.org/language/faq#What%27s_the_difference_...](https://docs.perl6.org/language/faq#What%27s_the_difference_between_token_and_rule_)?

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).

~~~
Ultimatt
Unfortunately the regex/grammar engine is one of those components lacking deep
optimisation. At the moment. Thats probably a much bigger factor than anything
algorithmic.

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...](https://github.com/MattOates/BioInfo/blob/master/lib/BioInfo/Parser/FASTA/Grammar.pm6)

~~~
yellowapple
I reckon the optimizations will come soon (at least that's what I gathered
from reading the Perl 6 documentation's "Performance" section); now that Perl
6.c is out in the wild, there's less of a moving target, so the
implementations can (and apparently are) starting to focus more on squeezing
out more performance.

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.

------
joelberger
Perl 6 looks very promising. It was an attempt to brush up Perl 5 but became
its own language with a very unfortunate name (read: Perl 6 will not replace
Perl 5). It has some very interesting features, including the built-in
concurrency primitives and the oft-mentioned grammars.

It is still very new (from a release time perspective). I don't expect there
are very many large-scale real-world usages yet. I do wish that the Perl 6
community would spend a little more time on advocacy but thankfully there are
several books on the way and hopefully that will start breaking out of the
echo chamber and introducing the language to the masses.

------
brudgers
I considered Perl 6 for a deep dive at the end of 2015...just as it was
'officially released'. The difficulty _for me_ was the state of the
documentation ecosystem. No dead-tree books (but for one that was written more
than a decade earlier) and a lot of information _ad hocked_ up in blogs and
slides. I just felt like I could not really get a handle on it...While
googling 'Perl 6' sort of worked, 'Perl 6 how do I <x>' type queries pretty
much ignored the "6" and landed me on Perl 5 resources. Perl 6 still only has
~300 StackOverflow questions.

I'm still interested in it, but it just doesn't work _for me_ as an ecosystem
yet.

~~~
zoffix222
FWIW, a huge amount of work has been done to docs in the past year. There's
even a dead-tree book available now ([https://deeptext.media/perl6-at-a-
glance/](https://deeptext.media/perl6-at-a-glance/) ), with 3 more slated to
release later this year.

~~~
brudgers
I knew there was work in progress because I've made a similar comment in the
past few months. I'm not in hurry which is perhaps in good alignment with Perl
6...A quick look at the book sample suggests it's not probably what _I 'd_
look for before starting a deep dive.

------
markstos
I worked on Perl 5 projects professionally for about 15 years, then switched
to a new job that uses Node.js. I enjoyed coding in Perl 5, but it was hard to
find and retain Perl 5 developers. Our later hires preferred to code in C#,
Python and Ruby-- This was before Node.js took off. Looking at language
trajectories on [http://modulecounts.com/](http://modulecounts.com/) The
momentum that JavaScript has compared to Perl is amazing-- CPAN growth is
relatively flat, JavaScript growth is skyrocketing. JavaScript has it's own
warts, but for web projects with smaller teams, having the frontend and
backend in the same language is big benefit. As much as I enjoyed the Perl
language and community, I can't foresee recommending it for team web projects
in the near future.

~~~
epoch1970
We should be careful when comparing the growth or package counts of CPAN and
npm. While conceptually similar, they're still very different from one
another.

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.

~~~
mst
Plus there's the fashion of uploading one npm dist per function, as well as a
bundled dist, for projects not using tree shaking to keep their browser bundle
small.

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).

------
CIAvash
I like many things about Perl 6, but I mention only the ones I used in my
project. MAIN subroutine makes it very easy to create simple CLIs, multiple
dispatch, gradual typing, subsets, the object system, roles, Unicode support,
being multi-paradigm.

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](http://football-data.org)

[1] [https://gitlab.com/CIAvash/App-Football](https://gitlab.com/CIAvash/App-
Football)

[2] [https://gitlab.com/CIAvash/WebService-
FootballData](https://gitlab.com/CIAvash/WebService-FootballData)

------
amyjess
Everything I've seen about Perl 6, I love to death.

I just wish I had an excuse to use it. The problem is, most of the time I
start a new project, I default to Python because it's what I know. I know the
libraries, I know the quirks of the built-in data structures, etc. So I just
go with what I know.

I really wish I had the discipline to sit down and tell myself "I'm going to
write this next project in Perl 6 no matter how much time it takes to figure
out how to do what I want to do".

Like, I actually just started a personal project to parse some US Census data
a few days ago. I could have, and probably _should_ have, taken the
opportunity to write it in Perl 6. But I got lazy and just went with what I
knew. I feel really bad about that, since from what I've seen, it sounds like
a language I'll love working with just as much as Python.

~~~
gkya
This is how I feel about Common Lisp actually (I've a sweet spot for Lisp). I
have switched from programming to humanities so I don't really have much
programming to do, and all the little tools and stuff I need I code them up in
Emacs Lisp, and because of that I actually have no use for CL ATM, and even
though I want to write some CL so bad, I write all the stuff in Elisp, I just
do that.. :)

------
mempko
I wrote PKafka
([https://github.com/mempko/PKafka](https://github.com/mempko/PKafka)) a year
ago, a Perl 6 wrapper around the rdkafka library. I just started using it in a
production system a week ago.

I feel that Perl 6 is an amazing language. The regex and grammars are
fantastic for doing any sort of parsing. The built in support for reactive
programming and gradual typing with the given/when syntax is fantastic. The
type constraint and multi dispatch mechanism is also great.

However, only until the latest release 2017-01, did I feel the MoarVM is
stable enough for production use.

------
woodruffw
I've been using it locally to write a few small scripts, nothing publicly
available (yet).

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/tadzik/panda)

~~~
b2gills
It sounds to me like you would like a "batteries included" version of Perl 6.
(include JSON/YAML in the runtime)

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.

~~~
woodruffw
First of all, thanks for responding. I understand the hesitation of language
maintainers with respect to adding complex modules like JSON and YAML, but I
_do_ think that there are some major benefits to doing so:

* 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).

------
hpcjoe
I am late to the party here, but I've recently rolled perl6 into my analytics
stack project: nlytiq ( [https://github.com/joelandman/nyltiq-
base](https://github.com/joelandman/nyltiq-base) ). Very early stages, I am
trying to build an up-to-date tool chain of very powerful tools for data
munging, analytics, etc. for my own projects. Born of a frustration with the
badly out of date tools in most distros.

I pulled Perl6 in after seeing some of what it was capable of last year.
Generally I like tools that make hard things easier, and easy things trivial.
I don't like tools that require huge amounts of boilerplate code to even start
using them productively.

Perl6 is definitely in the category of making hard things easier. It is not
Perl5, and doesn't pretend to be. Perl5 is immensely powerful on its own,
definitely one of my go-to tools.

Perl6 brings in many of the things that I've been using in other languages for
a while, with some aspect of "perl-ness" about it, which, to me, makes it more
comfortable. Its ability to connect with/call anything positively blows me
away. Perl5 has Platypus::FFI which can do some of this, but Perl6 is a
compiled language (to an underlying VM). This has been one of my major
concerns with P5 for a while (and still a concern in Python and others ...
yeah, I know of PyPy, but I want a compiler built into Python 3.x).

------
throwaway2016a
So this doesn't help with your question but I'm sure i'm not alone on this
one...

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).

~~~
throwaway7645
I once heard the apocalypse arrives when GNUHurd is released with perl6 & duke
nukem forever running on it.

------
donaldihunter
Perl 6 is my go-to language for writing command line utilities. The
combination of MAIN subroutines, named regexes and full-blown grammars makes
it simple to write documented, maintainable programs that can parse just about
anything. Oh and Unicode support is awesome. This protobuf grammar is a good
example of what Perl 6 grammars are like -
[https://github.com/donaldh/p6-pb/blob/master/lib/PB/Grammar....](https://github.com/donaldh/p6-pb/blob/master/lib/PB/Grammar.pm)
\- and worth comparing to the official protobuf language specification -
[https://developers.google.com/protocol-
buffers/docs/referenc...](https://developers.google.com/protocol-
buffers/docs/reference/proto3-spec)

~~~
donaldihunter
Low-level stuff on a Raspberry Pi, including native C library calls for mmap,
munmap. Binding the mmap library call into Perl 6 is as simple as:

sub mmap(Pointer $addr, int32 $length, int32 $prot, int32 $flags, int32 $fd,
int32 $offset) returns CArray[int32] is native {*}

[https://github.com/donaldh/Perl6-RPi-
GpioDirect/blob/master/...](https://github.com/donaldh/Perl6-RPi-
GpioDirect/blob/master/lib/RPi/GpioDirect.pm)

------
xaduha
For a long time I thought that Perl 6 would be close to an ideal language for
me. I haven't really questioned that belief, but it turns out [http://www.red-
lang.org](http://www.red-lang.org) is much closer.

Let's say that I'm glad that Perl 6 is there as an option.

~~~
throwaway7645
Gosh yes I'm excited for Red Lang too.

------
fennecfoxen
As a perl5 programmer of 5 years, I've branched out. In terms of
_professionally_ this means mostly into Ruby but a little bit Java and the
occasional JavaScript.

Perl5 is a fine language that is over-attacked, and neat stuff is still done
in it. Ruby as a language is better (but more subject to hype and so more
often overrated)... and I'm confident that Perl6 is full of neat stuff. I wish
it the best. And I will take any of these languages over Java for most
problems I've faced.

But if you stick with too much Perl for too long you run a serious risk of
being typecast as a "Perl guy" familiar only with dated languages, fairly or
otherwise, and can expect a hard time finding the sort of jobs you want in the
future, which is a pity. (Which isn't to say you won't find jobs, just that
the pool of jobs will lean towards "maintain legacy code with no chance to
refactor make your time" and "build engineer".) This is why I branched out in
the first place.

My next target is Elixir (and then by extension, Erlang), narrowly winning out
over Scala, with Go/Rust/OCaml trailing behind a little. I reckon Scala is
probably more practical, and surprisingly popular in Europe, but I like
working with a "reliability" mindset more than not and therefore forecast that
I'll like the tools and opportunities in Elixir better. I've barely started
but my initial reaction to what I've seen is quite positive.

\- But at some level, all that's just me, and you shouldn't take lessons from
my experience nearly so much as it should prompt you to think about your own
experience and what you want out of programming as a hobby or as your career.

------
omouse
I wrote up a tutorial on Perl 6 and tried to get it more widely known there
are a lot of neat features in it and it looks far better designed than most
languages:

[https://www.codementor.io/perl/tutorial/how-to-use-json-
in-p...](https://www.codementor.io/perl/tutorial/how-to-use-json-in-perl-6)

However, most people have dismissed it because they think Perl 5 is dead and
anything using Perl should be replaced with Python or Ruby or Go or Rust or
some other language.

The hacker flavour of the language has been preserved and that's the niche it
would fill for me...if I didn't have to basically do frontend web all day.

~~~
branchly2
> However, most people have dismissed it because they think Perl 5 is dead and
> anything using Perl should be replaced with Python or Ruby or Go or Rust or
> some other language.

I didn't dismiss it for that reason. I wanted to like Perl 6, but dismissed it
because last time I tried learning it:

* it seemed to include too much syntax

* too much lingo required to understand core concepts

* no coherently-written definitive tutorial. No Camel book for that matte.

* most examples seem to be written with maximum quirky-ness to show off the acrobatics you can do. I just want to get work done.

~~~
qbaqbaqba
[http://perl6intro.com/](http://perl6intro.com/) is quite nice.

~~~
throwaway7645
Yes, but as the author mentioned it is a far cry from a camel book. I've been
told Larry is working on it, but I bet I can't buy it for at least two years
if not three. We do have 3-4 other books coming out in the future, but I want
a 600 page monster to make me truly understand it in and out.

------
onli
I used perl6 to write a mini-webservice, an API-wrapper for a weather forecast
API my bash script is speaking to – I of course don't want users to have to
generate API keys, hence the wrapper. Programming that was straightforward,
the language itself nice and powerful. But of course I did not really need a
powerful language for that task.

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.

------
bashcoder
To a large degree, the ongoing utility of Perl 6 depends upon the continued
vibrancy of the CPAN community. IMHO, CPAN is anything but vibrant by today's
standards.

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/](http://www.modulecounts.com/) [2]
[https://modules.perl6.org/](https://modules.perl6.org/)

~~~
marvy
I'm no Perl user, but surely 800 is pretty good for a one year old language?
How many did Perl 5 have when it was one year old? (That's a trick question:
CPAN was officially launched about year after Perl 5 came out; see here
[http://history.perl.org/PerlTimeline.html](http://history.perl.org/PerlTimeline.html))

~~~
bashcoder
Fair point, but it's also fair to note that Perl 6 development began 17 years
ago.

~~~
gkya
Well you don't develop modules for a language yet to be released.

------
hyperpape
I'm the rare person who never used Perl 5 but is trying to learn Perl 6. I
haven't progressed beyond very simple scripts, but it's interesting. I
especially am interested in the grammars, so I'll try to find a task where I'd
get to explore them.

I have no plans to try and ship software written in it.

~~~
throwaway7645
I'm in a similar boat. Many of the features make for great analysis language.

~~~
chubot
What do you mean by analysis? Text analysis? I'm curious what features drew
you toward it.

Personally I think the optional typing looks interesting.

~~~
throwaway7645
Gradual typing, grammars for parsing, writing your own operators for common
tasks, FP style for one-liners...there are more, but I'll have to add later
when not drawing a blank.

------
ams6110
I honestly haven't heard of anyone using Perl for anything new. Sure there is
a lot of legacy Perl 5 being used and maintained, but Perl 6? For a new
project? I've never even seen it on a short list.

~~~
joosters
I use perl for new code all the time. It's not a trendy language, so it won't
get much coverage on HN, but the language and libraries are great IMO.

Also, 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.

~~~
marvy
As someone who knows neither version, I find this surprising. Surely, even if
none of your code works, switching from Perl 5 to Perl 6 is much less of a
"culture shock" than switching to, say, Ruby or Python?

~~~
v64
As someone who still occasionally has to write Perl 5 for a living, Perl 6
really is a new language. And because Perl 6 isn't as mainstream as Ruby or
Python, there is a bigger culture shock when trying to find resources or
figure out the "right way" to do things (I know, I know, There Is More Than
One Day To Do It). There are big changes to the syntax too that make it feel
like less of a successor and more of a new language inspired by an old one.

~~~
marvy
Wow, that big a change? Then maybe they should have changed the name after
all. Purl?

------
mnglkhn2
Perl6 looks like a great language. What Perl6 needs is a clear branding
message which in most cases has to do to a clear use-case scenario. People
need to know why do they need Perl6. In late 1990s and early 2000s Perl was
CGI, which was dynamic pages on the internet.

What is Perl6 now?

~~~
yellowapple
For me, Perl 6's "killer feature" is the same as Perl 5's: the ability to
parse arbitrary textual data with relative ease. Perl 5's regex syntax ended
up becoming probably the most common thereof (mostly by way of PCRE); I
suspect Perl 6's "grammars" could do the same and serve as "the" syntax for
PEGs.

------
rsync
All of Oh By[1][2] is built on perl.

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](https://0x.co)

[2] [https://0x.co/hnfaq.html](https://0x.co/hnfaq.html)

------
MarkSenn
I've used Perl as my primary programming language over 20 years and think that
Perl 6 is a big improvement. I've been using 6 for new Perl software since
2012 (one 500 line program I run once a week and a few other 30 lines or less
programs used one time) with good results---learning Perl 6 was hard for me---
am looking forward to Perl 6 books. Thanks to all the people that made Perl 5
and 6 possible.

------
alekratz
follow-up: for a non-Perl person, who is incredibly interested in getting
started with Perl 6, are there any good resources (code examples, blog posts
exploring language concepts unique to Perl 6) that anyone would recommend?

~~~
perlgeek
I'm writing a book about Perl 6 right now, targeted at folks who already know
some programming language(s), but not necessarily Perl 5:
[https://leanpub.com/perl6](https://leanpub.com/perl6)

There are 9 chapters out there already, which you get you started nicely.
Feedback would be very welcome!

~~~
alekratz
Thanks, I'll give it a look and probably give you feedback... a long time from
now. I get to things slowly, but I do get to them :)

------
perlgeek
So far I've used it for several small tools, including some that refactored
code for other, larger projects. Grammars really make that pleasant.

~~~
chubot
Are any of those open source? I'd like to see grammars used in "real" code,
not just examples.

~~~
colomon
Real grammar [1], regularly used by me, at least. It may not be the best way
of doing things today, it was written three or four Perl 6 compilers ago. But
it works on the latest Rakudo release.

[1]
[https://github.com/colomon/ABC/blob/master/lib/ABC/Grammar.p...](https://github.com/colomon/ABC/blob/master/lib/ABC/Grammar.pm)

Edited to add: I think originally based it on
[https://web.archive.org/web/20120201072612/http://www.norbec...](https://web.archive.org/web/20120201072612/http://www.norbeck.nu/abc/bnf/abc20bnf.htm)

------
gtycomb
use perl5 instead because it is already there on unix systems. Use it to
collect infrastructure data, scrape logs, query databases, or even for some
statistics/math on the fly. If on an island I will take perl5 (and golang :-)
I had hopes for perl6 but it got cumbersome in practice ...

------
Thaxll
I'll be downvoted for that but isn't Perl been replaced by Python in the last
7-8 years? I've never seen Perl used in the companies I've worked for in the
past 6 years.

~~~
hedora
I think python adoption is kinda an overreaction to perl 5's warts: for
example, too much punctuation switches to too little.

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).

------
colomon
I've been a Perl user since 1994 or so, using it for an endless variety of
small scripts to aid my $work and computer use in general. Since 2010 or so
the vast majority of new scripts I've written have been in Perl 6, and I've
ported a few of the older ones rather than try to make extensive modifications
in my old Perl 6 code.

My biggest Perl 6 project (much bigger than anything I ever tried in Perl 4/5)
is the ABC module [1]. This provides a grammar for parsing ABC music notation
[2], a set of classes for representing ABC data, and some scripts built using
it. The one I use the most is abc2ly, which translates ABC files to Lilypond
format [3] for producing beautiful sheet music [4].

The other tool of mine I use routinely is TagTools [5]. There's nothing really
fancy there, just a bunch of simple scripts which use Perl 6's
Audio::Taglib::Simple module to work with the tags on MP3 files. But they were
easy to write, come in handy for working with MP3s, and are easy to modify for
odd cases.

Recently I've done a couple of scripts which rely on Inline::Python. The
latest is wunderlist.pl, which I have installed in cron to update my
Wunderlist to-do list every day. There is (to the best of my knowledge) no
Perl6 module for working with the Wunderlist API, but there is a Python
module, wunderpy2. There is a bit of boilerplate glue code there (lines 16-21
of the script) but once that's done using the Python module is almost
indistinguishable from working with normal Perl 6. (Of course, if you're
fluent in Python this maybe isn't such a big deal for you, but I don't know
more than a tiny bit of Python, and Inline::Python lets me effectively use
Python modules from the comfortable-to-me world of Perl 6.)

[1] [https://github.com/colomon/ABC](https://github.com/colomon/ABC) (Note
that as I write this, the README is about 4 years out of date.]

[2] [http://abcnotation.com/](http://abcnotation.com/)

[3] [http://lilypond.org/](http://lilypond.org/)

[4] For instance,
[http://www.harmonyware.com/tunes/They_Sailed_From_Belfast.ht...](http://www.harmonyware.com/tunes/They_Sailed_From_Belfast.html)

[5] [https://github.com/colomon/TagTools](https://github.com/colomon/TagTools)

[6]
[https://gist.github.com/colomon/89a6e7b8bf7694aa42e83058bb43...](https://gist.github.com/colomon/89a6e7b8bf7694aa42e83058bb43f489)

------
wyclif
I think DuckDuckGo uses Perl 6 in production. Some of those devs have accounts
here, so maybe they'll speak up.

------
vgy7ujm
Was very interested some years ago but lately I think many of the things I
don't like with for example C# has snuck into the syntax.

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.

~~~
b2gills
I can't think of a single capitalized keyword.

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 )

    
    
        my $sum = [+] 1..100000000000000000000000;
    

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.

~~~
vgy7ujm
Perhaps worth another look again. I remember 'Int', '.WHAT', etc. from some
presentations and that stung in my eyes a bit.

~~~
raiph
Perl 6 makes careful use of letter case to convey useful information.

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.

~~~
vgy7ujm
I hope these things are explained well in the upcoming books. Me, a seasoned
Perl 5 programmer that doesn't participate much in the Perl 6 community find
these things a bit strange and visually a turnoff if you get what I mean. Also
angle brackets usage no auto quoting was something I remember not liking too
much.

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.

------
tmaly
I have been programming Perl 5 for many years in the finance industry. I have
not seen any Perl 6. In the last year I have been using Go in conjunction with
Perl to handle some of the cases where Go solves the problem better.

------
liveoneggs
reading through the docs in perl 6 is really fun and I'm similarly interested
in it. I think, however, that it will take some dedicated usage to get
momentum going so you are stuck in a catch 22. :)

------
throwaway7645
I'm actively following the project, but waiting for it to mature (speed,
doc...etc) before using it.

------
jkeks
I wrote some scripts for my little tasks. Thats cool thing !

------
bebna
Perhaps you should look at this two presentations first:

[https://media.ccc.de/v/31c3_-_6243_-_en_-
_saal_1_-_201412292...](https://media.ccc.de/v/31c3_-_6243_-_en_-
_saal_1_-_201412292200_-_the_perl_jam_exploiting_a_20_year-old_vulnerability_-
_netanel_rubin)

[https://media.ccc.de/v/32c3-7130-the_perl_jam_2](https://media.ccc.de/v/32c3-7130-the_perl_jam_2)

~~~
gpvos
Looks like that's about Perl 5, not 6. (I am not going to watch such long
videos without more info up front.)

~~~
throwaway7645
The problems in that video are P5 centric. P6 is very different as far as how
under the hood works

~~~
nocman
P5 centric, and old P5 centric, and the videos aren't funny. He could have
just said "Perl 5 sucks" and left the stage and the videos would have been of
equivalent value (as in, they aren't worth anything).

