11 ms·

Why not the other way around? What did Python have relative to other languages that inspired these developers to devote so much energy into their projects? Th

Why not the other way around? What did Python have relative to other languages that inspired these developers to devote so much energy into their projects? They could have chosen PHP, Ruby, Node, Go, Java, etc. If I think back to ~2012 I remember that compared to other languages Python had: 1) Decent package management and "virtualization" (via virtualenv) 2) Nice balance of expressiveness and strictness 3) Was fun to write, hard to explain but it was the vibe 4) Decent enough performance for most things 5) Lots of developer tooling for debugging and stuff It felt like the least messy of the scripting languages. - Everyone knows all the issues PHP had, no need to list it all here - Ruby was cool but there were a thousand ways to do the same thing - Node was inheriting that weird web language with all its quirks - Go was just in its infancy - Java was the kitchen sink

throwaway894345 4y ago
Sadly Python has stood still in the interim, focusing mostly on completing the migration from 2 to 3, by which point the competition was much farther along and continuing to innovate at a rapid pace (performance, package management, type system, tooling, etc).
- 0xFACEFEED 4y ago
- jonnycomputer 4y ago
  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
justsomeguy123 4y ago
> What did Python have relative to other languages that inspired these developers to devote so much energy into their projects? Not a popular opinion, but Python had Google.
- seanp2k2 4y ago
  Google App Engine was ahead of it’s time, but unfortunately not very good if you weren’t trying to write a webapp with the intention of scaling it on Google hosting.
mch82 4y ago
Python had PyPI and scientific packages. It’s an attractive language for people who want to integrate existing packages into a solution instead of creating everything from scratch. Poorly written software that correctly implements science/physics tends to be more valuable than expertly written software that encodes a science/physics defect.
- mch82 4y ago
  People who aren’t software engineers don’t really care about exotic language features. They care more about packages, developer experience, documentation, tutorials, and how difficult it is to share code with teammates.
- 0xFACEFEED 4y ago
  I mentioned this in another comment below, but scientific packages were often ignored when building web services and APIs and that's the context in which Django/Flask were built. At the time the scientific packages were extremely heavy and best avoided in production environments. Some people did it anyway but removed it once they needed to scale. Simply installing these packages was a huge pain and blocked one's ability to provision new machines, for example. PyPI was indeed a big benefit. Ruby Gems are also what made Ruby so competitive at the time.
  - code_biologist 4y ago
    Slapping some scipy, sklearn, or pandas stuff into Django was a pretty workable solution even back when. Just want to sing the the praises. I've slayed a lot of normal size (as opposed to big) data problems with Django/Flask. Rub some JS charting on top of it and people thought you were a wizard.
    - 0xFACEFEED 4y ago
      Oh it was workable. Until it wasn't. I specifically remember extricating a high throughput web service from pandas. Having to scale made that stuff harder. If it was some app that a few thousand people were using, no problem.
_oghd 4y ago
it has that xkcd comic. no joke.
- krallja 4y ago
  import antigravity
  - _oghd 4y ago
    exactly. check this out: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F05z1_ https://trends.google.com/trends/explore?date=all&geo=US&q=%... see the inflection date? end of 2007. guess when that comic[0] was published 2007-12-15 mic drop [0] https://xkcd.com/353/ https://xkcd.com/353/
    - krallja 4y ago
      It definitely had a minor positive effect on my feelings about learning Python later, when I was offered the professional opportunity.
