> Is there a reason to learn Perl these days when we have Python?
Yes, the GIL - global interpreter lock (in python) is a reason if you are doing multithreaded stuff in a scripting language (which i think is a bad idea by definition because suddenly you are debugging problems in your program as well as the interpreter/runtime)
Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
Let's not pretend perl threads solve concurrency issues in dynamic languages.
The third item in the threads perldoc, after the table of contents and the version, is a big, fat warning about how you shouldn't use them [1]:
> The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help.
>The use of interpreter-based threads in perl is officially discouraged.
> Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. Also most of the librarys that use perlxs modules aren't thread-safe.
> Let's not pretend perl threads solve concurrency issues in dynamic languages
i didn't 'pretend' that - that's a misstatement; still a big fat lock in the interpreter isn't a concurrency solution at all, instead of running concurrently your threads will be mainly blocked on the lock.
Interpreter threads is an approach that does without a global lock, but as i said it is still a pain to debug the result - as you are effectively debugging both your program and the runtime.
> Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes.
threads are not copy on write processes; that is not unique to perl threads. The advantage of threads is that it makes easier to share data - with processes you will need to do a shared memory segment for that. Also it is less costly to create a thread rather than a process.
> The advantage of threads is that it makes easier to share data
Sharing of data is of marginal benefit when you have to pay the cost of duplicating all of your data to begin with. Perl also has modules that make forks just as easy to use as threads.[1] This is doubly so when most libraries have little to no regard for thread safety because perl's threading support it so bad.
> Also it is less costly to create a thread rather than a process.
Not unix because of copy on write processes [2][3]. Perl threads copy not just the interpreter but all local variables. [4] The only place threads are useful is on windows where the cost of a fork is higher than a thread.
> most libraries have little to no regard for thread safety because perl's threading support it so bad.
Fwiw Perl 6's concurrency and parallelism is very much one of its strengths, not one of its weaknesses.
(It's pretty obvious to me that you are writing about Perl 5, not Perl 6, but it might not be obvious to others. Indeed some folk will even claim Perl 6 isn't a Perl, but Perl's original creator Larry Wall thinks Perl 6 is a Perl, and I think he has a point.)
Yes, the GIL - global interpreter lock (in python) is a reason if you are doing multithreaded stuff in a scripting language (which i think is a bad idea by definition because suddenly you are debugging problems in your program as well as the interpreter/runtime)
Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.