Ask HN: Perl 6: Do you use it, how do you like it, what do you do with it?

For those wondering what library he is talking about in point 2, that is libev by Marc Lehmann. Before moving to libuv node was using libev for events and libeio for I/O

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.

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.

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.

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.