twelvechairs 4y ago
Ruby had all of your points 1-5. I don't think the difference was 'a thousand ways to do the same thing' (python has many ways to do the same thing also, and ruby's approach made it 'more fun') but some of the core libraries - especially things like numpy, pandas, scipy, etc. that both increased performance, simplified a wide variety of tasks and also attracted a broader range of users (mostly the 'scientific community').
- 0xFACEFEED 4y ago
  This is anecdotal, but my experience was that Ruby was fashionable in the wrong kind of ways. For example... Ruby doesn't have primitive data types. Everything, including strings, are just objects. This level of purity is quite nice and "cleaner" in a conceptual sense. Until you encounter a large codebase with hundreds of monkey patches. Or, something I saw a lot, the extending of "base" data types such as String. I must admit that my memory is a little hazy here, but I remember that it was impossible to find language tooling that allowed me to "jump to definition" of anything I encountered. Ruby was so free-form with so much ambiguity that at the time it just didn't exist. I'm sure this has been resolved by now. In Python we had "Jedi" and other tools that worked really well for this purpose. You'd be browsing a Ruby codebase, see `some_str.foo`, and wonder: 1) Is foo a method or a property? In Ruby a function call doesn't need parenthesis if it takes no arguments. 2) Where is foo? I don't remember it being part of the standard library. Where is it defined? 3) If I do find foo, did something else monkey patch it? How would I know? 4) If I need to pass an argument into foo, should I factor it out of String? At what point am I overloading a base class like String with too much functionality? These are very real questions and the answers are important. Come across enough of these scenarios (remember this is just one example w/ Ruby) and you eventually give up trying to understand the codebase at that level. Everything becomes a black box, everything is magic. Do these footguns exist in Python? Sort of. You can't extend primitive types and monkey patching doesn't fit so cleanly into a normal program (think of it as "friction"). There was less ambiguity in Python's syntax. And the language community promoted a list of idioms which was helpful for discouraging bad practices. These things may seem subtle but they made a pretty big difference at the time. > especially things like numpy, pandas, scipy, etc These libraries were generally avoided when building web services, APIs, etc. The context of this discussion is Flask and the engineer(s) who built it were generally working in the world of live services. Dropbox, Reddit, and other YC companies made heavy use of Python as live service type software. Data analytics stuff def existed but different context. The reason numpy and friends were avoided was due to the complexity of installing them. The dependency list was enormous and some of those dependencies needed to be compiled on the fly. Scientific packages also typically shipped with very large datasets to support whatever complex computing they were doing (think training data). The 'scientific community' played a small part in the creation of the frameworks discussed here. If they did, it was more that Python was one of the first languages that the creators picked up in University.
Nextgrid 4y ago
At the time, Python was the best choice, and nowadays since Python has all these frameworks that solve the problem there's less demand for an alternative in a different language if you can use the thing that already exists and has over a decade of battle-testing.
nunez 4y ago
Go and Node were infants back then Java was (and still is) insanely heavyweight Ruby was tied to the hip with Rails despite being more than capable on its own and being much more expressive than Python (IMO). Python is faster though. PHP was (and still is) PHP
- philsnow 4y ago
  Ruby has Sinatra, which is much closer to Flask than to Rails.
- 0xFACEFEED 4y ago
  We were shipping Go services all the way back in 2011! A bunch of my friends were working at other well known companies (of the time) and shipping Go stuff. Service based architecture was pretty popular and people were experimenting a lot. Walmart picked up Node.js in 2012. Not for their core stuff obviously but they were running a bunch of internal services with it. LinkedIn was evaluating it alongside Ruby (EventMachine) and Python (Twisted). They ended up picking Node for some of their services. Highly concurrent green-thread-ish type stuff was all the rage. Go and Node were the front runners. Python was the conservative choice. Ruby was hipster choice :P
- seanp2k2 4y ago
  Love Ruby method chaining and .tap(). Ruby was the language I could most “think in” and write a lot of stuff then have it just work like I figure it would. Python makes me roll my eyes having to explicitly handle a bunch of random small errors, like it’s being overly pedantic. I’m also not a fan of significant whitespace, which is another reason I prefer JSON to YAML (along with always having to look up if I need a hyphen on a line or not).
Semiapies 4y ago
"Back in 2012", Django was already 7 years old and had taken most of the market share of the first generation of Python web libraries and frameworks. This included that strange beast that was once considered the "standard" Python web system, Zope. Bluntly, Django had a much better development experience overall than the older web options. (Mind you, the likes of Zope and CherryPy are still out there and under development. You just don't hear about them much.) Up until about 2010, web dev in Python was converging hard on Django. It took Flask and similar small frameworks to bring back variety, and all of those had to meet the requirement of better than Django in at least some narrow sense, if only in being much lighter, to get any uptake.
- foxhop 4y ago
  don't leave Pyramid out of the picture, it powers key infrastructure pypi.
  - Semiapies 4y ago
    There were many early Python web systems that are still in active development, so I kinda do have to leave someone out. But good call in mentioning Pyramid. :)
