A place for programmers of all languages to come and chat, show off what they've done, and general shop talk.
Yes, Python is Slow, and I Don't Care
I'm taking a break from my discussion on asyncio in Python to talk about something that has been on my mind recently: the speed of Python. For those who don't know, I am somewhat of a Python fanboy, and I aggressively use Python everywhere I can.
Yes, Python is Slow, and I Don't Care
hackernoon.com




As much as I like Python, I think there are some rebuttals that need to be made. While Python might be a great choice when you're working on the initial prototype and time-to-MVP is your most important metric, it may not be the best idea to stick with it as you try to scale. There's a reason why large sites like Twitter, Amazon, and Facebook, which were originally written in dynamic scripting languages (Ruby, PHP, and Perl, respectively), have since moved the critical parts of their infrastructure to compiled languages (Scala, HHVM, and Java, respectively).
Resource Usage Actually Does Matter (at scale)
Python, Ruby, and other programming languages are very wasteful of CPU resources. They use a lot more memory and cycles for the same computation than Java or Scala. While it's true that this won't be your bottleneck early on, what happens when you need to aggressively scale out. While you could throw more hardware at the problem and run instances of your service on more nodes, this will eventually become very expensive. At a certain scale, it will make sense to rewrite and optimize your application so that you can handle a higher volume of requests with less hardware. As for rewriting things in Cython/C. The C programming language doesn't strike me as the safest thing to write your webservice code in. But there's another issue with Python not related to performance.
It's Hard to Manage Large Projects
As your application becomes larger, more complex, and (hopefully) more stable, you need tools with a greater focus on safety. It's no longer just about making it easier to write new code, it's about making it easier to change code and be confident the changes didn't break things. You can achieve this with Python by writing a lot of unit tests. But more type-safe languages can relieve you from a lot of the testing burden. Having worked at Amazon, which primarily uses Java, it's worth the extra typing in order to get that extra safety.
The recommendation to use microservices is definitely good though. It makes it easier to port your system to a more efficient language. You can rewrite the more resource intensive services in Java or Scala and leave the others in Python.
Yes, the article had no tradeoff analysis. One should list advantages and disadvantages.
Then the author might wonder: are there tools which merge developer productivity with computer performance? I think there are.
And there's other dimensions to consider, like reach. Can your tools target JVM, Javascript, etc? They're major platforms with a ton of libraries. Libraries may be even more important than a language's expressive power—code you don't have to write.
(That said, Python has many good libraries too. And its design is generally more sound than Java. I don't necessarily believe Java is better for correctness & robustness vs change than Python.)
I honestly think that traditional "classist" OOP languages like Java and C++ are actively detrimental to robustness, but that's my own bad opinion
There's never going to be universally good programming advice. A thing I notice people doing a lot in these discussions is taking whatever kind of programming they do and taking their conclusions about how to best do that kind of programming, and positing them as hard truths or even as more than very localized conclusions. This is especially true of assertions about language choice.
Programming languages are primarily tools meant to be used by humans and a lot of the arguments over language choice are basically a left-handed person trying to tell everyone they need to use left-handed scissors. CPU cycles being or not being a bottleneck is a purely local contingency, too, and it can vary wildly even between seemingly similar applications.
Like, I'm primarily a game developer, but I care 0% about CPU or GPU performance when it comes to code; those are just not the kinds of games I'm making. Someone working on stuff that is superficially similar to what I'm doing might care enormously about cycles because their game has stuff that it needs to calculate every frame and they want to run at decent framerates even on mobiles.
Similarly, some big networked applications are just glue to turn http queries into database access, and some are engines for doing large-scale math, and often those two use cases get conflated easily because they're superficially the same kind of thing. Like, any sort of bespoke solution for a big company is going to be seen as "enterprise" and people will think that the same solutions apply to it even though those applications might be doing wildly different things.
The bottom line is, though, Python is a really bad language that you shouldn't use, and Ruby is way better.
Interesting piece and good perspective.
I wonder how this applies to something like golang, which, from my understanding, really excels at optimizing around the network being the bottleneck. While Go would be slower than java or c++, its faster than python while having a similar type feel to it.