| > And I know some smart Alec will trot out the usual 'downshift into C' line that everyone (including Guido) use as the final goto solution for performance but that is simply a disgrace in 2017. Easy gluing of other languages together has long been something I considered a strength...but I suppose to each their own. > Why can I not choose to write Python and it be fast?? Well there are lots of reasons...including implementation issues and I don't know them all...but I think Python has a very clear productivity niche. Personally, I am ok with Python trading performance for productivity. For the most part, I haven't had Python be so much of a bottleneck that writing a very small part of logic to be performant hasn't solved my use case. > And yet Python 3 is getting slower. Don't agree? Yeah I don't agree...that benchmark uses Python 3.3. The corner on Python 3 performance over Python 2 started turning around 3.4. Perhaps a talk from this years PyCon would help illustrate: https://www.youtube.com/watch?v=d65dCD3VH9Q > But PyPy is proof that Python can be fast. Indeed, I would even say that Cython is even more proof that there are frontiers of performance that could be explored. But with PyPy (as with Cython) their are sacrifices you have to make. Personally, I think the most promising performance improvement that is tantalizingly close for me is Larry Hasting's Gilectomy project: > https://www.youtube.com/watch?v=pLqv11ScGsQ But at the same time, I am not sure that Python ever needs to be fast running in CPython. With `WASM` perhaps it is better to just compile Python. I don't know, performance in Python has always been a mixed bag...but personally I think it doesn't get much focus because it doesn't really serve Python's target niche. I don't know if there ever will be (or should) be 1 language to do everything...and as it is Python is a good "productivity" focused language to have in your toolbox so-to-speak. |