Hacker News new | past | comments | ask | show | jobs | submit login

I've had my share of frustration with the GIL over the years, but I don't think it fits into the list.

Python's rising years have been the same years that we discovered that (a) generalized parallelism is really hard, and (b) many many many applications of muticore are "embarrassingly parallel" and benefit little from shared resources. Stasis around the GIL is a usecase-driven decision to make embarrassing parallelism easy enough (via multiprocessing) and delegate more involved parallelism to linkable libraries or separate services. It helps the language focus on what it's good at.




I think for most people, async io / coroutines gets them most of the benefit that they'd ever get out of multi-threading.

With async io, you can have a lot going on at once, interleaving nicely while different tasks wait for io responses.

Beyond that, normally you're just as well off to kick off a second process.

You have to get pretty fancy with algorithms to make multi-threaded computation a net-benefit. Most of the time you don't need that. If you do, you're probably not reaching for python.


I agree. Having worked on some long running systems ( > 20 years). Often their success comes from simplicity - - almost any choice different from the GIL, at the time of Python's beginning, would have massively hurt at least one of performance or usability.


I always wondered why there was specifically so much chatter about Python's GIL. If you consider PHP, Perl and Ruby to be Python's main "competitors", they have pretty much the same limitations (not much real world single process concurrency being used) but much less noise around it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: