5 ms·
The current situation of Python's performance is really pathetic. Thanks for the project, we need to make Python great again otherwise the future is for Go, Eli
by myf01d 10y ago
The current situation of Python's performance is really pathetic. Thanks for the project, we need to make Python great again otherwise the future is for Go, Elixir and Rust.
- sametmax 10y agoPeople are obsessed with performances, while my experience is that for the enormous vast majority of projects you could run on something 10 times slower than Python. Actually, I have a friend of mine running a streaming website. He banks 15k€ a month for 400k daily users. Python perf has zero inpact on his project. Python ease of use and maintainability means he, as a terrible (really terrible) programmer have been able to keep the site up and running for 5 years. I worked in africa for a while. Needs for Python perf ? Zero. Needs for code that is understandable and easy to write. A LOT. Moved to geographes working on SIG. Needs for Python perf ? Hell the GIS engine does the heavy work, they don't care. But they don't undestand jack about programming and need things done. Python let them to do it cleanly. Or I moved to embeded programmers. Hardcore C coders that are using Python to test their boards. Need for Python perf ? They don't even know what you are talking about. For them perf is assembly. They want something that is fast to write, with 10000 libs available. As a trainer and dev I teach Python on a monthly basis. JS training. Jeez, where do I begin ? If you let them do something more than a one-file stuff, they are lost. Python ? They are project ready in no time. Data mongers ? They have numpy and databases. Now myself ? I code in Python all the time. I've seen many slow sites. It's always either because of the DB queries or the static assets. Never about the server side language, be it Python, JS, Ruby or PHP. Coding in Go, Elixir or Rust for task where my productivity is more important than the machine output makes no sense. Especially in a world where an unmetered VPS cost 3€/month (https://www.ovh.com/us/vps/ https://www.ovh.com/us/vps/) with 2 GB RAM and 10 GB SSD. I can just take 100 of those and build a freaking skynet without making my company accountant blink. We are not google or facebook (and they do use Python BTW. Fb just announced they are migrating to 3 massively). So yes, more perf is nice. I would literally pay to help having better perf because it's always a good thing. But stop pretending you need it so bad, because you would be magically the 0.1% that actually do on all the forum post where people are saying they are. It's a nice to have. If you want to switch to something else, just admit you are following a trend. Dev always are. They love what's new and shiny. Nothing wrong about it. But those "Python is slow I'm out" posts are ridiculous. Dropbox can say that. Bank of America can say that.
- christophilus 10y agoYeah. I mostly agree with this. Developer productivity is the best thing to optimize for. These are the most important metrics for that, in my opinion: Code readability, good editor w/ intellisense, fast test suite, solid library ecosystem. It would be interesting to see an analysis done of developer productivity across languages to find out which language provides the best over all value for new and existing codebases.
- vgy7ujm 10y agoPerl would be my bet.
- sametmax 10y agoPerl fail on big code base, particularly because the cognitive load of reading it is high.
- vgy7ujm 10y agoI'm not really buying into that argument. I have seen Python code that is unreadable, actually a lot worse than 90s PHP/Perl. Take a look at modern Perl please.
- sametmax 10y agoPerl 6 is better, but it still offloads a lot of the logic parsing to the human brain. Create an array or string, take the last element and display it: <A B C>[* - 1].say; The same in Python: print(['A', 'B', 'C'][-1]) The same in Ruby: print ['A', 'B', 'C'][-1] The first version is a good example of what perl is good at : it's short to write. The Python version is more verbose. But, your brain has to do the following: - Scan the element to realise A, B and B are strings. Perl can have strings with "A", but in this here you can write it without it. So when you read, you need context to know what's going on. The Python version make it clear it's a string. - Then figure out the that the separation is on the spaces. Python put comas, so you don't have to parse negative space in your head. - the you have the "*" you need to integrate to get context of what element you use. Then you get the ";" which is just noise. Small elements like those add up very, very quickly in a code base. Every time your brain has to gather context before understanding what it reads, you add cognitive load. You can't scan the code. PHP, Perl and JS by nature have a higher cost that Ruby or Python. The laters have been design with readability in mind. You have less tricks, they are more boring. And easier to read. Of course you have many other small issues with perl, like figuring out why you use .say but .WHAT in uppercase. Why the shell by default on some linux setup have a broken history. Why you can leave out the .say most of the case in the shell, but sometime if you don't use it nothing is displayed. That you have to install the rakuto package on Ubuntu but run the perl6 command to start the shell, etc. All in all, Perl is a neat technical achievement, but has not been very ergonomy oriented.
- throwawayish 10y agoMy experience is that people that scream the loudest about "performance" are often also people that make micro-benchmarks and derive ridiculous claims from them, and also seem to often be the people that otherwise don't know much about "performance", or be in need of it. For the by far largest share of web applications, easily everything to the 99th percentile, performance, in the "sense" of this benchmark, is wholly irrelevant.
- crdoconnor 10y ago>For the by far largest share of web applications, easily everything to the 99th percentile, performance, in the "sense" of this benchmark, is wholly irrelevant. Amen to that. Performance is incredibly low on the list of concerns for most businesses I've worked for. Getting code out quickly and making it work reliably are usually priorities #1 and #2. Performance is a "sexy" problem though.