3 ms·

Async took forever too. Node was already being evaluated against Python/Twisted back in the early 2010s (and winning!). Great point about package management. G

Async took forever too. Node was already being evaluated against Python/Twisted back in the early 2010s (and winning!). Great point about package management. Go already had it figured out. Node was busy figuring it out (npm shrinkwrap; still sucked but less so). Any time I talked to people about Python the conversation was about 2to3 and core team drama lol

physicsguy 4y ago
And on top of that, if you’re using Django, async support is still incomplete and will be for at least another year
- throwaway894345 4y ago
  Same with many SDKs. I haven’t looked into it recently, but IIRC there is mo official async AWS SDK. I’m pretty sure there also is no async Kubernetes SDK either.
- lambdadmitry 4y ago
  I was pondering this for quite a while, and overall I'm struggling to see why would it be more than "nice to have". Minor performance gains that very few companies would actually need? That's pretty meh. Chats and SSE and reactive stuff? Even with async, django doesn't fit those applications well. Other than getting on with the cool kids, why do you feel that async support in Django is particularly important?
  - 0xFACEFEED 4y ago
    You are 100% correct. For the types of applications built with Django, async is actually more of a hinderance than a benefit. Async I/O can create massive back pressure in a distributed system. A simple example would be a web service that gets a massive influx of traffic (organic or DDoS, doesn't matter). If the web service is using async I/O to manage database connections with an unlimited connection pool (often the default) then it will happily accept all incoming requests and push all of that pressure onto the database. The database gets overwhelmed because it's inherited all of that traffic. The database starts refusing connections not just to the web service but any service that connects to the database. And boom, you have system wide outage. Obviously the database should guard against this kind of overwhelming traffic but that's often thought about last. Diagnosing the problem becomes a lot harder since your bottleneck is further downstream. It gets messy. Synchronous services on the other hand create a nice throttle. Your Django app is never going to achieve the kind of throughput that your database will. So, by design, your Django app will get overwhelmed first because it won't accept new connections (eg: maybe it runs out of memory). That being said I still think it makes sense for Django to support it. Not for a chat app, but say... web sockets. You may want a websocket connection that pushes notifications back to a single-page-app. The notifications will contain a bunch of contextual data that the Django framework provides easy access to (think ORM, templates, etc). Obviously you could build the websocket thing as a separate service but then you lose all the goodies that Django provides to you.
eptcyka 4y ago
Go really didn't figure package management until very recently.
- throwaway894345 4y ago
  Well, 2018, or about 6 years after 1.0. Granted it took some time to polish rough edges and get the ecosystem moved over to it.
jimnotgym 4y ago
Has node got it figured out. "Delete node-modules and try again" seems to be all to common in our developer chat system
- seanp2k2 4y ago
  The whole Node “works on my laptop” thing can be mostly resolved by ensuring that unit / intg tests run as a prerequisite for merging on a separate CI system with a clean (as in no existing node_modules) build workspace each time. It’s almost always down to bad package.json / package-lock.json practices // mixing in global packages.

physicsguy 4y ago

And on top of that, if you’re using Django, async support is still incomplete and will be for at least another year

throwaway894345 4y ago
Same with many SDKs. I haven’t looked into it recently, but IIRC there is mo official async AWS SDK. I’m pretty sure there also is no async Kubernetes SDK either.
lambdadmitry 4y ago
I was pondering this for quite a while, and overall I'm struggling to see why would it be more than "nice to have". Minor performance gains that very few companies would actually need? That's pretty meh. Chats and SSE and reactive stuff? Even with async, django doesn't fit those applications well. Other than getting on with the cool kids, why do you feel that async support in Django is particularly important?
- 0xFACEFEED 4y ago
  You are 100% correct. For the types of applications built with Django, async is actually more of a hinderance than a benefit. Async I/O can create massive back pressure in a distributed system. A simple example would be a web service that gets a massive influx of traffic (organic or DDoS, doesn't matter). If the web service is using async I/O to manage database connections with an unlimited connection pool (often the default) then it will happily accept all incoming requests and push all of that pressure onto the database. The database gets overwhelmed because it's inherited all of that traffic. The database starts refusing connections not just to the web service but any service that connects to the database. And boom, you have system wide outage. Obviously the database should guard against this kind of overwhelming traffic but that's often thought about last. Diagnosing the problem becomes a lot harder since your bottleneck is further downstream. It gets messy. Synchronous services on the other hand create a nice throttle. Your Django app is never going to achieve the kind of throughput that your database will. So, by design, your Django app will get overwhelmed first because it won't accept new connections (eg: maybe it runs out of memory). That being said I still think it makes sense for Django to support it. Not for a chat app, but say... web sockets. You may want a websocket connection that pushes notifications back to a single-page-app. The notifications will contain a bunch of contextual data that the Django framework provides easy access to (think ORM, templates, etc). Obviously you could build the websocket thing as a separate service but then you lose all the goodies that Django provides to you.

eptcyka 4y ago

Go really didn't figure package management until very recently.

throwaway894345 4y ago
Well, 2018, or about 6 years after 1.0. Granted it took some time to polish rough edges and get the ecosystem moved over to it.

jimnotgym 4y ago

Has node got it figured out. "Delete node-modules and try again" seems to be all to common in our developer chat system

seanp2k2 4y ago
The whole Node “works on my laptop” thing can be mostly resolved by ensuring that unit / intg tests run as a prerequisite for merging on a separate CI system with a clean (as in no existing node_modules) build workspace each time. It’s almost always down to bad package.json / package-lock.json practices // mixing in global packages.