7 ms·

I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks

I feel like anybody really searching for speed is using something other than Python. I don't use Python for speed, but for ease-of-use. It took me some clicks to see it's supposed to be a drop-in replacement, so that's good.

RandallBrown 6y ago
Sure, but there's lots of people already using Python that would probably love some more speed.
tgv 6y ago
I feel you, but then again, Python applications tend to deployed anyway, so a speed boost can be welcome for some. Memory usage looks better, too.
qorrect 6y ago
I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!
- wil421 6y ago
  The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.
  - austinpena 6y ago
    Likely because pytorch uses C++ under the hood.
- throwaway5752 6y ago
  Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.
- ehsankia 6y ago
  Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
- anakaine 6y ago
  I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
- hhas01 6y ago
  20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage. Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.
  - newen 6y ago
    I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.
    - hhas01 6y ago
      Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
    - coldtea 6y ago
      >Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
    - dragonwriter 6y ago
irrational 6y ago
Maybe. One of my projects at work is supporting a legacy ColdFusion website that is nearly 20 years old (well, it was started 20 years ago, but has seen updates since). We'd love to move it to something faster, but it is huge and it would literally take years to rewrite it. Other things take priority so it will probably never be rewritten. I imagine there are Python projects in a similar boat.
- pastage 6y ago
  Rewriting parts of it will not take years. Most of it can probably be thrown away, replaced by standard components. (only talking from personal experience, sure we had legacy systems running for years).
  - irrational 6y ago
    Unfortunately that wouldn't work with this site. Between the five of us in my group we have nearly 100 years of developer experience. We've talked a lot about if there is anyway we could divest of it a little at a time or replace parts of it, but we really can't.
chrisseaton 6y ago
> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.
- Shared404 6y ago
  > I don't get why people object to performance work on languages not intended for performance. Presumably because they see it as effort that could be better applied elsewhere. I don't know that I agree, but I can understand the viewpoint.
- Narann 6y ago
  > I don't get why people object to performance work on languages not intended for performance. You're right, this objection is not relevant in general. But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free. This trade of makes the point about the language choice relevant.
- mhh__ 6y ago
  > I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)
  - saluk 6y ago
    As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.
coldtea 6y ago
>I feel like anybody really searching for speed is using something other than Python. Well, anybody using Python for all its over benefits, still would very much like more speed.
sally1620 6y ago
It is not about searching for speed. It is about lowering the cost of large Python code base running in production.
nerdtime 6y ago
Why not make the languages that are easy to use speedy? That way I don't have to search for one or the other.

RandallBrown 6y ago

Sure, but there's lots of people already using Python that would probably love some more speed.

tgv 6y ago

I feel you, but then again, Python applications tend to deployed anyway, so a speed boost can be welcome for some. Memory usage looks better, too.

qorrect 6y ago

I use python because of Numpy, Scikit and Tensorflow. I don't know of any other languages with libraries as productive as these, so speeding these apps up is a big win for a lot of people. Also 20% is huge, I look forward to trying it!

wil421 6y ago
The 20% speed up looked like it was for flask and Django. In their benchmarks PyTorch did not have a speed increase.
- austinpena 6y ago
  Likely because pytorch uses C++ under the hood.
throwaway5752 6y ago
Aren't all of those mostly implemented in C or C++ extensions? Not to minimize speeding up the glue code, but I don't know if they will see that large of an improvement.
ehsankia 6y ago
Well that still goes in the "ease-of-use" bucket in my opinion. That being said, those libraries are already highly optimized and all the heavy stuff running on C anyways, so making the Python itself faster won't make that much of a difference in those workflows.
anakaine 6y ago
I'm in 5he same bucket here. My other ecosystem products are built on top of python, so we make use of pandas, numpy, dask, and our vendors own modules (which have taken them 10+ years to put together with a reasonably full team).
hhas01 6y ago
20% faster is nothing. You want at least a magnitude faster to justify the cost and risk of switching. The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now. I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage. Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom. There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.
- newen 6y ago
  I agree. Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages.
  - hhas01 6y ago
    Ah, sunk costs. Where the future goes to die. And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
  - coldtea 6y ago
    >Almost all arguments in favor of Python is about sunk cost. Not much about the actual language is appealing compared to modern languages. Well, I, for one, use Python because "the actual language is appealing compared to modern languages".
  - dragonwriter 6y ago

irrational 6y ago

Maybe. One of my projects at work is supporting a legacy ColdFusion website that is nearly 20 years old (well, it was started 20 years ago, but has seen updates since). We'd love to move it to something faster, but it is huge and it would literally take years to rewrite it. Other things take priority so it will probably never be rewritten. I imagine there are Python projects in a similar boat.

pastage 6y ago
Rewriting parts of it will not take years. Most of it can probably be thrown away, replaced by standard components. (only talking from personal experience, sure we had legacy systems running for years).
- irrational 6y ago
  Unfortunately that wouldn't work with this site. Between the five of us in my group we have nearly 100 years of developer experience. We've talked a lot about if there is anyway we could divest of it a little at a time or replace parts of it, but we really can't.

chrisseaton 6y ago

> I don't use Python for speed, but for ease-of-use. Right - but if you can get that with better performance that's good isn't it? I don't get why people object to performance work on languages not intended for performance.

Shared404 6y ago
> I don't get why people object to performance work on languages not intended for performance. Presumably because they see it as effort that could be better applied elsewhere. I don't know that I agree, but I can understand the viewpoint.
Narann 6y ago
> I don't get why people object to performance work on languages not intended for performance. You're right, this objection is not relevant in general. But in the situation we talk about, having 20 % more performance requires you to choose a fork that can came with it's own limitation. It's definitely not free. This trade of makes the point about the language choice relevant.
mhh__ 6y ago
> I don't get why people object to performance work on languages not intended for performance My gut feeling is that Python is just not safe or static enough to ever be worth trying to compete with (say) C++ with. Python sure is easy but I think the asymptotic cost of using it for a big project (in my hands at least) is just not worth it. I like Python's syntax quite a bit but I feel bad watching people learn to program using it - partly because it's an oddly low-level language (It's closer to being C than Haskell) and there's no compiler to stop you shooting yourself in the foot (If I write something fundamentally unsound I want to know about it now not when the process has been running all day)
- saluk 6y ago
  As someone who learned on python (many years ago), I think the balance of being allowed to shoot myself in the foot, while only having to learn complexity when complex concepts came up, was a good combination rather than a bad one. Trying to learn C++ and Java before, having to type everything was an impedement. On python, you find out that types still matter when you try to add a string to an integer, for example. The moment the type matters to you is when you need to dig into those details. I'm not sure I would have the career I do if it hadn't been around to be the one language that fit my 16-year old brain.

coldtea 6y ago

>I feel like anybody really searching for speed is using something other than Python. Well, anybody using Python for all its over benefits, still would very much like more speed.

sally1620 6y ago

It is not about searching for speed. It is about lowering the cost of large Python code base running in production.

nerdtime 6y ago

Why not make the languages that are easy to use speedy? That way I don't have to search for one or the other.