[sago]

GIL seems to me to be only a niche problem in reality. But it is a bit of a storm in a powerpoint (i.e. people see it on a list of features of python and panic. Even though, as the article says, Javascript has much more constrained single-threadedness).

I've been deploying python for almost 20 years, and I haven't had a single performance issue that was caused by GIL and couldn't easily be worked around. In my experience, building big multithreaded applications with shared memory access isn't great design anyway. I prefer systems that share as little as possible, and can therefore scale beyond a single machine when needed.

So I think the focus on the GIL is a false quest. It isn't a bad compromise to a thorny implementation issue (it allows certain performance optimisations, without forcing you to worry about re-entrancy and atomicity when writing simple code). Removing the GIL will be a big thing for pundits, I think, but won't make much of a difference to big python deployments. It certainly isn't the killer app for Py3 adoption.

[kaoD]

Disclaimer: I used both Python and Node.js at job, and use Node.js regularly for side projects.

I think the difference is that Node embraces the single-threadedness as part of its architecture. I don't use Python that much now so I'm not sure if it's changed, but I found it clumsier by default.

I know there's Twisted and other nice evented/multiprocess libraries that make Python closer to Node, but it surprises me that a batteries-included language with a GIL has to be, as you say, worked around. I don't work around single-threadedness in Node, I work towards it! And the platform encourages me to do so.

EDIT: I'm not sure why you seem to have been downvoted (man, I hate HN sometimes). Here's an upvote to counter it.

[sago]

GIL is a bogeyman, particularly from folks who've never deployed large python codebases, so I was fully expecting downvotes. Unpopular opinions attract them. Though it would be more gratifying to see downvotes along with people's use cases for when GIL was a genuine issue for them.

I agree that Node has its single-threadedness baked in, and Python doesn't clearly have one way to do it. Still, I think that multithreaded programming isn't very scalable in the long-run. Learning Erlang and figuring out that message passing buys you much more headroom was important to me. I like that you can do simple things in Python simply, but it is important to have some understanding of why different languages solve the problem in different ways, and what approach is best for a problem domain. My sense is that Node's default approach is actually very good for a large range of situations, a larger range than multithreading, anyway. But that could be because my use-cases are often either UI or CPU bound.

In your example, is your domain primarily internet servers (what I assume is Node's sweet spot for commercial deployment).

[mpdehaan2]

Sharing nothing between reqeusts is (IMHO) a much more resilient model in web applications, mainly because you are forced to use the database as state and can scale out horizontally. On a single node, something like mod_wsgi will also let you run in multiple forks automagically, and even you can set things like MaxRequestsPerChild to kill forks every 5000 requests to defend against memory leaks.

So yeah, the GIL is not an issue there. You'll just want something like celery for backend jobs, which is nice because it also maintains job state/info that survives process death - which globals in twisted won't do for you.

So, basically, it's a much more resilient way to do thngs, particularly if the front end of your application is request driven. Doesn't fit all models though.

(Also, Django + Django REST Framework is pretty awesome).

[aidos]

I agree, it's not a problem in most spaces.

I'm one of those not so lucky souls that could benefit from having the GIL removed. I do a load of concurrent read only access from multiple threads of execution on a large object in memory. At the moment I'm forced to fork using multiprocessing. It works, but it sucks to have the overhead.

Though, as you say, it's really a non-issue for most workloads.