garfieldnate 4y ago
Core Python didn't include pip until a few years after that; package management with Python in 2012 was a confusing mess.

throwaway894345 4y ago

Sadly Python has stood still in the interim, focusing mostly on completing the migration from 2 to 3, by which point the competition was much farther along and continuing to innovate at a rapid pace (performance, package management, type system, tooling, etc).

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

justsomeguy123 4y ago

> What did Python have relative to other languages that inspired these developers to devote so much energy into their projects? Not a popular opinion, but Python had Google.

seanp2k2 4y ago
Google App Engine was ahead of it’s time, but unfortunately not very good if you weren’t trying to write a webapp with the intention of scaling it on Google hosting.

mch82 4y ago

Python had PyPI and scientific packages. It’s an attractive language for people who want to integrate existing packages into a solution instead of creating everything from scratch. Poorly written software that correctly implements science/physics tends to be more valuable than expertly written software that encodes a science/physics defect.

mch82 4y ago
People who aren’t software engineers don’t really care about exotic language features. They care more about packages, developer experience, documentation, tutorials, and how difficult it is to share code with teammates.
0xFACEFEED 4y ago
I mentioned this in another comment below, but scientific packages were often ignored when building web services and APIs and that's the context in which Django/Flask were built. At the time the scientific packages were extremely heavy and best avoided in production environments. Some people did it anyway but removed it once they needed to scale. Simply installing these packages was a huge pain and blocked one's ability to provision new machines, for example. PyPI was indeed a big benefit. Ruby Gems are also what made Ruby so competitive at the time.
- code_biologist 4y ago
  Slapping some scipy, sklearn, or pandas stuff into Django was a pretty workable solution even back when. Just want to sing the the praises. I've slayed a lot of normal size (as opposed to big) data problems with Django/Flask. Rub some JS charting on top of it and people thought you were a wizard.
  - 0xFACEFEED 4y ago
    Oh it was workable. Until it wasn't. I specifically remember extricating a high throughput web service from pandas. Having to scale made that stuff harder. If it was some app that a few thousand people were using, no problem.

_oghd 4y ago

it has that xkcd comic. no joke.

krallja 4y ago
import antigravity
- _oghd 4y ago
  exactly. check this out: https://trends.google.com/trends/explore?date=all&geo=US&q=%2Fm%2F05z1_ https://trends.google.com/trends/explore?date=all&geo=US&q=%... see the inflection date? end of 2007. guess when that comic[0] was published 2007-12-15 mic drop [0] https://xkcd.com/353/ https://xkcd.com/353/
  - krallja 4y ago
    It definitely had a minor positive effect on my feelings about learning Python later, when I was offered the professional opportunity.

twelvechairs 4y ago

Ruby had all of your points 1-5. I don't think the difference was 'a thousand ways to do the same thing' (python has many ways to do the same thing also, and ruby's approach made it 'more fun') but some of the core libraries - especially things like numpy, pandas, scipy, etc. that both increased performance, simplified a wide variety of tasks and also attracted a broader range of users (mostly the 'scientific community').

