4 ms·

Honestly, I'm having a hard time buying this opinion. Python3 has changed a lot in the last 10 years, and much of those changes have been for the better.

throwaway894345 4y ago
I guess I’ll preface by saying I’ve been developing and operating Python services for about a decade, and I did a bunch of Python before that in various capacities. I’ve made a lot of money with Python, and I’m not one of the people who tars a language without having used it in anger. Those changes have largely been incremental and/or questionable. Python has async now, which is cool, but anyone calling a sync call or some poorly optimized algorithm anywhere in the stack can bring the entire application down. Type hints are moving slowly in the right direction, but they’re still really cumbersome and mypy is still a pain to use (publishing type hints, recursive types, loading type hints, etc). Last I tried it (admittedly it’s been a year since I was deep in the Python game) it was still pretty beta quality. Package management still sucks. Deployment still sucks. Yeah, Docker helps, but it also makes some things worse, like local dev and build times and so on. And there aren’t many good solutions for distributing CLIs and other apps to users—some of the zip things work okay but they don’t close over the runtime, stdlib, or shared objects. Moreover, Python dependency zips can be huuuge—we were busting the 250MB lambda limit (compressed—this was back when lambda had a limit, pretty sure they upped/removed it since) meanwhile a comparable Go binary weighed in at 6MB. Performance still sucks. Yeah, the 3.11 improvements will feel big to a Python programmer, but 40% (made up number) faster than 1000X slower than Go is still really slow (yeah, “just write the slow parts in C/Numpy/multiprocessing/whatever” works once in a while, but very often it doesn’t and it’s basically impossible to know from the project’s outset whether all of its bottlenecks will be amenable to that particular optimization). So to summarize areas where Python has been left in the dust (probably an incomplete list): * Performance * Package management * Static type system * Deployment * Async
- 0xFACEFEED 4y ago
  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.
seanp2k2 4y ago
F-strings and defaultdict make me dislike Python about 50% less. Date math still sucks compared to JS, and comprehensions tend to be less comprehensible reading code someone else wrote, but Python wasn’t really meant to be a functional lang. All that said, I strongly believe that solving the right problem and working in a language that more of the dev team / company are comfortable with deploying / supporting / integrating with are way more important. I’ve seen far too many times what happens when a team at a BigCo “goes rogue” and wants to use something nonstandard, then has to re-solve dozens of solved problems because of that decision. It’s never been worth it in my experience. M

throwaway894345 4y ago

I guess I’ll preface by saying I’ve been developing and operating Python services for about a decade, and I did a bunch of Python before that in various capacities. I’ve made a lot of money with Python, and I’m not one of the people who tars a language without having used it in anger. Those changes have largely been incremental and/or questionable. Python has async now, which is cool, but anyone calling a sync call or some poorly optimized algorithm anywhere in the stack can bring the entire application down. Type hints are moving slowly in the right direction, but they’re still really cumbersome and mypy is still a pain to use (publishing type hints, recursive types, loading type hints, etc). Last I tried it (admittedly it’s been a year since I was deep in the Python game) it was still pretty beta quality. Package management still sucks. Deployment still sucks. Yeah, Docker helps, but it also makes some things worse, like local dev and build times and so on. And there aren’t many good solutions for distributing CLIs and other apps to users—some of the zip things work okay but they don’t close over the runtime, stdlib, or shared objects. Moreover, Python dependency zips can be huuuge—we were busting the 250MB lambda limit (compressed—this was back when lambda had a limit, pretty sure they upped/removed it since) meanwhile a comparable Go binary weighed in at 6MB. Performance still sucks. Yeah, the 3.11 improvements will feel big to a Python programmer, but 40% (made up number) faster than 1000X slower than Go is still really slow (yeah, “just write the slow parts in C/Numpy/multiprocessing/whatever” works once in a while, but very often it doesn’t and it’s basically impossible to know from the project’s outset whether all of its bottlenecks will be amenable to that particular optimization). So to summarize areas where Python has been left in the dust (probably an incomplete list): * Performance * Package management * Static type system * Deployment * Async

0xFACEFEED 4y ago
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.

seanp2k2 4y ago

F-strings and defaultdict make me dislike Python about 50% less. Date math still sucks compared to JS, and comprehensions tend to be less comprehensible reading code someone else wrote, but Python wasn’t really meant to be a functional lang. All that said, I strongly believe that solving the right problem and working in a language that more of the dev team / company are comfortable with deploying / supporting / integrating with are way more important. I’ve seen far too many times what happens when a team at a BigCo “goes rogue” and wants to use something nonstandard, then has to re-solve dozens of solved problems because of that decision. It’s never been worth it in my experience. M