[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).