
Why I’m Learning Perl 6 - mpalme
http://www.evanmiller.org/why-im-learning-perl-6.html
======
StevePerkins
> _Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE
> CODE, where application threads aren’t pinned to pthreads) your options
> today are precisely Erlang, Go, .NET, and Perl 6._

Putting aside the "web scale" jokes ([http://www.mongodb-is-web-
scale.com/](http://www.mongodb-is-web-scale.com/)), this statement is still
absurd.

Every major language, or at least the ones that matter for backend
development, has support for thread multiplexing / coroutines / fibers,
whatever. Perhaps not in the core language syntax or standard library. But
it's easy to implement with native code, and so SOMEONE has implemented it in
a library if the language has an FFI.

Java, and all of the other JVM-based languages in turn, have Quasar
([http://docs.paralleluniverse.co/quasar/](http://docs.paralleluniverse.co/quasar/)).

Ruby has support for primitive fibers baked into the standard language
([https://ruby-doc.org/core-2.1.1/Fiber.html](https://ruby-
doc.org/core-2.1.1/Fiber.html)), and likewise community gems with more robust
functionality like Quasar.

Python 3 likewise has this out of the box
([https://www.python.org/dev/peps/pep-0492/](https://www.python.org/dev/peps/pep-0492/)).

The list goes on and on:
[https://en.wikipedia.org/wiki/Coroutine#Programming_language...](https://en.wikipedia.org/wiki/Coroutine#Programming_languages_with_native_support).

~~~
rootlocus
I'd like to know why people are downvoting this.

~~~
supremesaboteur
For Python there is no native support for threads because of GIL. You can get
around this through multiprocessing etc but these are hacks

~~~
askvictor
There is native support for threads, it's just that they don't run
concurrently.

~~~
nothrabannosir
At this point the word is so far removed from the meaning in this thread you
might as well say a haberdasher supports threads.

~~~
askvictor
There are valid reasons for programming with threads with only a single CPU
(indeed when I learnedb thread programming in the 90s pretty much only single
core cpus were available). For instance, IO blocking.

------
Verdex_2
For some reason, when I started my software engineering career I got it into
my head that I needed to learn as much as I could about programming languages.

I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#,
java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't
quite enough because haskell and idris kept on talking about complicated type
theory stuff. So I also learned lambda calculus, type theory, set theory,
domain theory, topology, category theory, information theory, sub-structural
logic.

What I'm trying to say is that I'm not afraid of learning new things. Even if
they seem hard or esoteric.

When I heard that perl6 was ready, I took a look. I like the idea of a lot of
what is present in the language (hey look, a grammar engine, that's neat). But
ultimately, I decided that it was too much stuff that I would have to learn.
Maybe that's just a perception problem on my part, but I have to think that
they have _some_ sort of problem if someone like me feels overwhelmed by all
of the things that you have to grok in order to understand the language.

~~~
daotoad
Perl 6 is designed to be a large, feature rich language that can be learned
and used incrementally. The intent is that, like users of natural languages,
Perl 6 practitioners gain fluency and nuance in their expression over time.

So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6.
Write something that works and solves your problem. Later on you may learn
that there are multiple other ways to express the same ideas you wrote
already. Maybe one of them better expresses the heart of your algorithm, then
you update your code.

Now, you may think, how the heck am I going to maintain code written by a
bunch of people at different phases of learning Perl6?

The Perl community has responded to this challenge by putting a huge amount of
work into writing excellent documentation. Perl6 docs are readily searchable
and carefully indexed. It's a big, new language with lots to write about, so
the docs are not yet complete, but they are already fantastic and keep getting
better.

So, please, just pick a problem to solve and jump on in. The water's fine.

~~~
oblio
While I encourage OP to dive in and don't want to dismiss your points, in my
experience life is more about perpetual intermediates:
[https://blog.codinghorror.com/defending-perpetual-
intermedia...](https://blog.codinghorror.com/defending-perpetual-
intermediacy/)

As a result, a language like Perl is very nice and maybe even artistic but in
many situations downright "dangerous".

~~~
daotoad
Perpetual intermediates exist in every field, many of them with far more
nuance than any mere programming language has to offer. The way to extract
productivity from these people is the same in software development as it is in
any endeavor: leadership.

Good leaders identify and propagate conventions that can keep their teams
functioning in a complex millieu.

You can't get rid of the irreducible complexity of any system. You can only
move it around.

In my experience, if you use an expressive language well, you can fit the code
to the problem domain in a way that better communicates the underlying
approach you have taken to solving the problem.

Relying on strict, small languages, like Java, means that you gain a
consistency of syntax by sacrificing flexibility.

I've seen monstrous turds written in many languages, the problem in all these
cases was poor or absent leadership.

------
Steeeve
I hate perl6. I hate it because I tried to get involved in the project early
on, and it led me down the Haskell rathole. I don't know what Haskell looks
like today, but a decade or more ago it was the hardest language to pick up
that I had ever experienced. It was as if I had a solid background in latin
languages and I was trying to pick up Chinese based on a handful of tutorials
written by a tourist on the back of a napkin.

But it has been a decade and I am truly impressed with what it has turned
into. Unfortunately, it has to re-gain mindshare as if it was starting from
scratch. It might be a little bit harder actually, because there are a variety
of scripting languages these days that are easy to learn, and there are still
more than a few people who actively don't like Perl.

I really liked this slideshow:
[http://tpm2016.zoffix.com/#/](http://tpm2016.zoffix.com/#/)

It gives a good review of Perl6 from early 2016. The video is an hour and a
half, but it only takes a few minutes to scan through the slides and find the
interesting pieces. (left and right arrow to navigate the slides)

~~~
txdv
I looked quickly through the slides and saw that perl has now grammar build in
the language...

Truly an interesting feature

~~~
dmytrish
Is the language itself a good place for parsing/grammar handling?

I could not even find in the standard documentation which kind of parsers it
supports, is it LR(k)? LL(k)? Any CFG? What parsing method does it use:
recursive descent, shift-reduce, something more general like CYK/Earley
algorithms? How does it handle ambiguities?

It turns out that `grammar` keyword generates recursive descent parsers and
anything even a bit fancier still requires a dedicated parsing library.

~~~
riffraff
perl6 grammars have to be seen in context of perl5 regexp.

Basically, regular expressions have grown to impossible to understand, write
and modify. Mostly due to perl.

Yet, they are used daily by millions of developers, because they are a ton
better than manual character checks.

Perl6 grammars are basically an attempt to bring developers another step
forward.

~~~
vram22
Are you saying that Perl6 grammars are a replacement (maybe eventually) for
Perl5 regexps?

~~~
riffraff
partly, you still build Grammars out of "token", "regex" and "rule"
definitions, but some things are more natural with one or the other.

So, if you are doing "test if string has whitespace" you'd use a regex, while
for "parse an apache log line" you'd probably use a grammar instead of a very
nasty regex.

IANA perl6 dev though, just a casual observer.

~~~
kbenson
> while for "parse an apache log line" you'd probably use a grammar instead of
> a very nasty regex.

That's actually a fairly easy endeavor with perl regex capabilities,
especially named captures. Parsing HTML, or a programming language, or other
much more complex structures is much easier with a grammar. For example, JSON
parsing[1].

That said, there are ways to approximate _some_ features of grammars with
Perl5 regexes[2].

1:
[https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...](https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Grammar.pm)

2: [http://blogs.perl.org/users/brian_d_foy/2013/10/parsing-
json...](http://blogs.perl.org/users/brian_d_foy/2013/10/parsing-json-with-a-
single-regex.html)

------
ricardobeat
Crystal ([http://crystal-lang.org](http://crystal-lang.org)) has fibers and
channels. Current implementation isn't multi-threaded but it's being worked
on. So you'll get that concurrency + nice syntax + types + a wonderful stdlib.

EDIT: as seen in other responses, options abound: Python 3, Elixir, D, Dart
and more all have built-in concurrency primitives, not to mention that
discarding nodejs because of "callback hell" is at this point laughable.

~~~
holydude
I am really,really excited about Crystal. I wish it success but I am afraid if
the rails shops and big companies do not start using it it will be too little
too late.

~~~
goatlover
That would be unfortunate. I really like Crystal as a fast, typed alternative
to Ruby, but I also prefer Ruby as a language to Go or even Elixir, which not
everyone does.

------
IceDane
> Why is this important? Concurrency is hard and if you want M:N thread
> multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned
> to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6.

I guess the author doesn't know about Haskell? The concurrency story for
Haskell is great, and using the right library, you can literally just define
types for the routes for your backend and then ask it to generate JS for your
frontend.

~~~
nilved
By "right library" do you mean Servant? (I'm interested.)

~~~
mrkgnao
Here's an overview I wrote a while back.

[https://news.ycombinator.com/item?id=14149200](https://news.ycombinator.com/item?id=14149200)

------
SeanDav
Without a "Major" sponsor, or a "Rails" type killer application, Perl 6, or
indeed any language, will struggle to get significant traction.

It is of course possible to gain slowly over time, but with numerous languages
competing, that path may be a dead-end.

~~~
forinti
Perl 6 still has to overcome Perl 5, which is everywhere and is a great
language. I never get around to using Perl 6 because 5 is already there in
every Linux distribution.

~~~
bjd2385
I wish Linux distros shipped with more recent language versions, e.g. Python
3.6 and Perl 6 in addition to just 3.4/5 and 5. I understand that it's not
their job to try and push people to update their language skills, but it'd be
nice to have access to them right off the bat if they feel like it.

~~~
chriswarbo
The difference between Python minor versions (e.g. 3.4 to 3.6) is tiny
compared to the difference between Perl 5 and 6.

From what I've seen, the difference between Python 2.x and 3.x is tiny
compared to the Perl 5/6 change.

~~~
b2gills
I think the difference between Perl 5.10 (2007) and 5.26 (2017) is bigger than
difference between the Python 2 of 2007, and Python 3 of 2017

The difference between Perl 5 and Perl 6 is probably about 10x the difference
between Perl 5.10 and 5.26

I like to explain it this way:

Perl 4 is to C

as Perl 5 is to C++

as Perl 6 is to Haskell/Smalltalk/C#/Swift/Julia…

~~~
tripa
Then again I've got Perl code I wrote in the 90s that still runs untouched on
the latest Perl 5. Much more recent Python 2 code (of mine) still won't run
untouched under Python 3.

So I might agree actually on the "bigger", but the "noticeability" does have a
lot to do with the general feeling.

(to be clear, I agree with all of your comment)

------
aduitsis
Read the article, very informative. Pleasantly surprised to find out that it
doesn't mention at all language traits like syntax, but focuses on the
features of Perl6's underlying VM, specifically MoarVM.

~~~
agumonkey
Indeed, a GILless bytecode VM is worth a look.

~~~
rurban
GIL less yes, but not lockless. The previous perl6 VM, parrot, had lockless
threads, scaling linearly per native core. MoarVM even needs to lock on hash
or array accesses, which is certainly not state of the art.

~~~
oconnor663
How did parrot write arrays from multiple threads without a lock somewhere in
there?

~~~
rurban
You deferred updates to the owner via scheduler, with high prio, and continue.
parrot threads are lock free but not wait free. The NQP compiler needed to
know about threaded writes and schedule the update, with a semaphore, while
the other threads continue.

What MoarVM got better was everything else. The GC, the calling convention,
the OO (6model), the jit. I was on my way to fix all the parrot damage done
from the previous decade, because this would have enabled all architectures
and proper threading for perl6, but then perl6 decided to kill it and go with
Moar. And spread a lot of lies on threads.

~~~
pierrebai
I fail to see how using a semaphore to schedule work in another thread is
"lock-free."

~~~
rurban
Because you wait but you don't lock. And the wait is not 100x of an
instruction, normally it's the same time as for one single instruction. Writes
are fast and atomic, because there's no lock. Only the writer needs to wait a
bit, not any other thread.

Google for lock-free vs wait-free

------
joosters
Maybe it's because I'm old, but I don't see the appeal of M:N multiplexing in
a programming language (i.e. 'green threads' or some other user-level context
switching)

For long-running tasks, if they are I/O bound you can use non-blocking I/O and
event loops. If they are CPU bound, then use threads or separate processes.
The two techniques can be combined to scale well across multiple cores.

The OS is designed to schedule workloads, it has decades of development in
doing this, and has all the system-wide information needed to schedule tasks
well across the CPUs. why re-implement the wheel in your programming language?

~~~
kbenson
> For long-running tasks, if they are I/O bound you can use non-blocking I/O
> and event loops. If they are CPU bound, then use threads or separate
> processes. The two techniques can be combined to scale well across multiple
> cores.

That combining _is_ what M:N threading is. Green threads are application level
threads. "threads" are OS level threads. M:N threading is the ability to take
M application level ("green") threads, and schedule them on N actual threads.

> why re-implement the wheel in your programming language?

Because for some things, OS level threads are far too heavy. For others,
application level threads don't achieve the parallelism required to
efficiently use the hardware available. Combining them should allow scaling
well across multiple cores, as you noted yourself. The difference here is that
they are part of the language, which means they can be easily and efficiently
used without setup by everyone using the language.

~~~
joosters
My point is that 'green threads/application level threading' is, IMO, not very
useful in a language. As you say, it's the bit where putting them on actual
threads is a win. A language that does its own green threads or co-operative
multitasking is trying to do the kernel's job, and it will never be as good.

It's at the purported 'web scale' in the article (I'm guessing this means lots
of tasks, or lots of work) that green threads least useful, because you know
there that the workload will be big enough to keep all CPU cores busy, and
multi-threading/multi-process is always going to be a win. Adding green
threading to an already maxed out computer is just extra overhead for no
benefit.

~~~
eikenberry
You shouldn't look at it just in terms of how well it can utilize system
resources. It allows for language level concurrent programming support which
facilitates different programming styles. Some people find this style of
programming 'fits' them and are attracted to these languages as a medium for
expression.

So while other languages can use threads and async-IO perfectly well to keep
all a systems resources utilized, that is not the only point of a programming
language. Programming languages are primarily a means of communication.

------
athenot
I'm glad Perl6 finally went the route of MoarVM. I always felt that ParrotVM
(which was supposed to also run Python and Ruby) was a terrible distraction
and scope creep. The idea was laudable but it would have required buy-in from
the other communities. As much as I like Perl, I don't think that would have
been fair to them, as Python and Ruby have evolved into their own respective
identities.

~~~
krylon
> The idea was laudable but it would have required buy-in from the other
> communities

But imagine how cool it would have been - write a class in Python, sub-class
it from Ruby, use that subclass in a function written in Perl, call that
function from Lua code...

Okay, I see it now. It was just too awesome for its time. Maybe in a hundred
years or so...

~~~
bigleagueposter
JVM is now becoming what Parrot was intended to be with Graal/Truffle.

~~~
krylon
I guess so.

But without Perl 5 _and_ Perl 6 it is just not going to be the same. (Pouty
face)

~~~
mst
Step 1. Fix Rakudo on the JVM

Step 2. Fix the perl5-in-perl6 work

Step 3. Retreat to a corner and sob until you recover some SAN points

------
mempko
Best argument to use Perl 6 is that it's fun. Like really fun. Whatever
language you are using is boring. Perl 6 is just damn fun. It's like your
favorite language but with dollar signs, and funner.

~~~
qbaqbaqba
Perl5 is also fun. Until you have to work with others' people code, or even
your own older code.

~~~
raiph
Many P5 folk claim that it remains fun if the P5 code is well written.

But regardless, having fun with P6, which is specifically designed to be
readable, maintainable, composable, refactorable, etc. is fundamentally
different from having fun with a language like P5.

------
nige123
Perl 6 is indeed fun - it's even optimised for it [1]!

I'm enjoying using it for command-line tools and web applications - it's
expressive and scales with the problem space.

1\.
[https://perl6advent.wordpress.com/2015/12/20/perl-6-christma...](https://perl6advent.wordpress.com/2015/12/20/perl-6-christmas-
have-an-appropriate-amount-of-fun/)

------
krylon
Can anyone recommend a good book on Perl 6? Are there any (even bad ones)?

Right now I feel the major reason that keeps me from investing time in Perl 6
- besides adoption by distros - is the lack of a good book, like the Lama and
the Camel book for Perl 5. It's kind of frustrating after having waited so
long.

~~~
totalperspectiv
This one is 'in progress'
[https://www.learningperl6.com/](https://www.learningperl6.com/)

Looking at the Perl 6 website, there are a few more coming along as well.
[https://perl6.org/resources/](https://perl6.org/resources/)

~~~
cutler
... but nothing from Larry Wall. I don't get it. Perl 6 without a "Programming
Perl 6" (O'Reilly or Pragmatic) will just delay adoption.

------
throwaway7645
Perl6 is indeed a very nice language that I've been watching for a few years.
As soon as the performance beats Python and the stability is solid I'll
probably switch over from Python...there's just a lot there.

~~~
b2gills
I have seen examples where the naive Perl 6 implementation is faster than the
equivalent C code. (The one I'm thinking of is probably owing to Spesh and the
JIT, but I forget what it was about)

Here's an example where a naive Perl 6 version is going to beat the pants off
of the naive version in another language:

Find the sum of all integers from 10 to 1000000 inclusive.

In Perl 6:

    
    
        say [+] 10 .. 1000000
    

the [+] is a left fold using the &infix:«+» operator (&infix:«+» is left
associative)

This finishes almost immediately. (It also does so if the endpoint is 10¹⁰⁰⁰
or more)

The reason is if you use the built in version of the &infix:«+» operator, it
calls the sum method on the Range object. That particular method knows how to
calculate the sum on the Range without iterating through the values. If you
modify the &infix:«+» operator lexically it won't take that shortcut.

This also works the same if you wrote it like this:

    
    
        say Range.new(10,1000000).reduce(&[+])
    

(There is syntax to omit either or both endpoints with both ways to create a
Range)

There are plenty of areas where Rakudo Perl 6 is slower than I would like, but
for many uses it is fast enough.

~~~
slackersc
That's pretty cool! I started trying to learn perl6 and write my first
interesting program. I have a copy of 'ray tracing in a weekend' and am trying
to translate the basic ray tracer from c++ to perl6.

It's remarkably slow right now.. It takes 1.5 minutes to generate an image. I
tried to do the same thing in Julia and it takes 1.5 seconds. So I guess I
must be doing something wrong!

~~~
Ultimatt
Probably not wrong but quite possibly in a way that's not been optimised well.
I'm sure people on Freenode IRC #perl6 would be interested in your work. Don't
forget `perl6 --profile script.p6` gives nice profiler output out of the box!

------
pmontra
On a sidenote

> or Nginx or Node.js without the callback cacciatore.

What's a cacciatore in this context? It means hunter in Italian. Probably
something messy if it means the same as callback hell.

~~~
dagw
cacciatore is a style of rustic stew in Italian cooking.

~~~
pmontra
I would have bet that cacciatore was about food. To be pedantic, that's "alla
cacciatora" but I won't be picky with Italian food terms outside Italy, it's
good advertising anyway (I'm an Italian in Italy.)

~~~
orbitur
> To be pedantic, that's "alla cacciatora" but I won't be picky with Italian
> food terms outside Italy

It's good that you won't be picky, since you're arguing against decades of
"cacciatore" for Italian Americans. ;)

------
contingencies
Great quote on perl5...

 _In #devops is turtle all way down but at bottom is perl script._ \-
@devopsborat

~~~
tripa
I like how the original was agnostic, yet you interpreted as perl5 :-)

~~~
contingencies
I think it's common knowledge that perl6 is basically rare in deployment,
whereas perl5 scripts are everywhere in legacy systems. Former CPAN author
myself.

------
jypepin
why is everybody saying they are put off by Go? Did we pass the "trend" phase
and now it's cool to say go sucks?

~~~
notamy
Tongue-in-cheek answer: lol no generics :)

To be serious, in my circle of developer-friends, we feel that it tries to be
TOO simple, and disagree with some of the decisions of how the language works
(ex. seemingly endless `if err != nil { return nil, err }` type things)

~~~
codegladiator
I always find it a bit funny when dev's try to put a label of "too simple" on
a language.

How would your friends label "brainfuck" ? Too simple because it has very
limited number of identifiers or Too hard because accomplishing anything is
nightmare ?

~~~
kazagistar
Simple is not the opposite of hard. The opposites are complex and easy.

------
ainar-g
Can Perl6 merge all of its generated VM code into one "package"? One of my
favourite things about Go is that you can statically compile everything and
then deployment basically becomes scp.

~~~
hpcjoe
I find it somewhat humorous that more than 25 years on, we are effectively
reverting to static linking and bundling [1].

Way ... way back in the day, the argument was it would save memory, encourage
reuse, etc. While some of this may have been true, it also gave rise to
dynamic library hell. Reuse was overshadowed by incompatible versions, or API
changes between versions that became the stuff of legends.

This would make a great study in how the ROI was completely overshadowed by
risk considerations not considered at the outset.

Of course, saving memory was a huge issue in the days when 1GB RAM was
considered gigantic. So maybe the cost was worth it.

[1] [https://scalability.org/2017/03/what-is-old-is-new-
again/](https://scalability.org/2017/03/what-is-old-is-new-again/)

~~~
Sean1708
_> Way ... way back in the day, the argument was it would save memory ... it
also gave rise to dynamic library hell._

Could you expand a bit on how static linking would cause either of those
things? It seems to me that they are both consequences of dynamic linking.

~~~
kbenson
I think "the argument" being referred to was the push for dynamic linking, and
the consequences in question are for dynamic linking. I think there was just a
somewhat unclear implicit shift in the subject.

------
Rjevski
My personal issue with Perl is how much of a mess the syntax is (10 different
ways of doing the same thing), and the lack of a standard library (CPAN is not
a viable replacement).

~~~
bloobloobloo
> 10 different ways of doing the same thing

Mostly an urban myth. Where it isn't, at least 8 of those ways are actually
important.

Exercise: write a python program that prints Python's quoting documentation,
without external files, without editing the documentation. Spoiler alert: it's
impossible.

~~~
dmytrish
So, how exactly these different ways of getting sub arguments are useful?

    
    
        sub add1 {
            my ($arg1, $arg2) = @_;
            $arg1 + $arg2;
        }
    
        sub add2 {
            my $arg1 = shift;
            # possibly two screens of dense code here, then
            my $arg2 = shift;
            $arg1 + $arg2;
        }
    
        sub add3 {
            $_[0] + $_[1]
        }
    
        # There may be some other ways to extract arguments 
        #  that I am not aware of.
        # It's possible to combine any of the methods!
    

And this is just argument access, one of the core language primitives.

~~~
kbenson
> So, how exactly these different ways of getting sub arguments are useful?

Because in the second (add2), you might do something interesting with the
second (or third) arguments depending on the first. You might have optional
arguments. Your arguments might be a list of items you don't know the size of.
It allows you to develop what you need out of the extensible core mechanism.
Modules can and have built on that.

> # There may be some other ways to extract arguments

There are. Now you can just do

    
    
        sub add( $arg1, $arg2 ) {
            $arg1 + $arg2;
        }
    

My personal favorite is to use Function::Parameters[1]

    
    
        fun add( Num $arg1, Num $arg2 ) {
            $arg1 + $arg2;
        }
    

which allows named params, type constraints (runtime), default params, etc.

1:
[https://metacpan.org/pod/Function::Parameters](https://metacpan.org/pod/Function::Parameters)

~~~
dmytrish
I cannot imagine any way of practical (ab)using this flexibility that could
not be covered in Python with its only way of handling arguments.

------
16bytes
Even though this could more properly be called, "Why having language support
for M:N thread multiplexing is important", I thought it was a refreshing
article on why I might actually use a bit of perl6.

Last year I attended a conference and saw Larry Wall speak. It was an overview
of Perl 6 and I was completely underwhelmed. Larry spent about half the time
talking about unicode support. It wasn't a boring talk, but I never felt a
moment when I said, "Awesome! This is a pain point in some other languages and
I would pick up perl6 if this ever happened again."

I don't want to write perl6 completely off, but I have found that perl6
advocates have not done a great job on why you would actually want to _use_
it. It's hard to justify learning "different" syntax just because someone
says, "hey, it's fun!".

~~~
cutler
Better math is one good reason. Grammars are also a great feature of Perl 6.

~~~
16bytes
I've never faced a problem in another modern language where math became a big
problem. Even using something like numpy made never made me frustrated with,
say, python's numerical types.

From what I've seen perl6 makes some operations more convenient. Cool, I
guess, but not a great reason to reach for perl6.

Grammars _are_ really cool, and one reason I might reach for perl6, but you
also have really great special-purpose tools like Antlr. I suppose I don't
feel the need grammars that often to need them reified in my language of
choice, but next time I need to do some parsing, however, I will probably play
around with perl6.

~~~
cutler
I should have been more specific. Try this in Ruby, Python, PHP or Javascript:
0.1 + 0.2 - 0.3 . You'll get an approximation in most languages but only Perl
6 returns 0.

~~~
16bytes
Yes, I understand the example. It's a classic floating point numbers
demonstration.

What I am saying is that I have not encountered a real-life case where this
would have made my life easier.

Again, it's neat, but not a real reason to move to a new language.

~~~
petre
Banking/accounting software? Generating reports that are expected to return
correct data w/o cumulative errors from flating point arithmetic? After all,
Perl is the Practical Extraction and _Report_ Language.

~~~
16bytes
I'm not saying there aren't applications where it is useful. If you can't
tolerate errors, then you typically don't use floats in the first place. We've
been running banking/accounting software for a long time without Perl 6.

What I am saying is that this isn't a killer feature.

It makes me go, "Oh, neat", and not, "Wow, this will make my life so much
easier".

------
rastapasta
thanks for touching the heart of an old perlmonk :)

------
hardwaresofton
It's pretty cool to see Perl adding this feature. My rubric for the three big
scripting languages (once upon a time?) was:

Perl: Good at regular expressions, and proper per-processor core threading,
Bad because what you wrote will be indecipherable to future you

Python: Very expressive (without being too much), lots of library support,
good drop-to-c/do-stuff-fast support, sensible support for object and
functional programming paradigms that evolved over time, super useful stdlib.
Bad because GIL

Ruby: ???? at least it's beautiful? seems to only be used in codebases that
are rails-based which is basically a red flag for me now due to personal
preference

It looks like Perl just got another killer feature

~~~
b2gills
Perl 5's base object system was based on Python's

Ruby has been referred to as Perl 5 with a better object system.

Perl 5 also has Moose an object system based on Perl 6's which has been ported
to Python and to Ruby twice.

The way to allow calling into C with NativeCall is almost seamless most of the
time. It has also been used to make using modules/libraries from other
languages even more seamless. (usually the only way you know the module is
from a different language is the :from<Python> in the use directive.)

------
libeclipse
Thing that really gets me about perl is the syntax, it's horrendous.

No other reason, that's all. Just the syntax.

~~~
Scarblac
It's _different_. But working for a few years with Perl 5, it really grew on
me. It could use a good "Perl: The Good Parts" book, I guess.

I haven't looked at Perl 6 yet, don't know if that's better or worse. Too many
other things to do, and I don't think I'll ever work with Perl professionally
again, that ship has probably sailed.

~~~
abecedarius
_Higher Order Perl_ might serve for that. (I haven't really read any other
Perl books.)

~~~
nocman
And you can read it for nothing, if you are interested:

[http://hop.perl.plover.com/book/pdf/HigherOrderPerl.pdf](http://hop.perl.plover.com/book/pdf/HigherOrderPerl.pdf)

------
jonbarker
Does this not help with handling this issue in python or is this considered a
hack? [http://effbot.org/zone/thread-
synchronization.htm](http://effbot.org/zone/thread-synchronization.htm)

------
pvdebbe
I like writing bash scripts a lot and perl is a natural step-up with powerful
libraries to use. As others have said, the major obstacle for me has been the
lack of great literature.

~~~
dmytrish
For small tasks I enjoy aesthetics of small dedicated Unix tools (grep, sed,
awk, cut, sort) working together much more.

Perl tries to be everything at once, still mysteriously lacking interactive
REPL out of the box. Yes, Python is more heavyweight for scripting, but it
pays in the long term with better maintenance and tooling for big scripts.

~~~
daotoad
So do you like small tools or having everything built in (like a REPL)?

It sounds like you are justifying an emotional attachment rather than making
consistent arguments.

Now, there is nothing wrong with having an emotional attachment to a language
or other tool, as long as you know it for what it is.

Python is a great language and has some really nice features, it's C extension
system is miles better than Perl 5's horrible mess called XS. But to me, using
it feels like wearing my shoes on the wrong feet, I really prefer Perl 5.

From my experience and from listening to colleagues, Python has one edge on
Perl 5. Perl 5 and Python have very similar tooling abilities. Long term
maintenance of large systems is pretty much the same. Python has the edge in
ability to find and hire qualified people because the community has done a
better job articulating Python's strengths and recruiting new people.

------
cutler
Perl 6 carries 2 pieces of baggage from its predecessor - prefixing variables
with "my" to create lexical scope and the obligatory "use v6;" at the top of
every script. Why can't an advanced language like Perl 6 scope variables
without littering "my" everywhere? You don't see it in any other mainstream
language I can think of.

~~~
petre
How is this different than prefixing variables with _var_ in JavaScript?

~~~
dugword
Just to be pedantic ;)

var creates variables that are function scoped. my creates variables that are
block scoped.

let in JavaScript would be pretty much the same as my.

Both are good things as they prevent typos from being new variables.

------
grondilu
> Guess what it outputs? Nothing! Just kidding, you’ll see a lot of distressed
> messages from tasks that passed out wait for the phone to ring, and woke up
> wearing someone else’s OS thread.

Well, as a matter of fact I really got no output at all :(

~~~
libeclipse
> Actually, the program will output nothing if you’re using a release of Perl
> 6 prior to Rakudo Star 2017.07; a caching bug previously caused $*THREAD.id
> to report an out-of-date value.

------
spion
Needs a correction re: node.js. It does have await and does switch context
now.

------
Paul_S
This would've been so much easier if they just called Perl 6 something else.
Would've saved them so much aggravation.

~~~
daotoad
You aren't alone in thinking that.

[http://blogs.perl.org/users/zoffix_znet/2017/07/the-hot-
new-...](http://blogs.perl.org/users/zoffix_znet/2017/07/the-hot-new-language-
named-rakudo.html)

[https://github.com/perl6/marketing/blob/master/TablePosters/...](https://github.com/perl6/marketing/blob/master/TablePosters/Rakudo-
Concise/Rakudo-Concise--72ppi.png)

------
_pmf_
> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE
> CODE, where application threads aren’t pinned to pthreads) your options
> today are precisely Erlang, Go, .NET, and Perl 6

Why mention .NET here? Async code in .NET works with a dispatcher thread
(-pool) under the hood, which is nothing like the greenish threads that the
other systems offer. Am I missing something?

~~~
pjmlp
TPL, tasks are the greenish threads you mention.

You can also just call Windows fibers directly, if feeling adventurous.

------
fundabulousrIII
I'll stick with Tcl if I'm going to use a glue language that has green thread
like functionality and an event loop. early choices were tcl or perl: went Tcl
and never looked back.

As far as web development in perl..well have fun convincing everyone on the
node.js and python bandwagons to move 'back' to perl. Glad it works for you.

~~~
totalperspectiv
I hadn't heard of Tcl before but it looks awesome! What do you find its ideal
use cases to be?

~~~
fusiongyro
Tcl is pretty old. A lot of the territory it covered well is now better
covered by other things.

One of its great strengths was being extensible. It's pretty easy to bake some
functionality into Tcl and provide a new shell with it. This is what expect
([http://expect.sourceforge.net/](http://expect.sourceforge.net/)) is, for
instance.

Another early advantage of Tcl was Tk, which provided Tcl extended with GUI
stuff. Tk was cross-platform and established very early on, so if you wanted
to provide one GUI for Unix, Mac and Windows, it was a good choice. It was
very ugly for a long time; I hear it has gotten better lately but I don't know
that myself. Tk is still built-in to Python as Tkinter. This is another
specialty shell provided by Tcl, wish ("window shell").

Tcl was supposed to be good for embedding. The original author was supposedly
using it for robotics. I haven't seen much energy there; I think Tcl's lunch
probably got eaten by Lua some time ago. Lua is smaller, more like a modern
programming language and easier to embed, but Tcl is more like shell
scripting, so I guess there might be style reasons why you might prefer Tcl
despite Lua's advantages.

Tcl is easy to disparage, but there's a lot of misinformation out there. At
one time, it really only had one data type (strings). Quotation is a big topic
in Tcl, but like Lisp, you can supply your own control structures. Everything
is a command and commands have a lot of freedom about how to interpret their
arguments. It is rather Lispy, unlike Lua. Tcl does have modern data
structures and it does pretty snazzy things behind the scenes to optimize
access to them while making things still seem to be strings for the cases
where that matters.

Tcl is still around in some surprising places. I wouldn't expect there being a
lot of new development starting with Tcl but it's kind of a fun language to
know about. I got the newest edition of the book and it's a neat book, but I
confess I haven't found ideal use cases for it.

~~~
fundabulousrIII
Old is relative. There is a good core dev community and recent development is
promising. It's interesting you mention Lua because that is a language I
picked up when looking to move from Tcl at some point in the last 8 years. I
decided rather quickly against that.

The reason is the swig bindings for Tcl are sufficient to generate decent
package cores for just about anything I care to extend and I can optimize
later.

~~~
fusiongyro
Old is relative, but there aren't many alternatives to Tcl that are older.

~~~
throwaway135634
Depending on your exact use case, Forth might be one

------
saysorry
I ctrl+F searched these comments for the word "hipster", 0 matches. If this
was about JavaScript though...

------
Thaxll
Perl is pretty much dead, I don't anyone still using that beside legacy code.

~~~
ue_
Nobody's using P6 for legacy code.

~~~
Thaxll
What kind of sane person who would use Perl ( 6 or older ) on a new project
nowdays.

~~~
nocman
Lots of "sane" people would (at least for Perl 5). I know it's not "the new
hotness", but Perl 5 is still an incredibly useful language that a lot of
people know (present company included). There are extensive libraries
available for doing a lot of things that need to be done in day-to-day
business. There are plenty of perfectly legitimate places to use it in new
development.

The Perl 5 porters development list has a decent amount of traffic (
[http://www.nntp.perl.org/group/perl.perl5.porters/2017.html](http://www.nntp.perl.org/group/perl.perl5.porters/2017.html)
). And Perl 5 still has a good number of active contributors (
[https://www.openhub.net/p/perl/contributors](https://www.openhub.net/p/perl/contributors)
). Also, The CPAN has _plenty_ of modules with daily activity (
[http://search.cpan.org/recent](http://search.cpan.org/recent) ).

Even if you would not choose to do new development in Perl 5 (because of other
language preferences, or whatever), that does not mean it is unreasonable (or
"insane") for others to do so.

Whether Perl 6 will ever catch on, I don't know. The language has a lot of
features that look interesting, and I think it could also be very useful. I
personally have not had time to look at it much yet, but probably will when I
don't have higher priority things in life preventing me from doing so.

------
kazinator
All I think about when I hear M:N thread multiplexing is "1992 is calling to
have its stupid threads hacks back".

M:N is what you do when you don't have real kernel thread support. You hacked
N user space threads per process (N:1) but then 1990 rolled in and cheap SMP
with M processors started to spread across the land, so you needed N:M to take
a bit of advantage of that.

~~~
b2gills
Perl 6 has M:N thread multiplexing along with normal thread support. It's just
that M:N thread multiplexing is easier to use because all of the hard work is
done for you.

------
mapcars
It's terrible that you put Erlang on a list with other languges/VMs.

>There’s no GIL, so unlike Those Other Languages

There is no GIL in EVM as well, but playing with the words you make it look
like "all are the same". This does not deserve top HN and just stupid.

If your Perl6 VM is _so_ great, why didn't you mention anything about what's
really important like preemptive scheduling which has been Erlang's unbeatable
feature since the beginning? Less hype and more details, please.

~~~
macintux
FWIW, the author is very well-known and respected in the Erlang world for his
work on Chicago Boss. Any perceived slights against Erlang are likely
unintentional.