0xFACEFEED 4y ago
This is anecdotal, but my experience was that Ruby was fashionable in the wrong kind of ways. For example... Ruby doesn't have primitive data types. Everything, including strings, are just objects. This level of purity is quite nice and "cleaner" in a conceptual sense. Until you encounter a large codebase with hundreds of monkey patches. Or, something I saw a lot, the extending of "base" data types such as String. I must admit that my memory is a little hazy here, but I remember that it was impossible to find language tooling that allowed me to "jump to definition" of anything I encountered. Ruby was so free-form with so much ambiguity that at the time it just didn't exist. I'm sure this has been resolved by now. In Python we had "Jedi" and other tools that worked really well for this purpose. You'd be browsing a Ruby codebase, see `some_str.foo`, and wonder: 1) Is foo a method or a property? In Ruby a function call doesn't need parenthesis if it takes no arguments. 2) Where is foo? I don't remember it being part of the standard library. Where is it defined? 3) If I do find foo, did something else monkey patch it? How would I know? 4) If I need to pass an argument into foo, should I factor it out of String? At what point am I overloading a base class like String with too much functionality? These are very real questions and the answers are important. Come across enough of these scenarios (remember this is just one example w/ Ruby) and you eventually give up trying to understand the codebase at that level. Everything becomes a black box, everything is magic. Do these footguns exist in Python? Sort of. You can't extend primitive types and monkey patching doesn't fit so cleanly into a normal program (think of it as "friction"). There was less ambiguity in Python's syntax. And the language community promoted a list of idioms which was helpful for discouraging bad practices. These things may seem subtle but they made a pretty big difference at the time. > especially things like numpy, pandas, scipy, etc These libraries were generally avoided when building web services, APIs, etc. The context of this discussion is Flask and the engineer(s) who built it were generally working in the world of live services. Dropbox, Reddit, and other YC companies made heavy use of Python as live service type software. Data analytics stuff def existed but different context. The reason numpy and friends were avoided was due to the complexity of installing them. The dependency list was enormous and some of those dependencies needed to be compiled on the fly. Scientific packages also typically shipped with very large datasets to support whatever complex computing they were doing (think training data). The 'scientific community' played a small part in the creation of the frameworks discussed here. If they did, it was more that Python was one of the first languages that the creators picked up in University.

Nextgrid 4y ago

At the time, Python was the best choice, and nowadays since Python has all these frameworks that solve the problem there's less demand for an alternative in a different language if you can use the thing that already exists and has over a decade of battle-testing.

nunez 4y ago

Go and Node were infants back then Java was (and still is) insanely heavyweight Ruby was tied to the hip with Rails despite being more than capable on its own and being much more expressive than Python (IMO). Python is faster though. PHP was (and still is) PHP

philsnow 4y ago
Ruby has Sinatra, which is much closer to Flask than to Rails.
0xFACEFEED 4y ago
We were shipping Go services all the way back in 2011! A bunch of my friends were working at other well known companies (of the time) and shipping Go stuff. Service based architecture was pretty popular and people were experimenting a lot. Walmart picked up Node.js in 2012. Not for their core stuff obviously but they were running a bunch of internal services with it. LinkedIn was evaluating it alongside Ruby (EventMachine) and Python (Twisted). They ended up picking Node for some of their services. Highly concurrent green-thread-ish type stuff was all the rage. Go and Node were the front runners. Python was the conservative choice. Ruby was hipster choice :P
seanp2k2 4y ago
Love Ruby method chaining and .tap(). Ruby was the language I could most “think in” and write a lot of stuff then have it just work like I figure it would. Python makes me roll my eyes having to explicitly handle a bunch of random small errors, like it’s being overly pedantic. I’m also not a fan of significant whitespace, which is another reason I prefer JSON to YAML (along with always having to look up if I need a hyphen on a line or not).

Semiapies 4y ago

"Back in 2012", Django was already 7 years old and had taken most of the market share of the first generation of Python web libraries and frameworks. This included that strange beast that was once considered the "standard" Python web system, Zope. Bluntly, Django had a much better development experience overall than the older web options. (Mind you, the likes of Zope and CherryPy are still out there and under development. You just don't hear about them much.) Up until about 2010, web dev in Python was converging hard on Django. It took Flask and similar small frameworks to bring back variety, and all of those had to meet the requirement of better than Django in at least some narrow sense, if only in being much lighter, to get any uptake.

foxhop 4y ago
don't leave Pyramid out of the picture, it powers key infrastructure pypi.
- Semiapies 4y ago
  There were many early Python web systems that are still in active development, so I kinda do have to leave someone out. But good call in mentioning Pyramid. :)

garfieldnate 4y ago

Core Python didn't include pip until a few years after that; package management with Python in 2012 was a confusing mess.