It always puzzled me why so many Perl devs moved to Python when Ruby is a much closer fit. Sysadmin tools can't be the reason because Ruby led the way with Chef and Puppet. Perl was my first real programming language back in 2002 and "Programming Perl" was my bible. Larry Wall is a wonderful gentle giant of a leader but unfortunately the community imploded over never-ending debates about OOP and MOP then there was the 15-year Perl 6 energy drain. If Perl had established a web framework to compete with Rails and Django it might have survived but Catalyst is an ugly beast and Mojolicious somehow never gained the momentum required despite being a much better option for web development.
> Sysadmin tools can't be the reason because Ruby led the way with Chef and Puppet.
Chef's first release was 2009; Puppet 2005, by which point many people had already moved to Python.
My experience is that Ruby was virtually unheard of in the English-speaking world until the rise of Rails (post-2005); at any point in time there are thousands of programming languages "out there" but only a handful have mainstream recognition; back in the 2000s Python was a known name in a way that Ruby just wasn't.
I hear this a lot, but I have to wonder if it is just the bias of web developers who never looked at it before Rails. I started using Ruby in 2001 in Montreal where other colleagues were using it. We were all former Perl people who had gotten fed up with Perl and we didn't care for the inconsistent object orientation of Python.
I'm not a web dev and have never used Rails, but I hadn't even heard of Ruby until Rails and Puppet got popular. I'm sure every language has a few people who heard about it in its early days, but I do think Rails was the catalyst for Ruby going mainstream, even to non-web people.
In my opinion, Cro (https://cro.services) stands a good chance of becoming the "Ruby on Rails" for Perl 6.
"Cro is a set of libraries for building reactive distributed systems, lovingly crafted to take advantage of all Perl 6 has to offer. The high level APIs make the easy things easy, and the asynchronous pipeline concept at Cro's heart makes the hard things possible."
"Cro is currently in BETA. We're overall quite satisfied with most of the APIs, and don't plan major changes in this regard. Expect some bumps on the road - and if you run into any of them, please consider filing a bug report so we can make things better."
Perl 6 is technically a far superior language than all the usual suspects (Python, Ruby, JS, PHP, Perl5) put together but what use is that when it's dog slow? The latest Rakudo is 23 times slower than PHP 7.2 in a task which used to be Perl's forte - parsing a log file with a regex.
I'm getting at the fact that it's 9 times slower than Perl 5 at doing something which made Perl famous - parsing files with a regex. Perl 6 seems to have thrown away the basics of Perl while trying to be all things to everyone.
At this point in time, I wouldn't recommend parsing files with a regex just yet. Parsing is indeed one of the few areas in Perl 6 that hasn't seen any specific optimizations yet.
Where Perl 6 has seen a lot of work, is general performance, and specifically in the part of concurrency.
Where the common idiom for grepping lines using a lazy iterator and showing the matching lines from a file in Perl 6 is:
.say for $filename.IO.lines.grep( { m/foo bar/ } );
You can spread this out over multiple CPU's by simply adding the word `hyper` to it.
.say for $filename.IO.lines.hyper.grep( { m/foo bar/ } );
On most current hardware (4 x 2 hyperthreaded CPU's) this would cause this code to run 3x as fast, while keeping order. If you're not interested in order, you can use `race`:
.say for $filename.IO.lines.race.grep( { m/foo bar/ } );
Which will make it go a little faster still because it won't need to remember the order of the batches of work.
So, yes, at this time, that particular job is done 9x faster with Perl 5 than it is with Perl 6. If you don't need any specific features of Perl 6, I'd suggest you keep using Perl 5 for that. Whether this answer will continue to be correct in the future? Time will tell.
Wrong priorities then. I also doubt this will ever be fixed. Perl 6 is just unacceptably slow at the basics. I mean if Perl 6 had been rushed out I would find these excuses more acceptable but after 15 years in development!?
In my case (having gone Perl [1991] -> Ruby [~2003] -> Python [2014] — with some Tcl during the Perl phase), the surrounding ecosystem was the decisive factor. There are tons of machine learning tools based on Python.
Another possible factor is that the irregular syntax and noisy punctuation of Perl started bothering me, so if that's what you dislike, Python makes more sense precisely because Ruby is lexically a bit closer to Perl.
I think many mistakes were made during Perl 6 development, but ultimately, I decided that the problem was not the Perl team not delivering the language I wanted, but that I wanted Perl to be a language it never was, never was meant to be, and never will be. So nowadays, I'm pretty happy with Python, except when I write a literal one-liner in Perl.
> It always puzzled me why so many Perl devs moved to Python when Ruby is a much closer fit.
For me it was that I wanted to get away from Perl: the fact that Ruby is like Perl is, from that point of view, a bad thing. I wanted something that would be clean, something that wouldn't surprise me, something where I could dig into someone else's code or revisit mine and not be lost. Python was, for many years, that language.
I can't speak for the devs, but the sysadmins in my world largely skipped ruby for a couple of reasons, such as speed, ease of the language, memory issues (which have mostly been solved now I hear), and the general ecosystem just got more adoption quicker so people gravitated towards it.
Honestly part of the problem is there has been an explosion of language choices that can all be used to get the job done, so it becomes very subjective to the individual and business as to what tool(lang) they use to accomplish their goals. Who has time to deal with so many different languages and their ecosystem complexities. The issues with ruby caused me to at first completely skip ruby to the point of not even using ruby tools because it took less mind-overhead that way. The same with node. Python with a large ecosystem was a safer choice and easier to learn. With python I get the choice of ansible and salt, with ruby I get chef and puppet, and I personally prefer ansible.
I'm also the kind of crazy who lives in emacs and still writes bash scripts daily so... take it all with a grain of salt.
It was when I found an awesome tool I wanted to start updating myself (http://argus.tcp4me.com/) that I realized perl is just hard for me to read and logic about easily...(I abandoned that project)
I really need to give 6 (Rakudo or?) a try sometime. I think I'm just going to skip it and go straight to guile and go.
> It always puzzled me why so many Perl devs moved to Python when Ruby is a much closer fit.
Maybe because Ruby was a much closer fit: close enough to make it harder to break out of Perl approaches, different enough that that often had bad results.
But I think lmm’s sibling comment gets the bigger reason right.
Perl -> Python user here: one of Ruby's strengths is metaprogramming features, which is why it's a natural fit for DSL-building problem domains like config management. I would say Chef and Puppet probably made the right choice.
I went the Python route instead. For me, my choice at the time was a purely pragmatic one based on ecosystem. Python simply had the stronger one at the time for most of the problem domains I was working in, and this continues to be true today.
Ruby is syntactically more elegant though -- it has a Japanese Zen-like quality. I really wanted to like it, but I knew it would mean living in a world where I had to reimplement, possibly badly, the stuff I needed to do the rest of my job.
Maybe from a developer standpoint, but from a deployment standpoint I absolutely disagree. I've never been a huge Perl fan (except for oneliners) and I still insist I would've had a happier life in my ops role if Puppet had been written in Perl. Mind you, I hardly ever dug into the source code, only used it, but I'm pretty sure a lot of the packaging/deployment/speed/memory problems could have been alleviated by using a language runtime that was available on every host system and in a usable version as well. All the omnibus packaging wasn't good and Puppet on low-memory hosts has always been terrible.
I do think Python would've been an even worse choice at the time because distros were shipping ancient version of it for ages (e.g. 2.4) and nobody was really using that, whereas Perl modules have traditionally been shipped as distro packages in a rock-solid state forever.
Using perl exclusively for web development, I was quite lucky when I switched to the very immature ( back then ) NodeJS.
I remember how happy I was and how fast I was able to run and develop anything ( compared to Catalyst ). Still, being a very big fan of Perl, unfortunately have to state that having a Perl job would already be a step backwards in my career.
Perl served it's purpose when CGI scripting was considered normal web server, but nowadays golang, NodeJS + TypeScript are having way bigger community than Perl and they feel "modern" compared to even Perl6.
I still use a lot of Perl one-liners, but I moved on to Go instead of Python because I needed more speed/efficiency for crunching through lots of data. There isn't enough difference between Perl and Python on the performance front (unless you use packages with C under the hood).
Mind elaborating a bit? I've been planning to learn Perl specifically "for crunching through lots of data", like multi-GB databases, and Python for other scripting tasks. But a few days ago I learned that Ken Thompson co-wrote Go and that it's used by CloudFlare, Netflix, Docker, Kubernetes, etc. Now your comment makes me wonder if Go would be a better fit for me than Perl. Furthermore, Twitch.tv migrated their chat spam engine from Python to Go, so maybe Go would even be a twofer.
I do write in golang for money, and in Perl 6 which unfortunately noone pays me for. The two languages are so fundamentally different that I find it hard to even compare them!
Golang certainly is quite efficient, probably close to C or C++. It also has lightweight threads which are great and terrible at the same time: you can take the thread-based concurrency model further without resource problems. And the CSP approach helps to make that somewhat safe. But at the end of the day any concurrency built on threads, even lightweight ones, is problematic.
It is a ridiculously low-level in terms of abstractions language though, just a tiny notch above C. Perl 6 is quite on the opposite end of that scale.
For me the most important differences are cultural however: Perl 6 is quite open and inclusive, both people and the language it self. TIMTOWTDI. I don't think I can or want to describe the Golang culture, but it certainly is quite different.
The good thing about Golang is that as a language it is so simple/primitive that you can easily try it out for yourself and get a comprehensive picture over a weekend.
Perl 5 is only a bit faster than Python 3 so not worth learning another language as they're both dynamic scripting languages. Go is compiled so you could get a bigger speed bump.
Back in the day when Perl and Python competed, you had to know Japanese to read Ruby's documentation. Perl had a cool hacker cult following, Python had an extremely friendly community, and Ruby's was... Japanese and invisible on the English-speaking Usenet.
Python was specifically designed for many of the use cases that people use perl for. Guido's paper for I think a language called ABC was a precursor to Python and explains some of the motivation for its design.
I read the paper about 20 years ago. I might be wrong in what I remember but I don't think the focus was on academic math. Will have to go find it and quickly scan it.
> The thing about Perl is that it just starts small, with a regexp here, a text-file line counter there. Nothing that couldn't have been managed quite easily in Bash or Sed or Awk. But once you've written a couple of scripts, you're in—there's no going back. Long-term Perl users remember how we started, and we see the newbs going the same way.
Somehow I never graduated; I write scripts occasionally but Perl one-liners have been my favorite way to use Perl for like 20 years. For most of that time, I’ve been meaning to get more fluent with awk & sed, but whenever the need comes up to get something real done, I use the Perl I know.
> I discovered after she handed in the results that it hadn't produced the correct results, but I didn't mind. It was tight, it was elegant, it was beautiful. It was Perl.
Sounds like a lot of Perl codebases. Tight, elegant, beautiful, incorrect results.
For my current reverse engineering project Perl was not good enough anymore for the easy parts, so I had to switch to picat, for some tricky constraints solving. Similar to Prolog, but with a SAT solver, and very Perl/python/Haskell like syntax. Actually the syntax is almost the same as my Perl VM: potion.
The front cover came off my copy of Programming Perl, detached by long use. Having said that, these days I seem to write more Python, since that's what the young know.
