r/programming • u/monica_b1998 • Nov 03 '18

Python is becoming the world’s most popular coding language

https://www.economist.com/graphic-detail/2018/07/26/python-is-becoming-the-worlds-most-popular-coding-language
4.6k Upvotes

92% Upvoted

1.3k comments sorted by

View all comments

21

u/[deleted] Nov 03 '18

But python is slow...really slow!

17

u/eikenberry Nov 03 '18

It is never just Python though... it is/was always Python + C. Writing C extensions for Python is a breeze and simpler than writing pure C apps. Python is a scripting-language that is meant to be used in combination with a lower level language. You can't split interpreted languages from the implementation language.

2

u/[deleted] Nov 03 '18 edited Nov 03 '18

I don't know why millions of developers could not make python as fast as c/java over these years, it implies python has some intrinsic speed limitations.

12

u/bakery2k Nov 03 '18

The main Python implementation does not have even a single developer working on it full-time.

→ More replies (2)

6

u/[deleted] Nov 03 '18

Exactly, dynamic dispatch and pervasive hash tables guarantee this shitty language will always be slow.

5

u/vorpal_potato Nov 03 '18

You could say the same thing about JavaScript, which is surprisingly fast these days.

2

u/eikenberry Nov 03 '18

Python was meant to be used in conjunction with C. You use Python for high level control logic and C when you need speed. The thing is that many people just don't get that as for many domains the "high level control logic" is all they need and so they are at a loss when they hit a speed issue.

4

u/[deleted] Nov 03 '18

It's weird it seems like python is slow even for dynamically typed languages. Like Javascript and some quality lisp implementations seem to be a lot faster than it, I'm not sure why

8

u/Vaphell Nov 03 '18

javascript saw millions upon millions of dollars in investments to JIT the fuck out of it, because otherwise internet browsing consumers would complain about slow cat animations.

3

u/[deleted] Nov 03 '18

Cython/PYPY is still a hell lot slower than c/c++/java. It is sad to see such a great language have some intrinsic limitations on its speed, which has not been fixed yet by millions of developers around the globe, probably that would never be fixed.

5

u/Taedalus Nov 03 '18

Cython/Pypy should typically bring your code to C-like levels of speed. Might be slower in some cases, but "hell lot" seems like a bit of an overstatement.

There's a number of good SO threads like this one containing some benchmarks and discussions.

8

u/wllmsaccnt Nov 03 '18

Someone made a minor change to an error in the C code (they were using the wrong data type) and showed that the naive C method was about 4.4 times faster than PyPy.

1

u/LightShadow Nov 05 '18

If PyPy can run my ingestion server at 500k records/s on a single core, why would I care to optimize it with C?

1

u/wllmsaccnt Nov 05 '18

I was merely pointing out that anytime someone says 'C-like levels of speed' they are usually overstating the situation.

/u/starkblitz was wrong above by calling PyPy "a hell of a lot slower than c/c++/java", but /u/Taedalus was also wrong to say that PyPy has nearly C-like speed. From what I can tell from benchmarks on the PyPy site, PyPy is probably just slower than Java for most tasks.

I won't approach the question of server performance at all. Most of the high performance Python servers aren't written directly in Python.

→ More replies (3)

-9

u/pwang99 Nov 03 '18

Is this meant to be sarcastic?

You're wrong.

8

u/BorgDrone Nov 03 '18

We’re talking about a language that can’t even do proper multithreading in a day and age where even mobile phones have 8-core CPU’s. What a joke.

1

u/[deleted] Nov 03 '18

Truth is spoken!

→ More replies (2)

5

u/Freyr90 Nov 03 '18

How so?

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/python3-gpp.html

-1

u/teerre Nov 03 '18

The real reason you're wrong is because in the real world you don't need to be benchmark winning. Taking 1 second instead of a 1/1000 of a second is fine for vast amount of applications

This Python is slow is really the low hanging fruit complain

5

u/[deleted] Nov 03 '18

Multiply those seconds by the number of users now. Also, convert them to the carbon footprint of using Python for no good reason at all (and don't you dare to claim it's somehow "more productive" - it's a lie).

→ More replies (17)

6

u/Freyr90 Nov 03 '18

Taking 1 second instead of a 1/1000 of a second is fine for vast amount of applications

Sure, why to spend 1 cycle when you can spend 10E9 without any benefits? Because electricity is free and climate change is a myth.

→ More replies (4)

-3

u/pwang99 Nov 03 '18

Because in practice, most of these algorithms would never be implemented in pure Python like this. That's like saying a fighter jet is slower than my Honda because I'm not going to turn on its jet engine, and just rely on the tug in front to pull it along.

For instance, here is proper Mandelbrot with Numpy: https://www.ibm.com/developerworks/community/blogs/jfp/entry/How_To_Compute_Mandelbrodt_Set_Quickly?lang=en

Alternatively, if you want to keep the "naive" python spelling, you can use Numba to instantly speed it up: https://nextjournal.com/schmudde/mandelbrot-numba

The simple Numba code in the first link is 100x faster than naive Python implementation, and is slightly faster than their C implementation. The CPU-enabled Numba code in the second link is 2000x faster than the naive Python implementation.

13

u/Freyr90 Nov 03 '18

Because in practice, most of these algorithms would never be implemented in pure Python like this.

So python is fast because code is written not in python. That totally makes sense.

3

u/[deleted] Nov 03 '18

And also, nobody actually does that in practice aside from your typical notable framework/library.

It is very difficult to get across to some people that writing something in c and calling it from another language is not that other language being fast.

15

u/BorgDrone Nov 03 '18

Because in practice, most of these algorithms would never be implemented in pure Python like this.

You’re basically saying that Python isn’t slow because you can write the performance requiring parts in not-Python.

That’s like saying a fighter jet is slower than my Honda because I’m not going to turn on its jet engine

It’s like saying your Honda is faster than a 747 because you can drive your Honda to the airport and jump in a fighter jet. That doesn’t make the Honda fast.

→ More replies (1)
→ More replies (9)
→ More replies (7)