Hacker News Reader

Comment by simula67 | Hacker News Reader

Even today, Perl is the only scripting language with more than 200K modules and no Global Interpreter Lock.

As of 3.13, Python doesnt have a GIL either. JVM-based Ruby implementations don't have a GIL. Perl on the other hand never had a GIL, it just more or less defeated the purpose of threading by copying the entire interpreter state including all variables in every thread. Modules that explicitly work with threading are as rare as hens teeth on CPAN, it's almost always some flavor of async like Coro (hell I bet POE still works too).

python 3.13 most certainly has a GIL, it can just be optionally disabled, and this feature is in experimental status. see https://peps.python.org/pep-0703/

Oh, I thought the experimental state was earlier and that 3.13 was the official no-GIL release. Presumably it's going to eventually drop the GIL entirely (probably Python 4 if there ever is such a thing) but nonetheless I stand corrected, thank you.

Who needs fork/join framework when it's so easy to call the OS fork() from inside your program?:-)

I was curious about this and did some casual googling. It spawns an interpreter per thread. However, it seems this is not advantageous performance wise. From docs [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 makes them easy to misuse. Few people know how to use them correctly or will be able to provide help.

[1]: https://perldoc.perl.org/threads

No, instead they have subinterpteters with all of the massive overhead that brings re: data sharing. And even fewer CPAN modules are remotely thread safe than PyPi modules, probably in absolute as well as relative terms. That’s a low bar.

As a result, threaded Perl code or frameworks are extremely uncommon, even relative to Python.

GIL is a python paradigm.

Reply on news.ycombinator.com