ESR "Waning of Python" post

[Chris Angelico]

On Thu, Oct 11, 2018 at 6:12 PM Ben Finney <ben+python at benfinney.id.au> wrote:
>
> Chris Angelico <rosuav at gmail.com> writes:
>
> > In actual fact, it's not a problem per-se. It's a design choice, and
> > every alternative choice tried so far has even worse problems. THAT is
> > why we still have it.
>
> That reads to me like a rejection of the point made in the blog post:
> that the GIL prevents Python from taking proper advantage of multi-core
> machines.
>
> In other words: Yes, it's a design decision, but that design decision
> causes the problems described.
>
> Is it your position that the described behaviour is not a problem? Do
> you hold that position because you think multi-core machines are not a
> sector that Python needs to be good at? Or that the described behaviour
> doesn't occur? Or something else?

Multi-core machines are important, but even on multi-core machines,
most Python processes don't need more than one. AFAIK, every single
alternative to the GIL has resulted in a measurable performance
penalty when running on a single core. (Happy to be proven wrong if
that's not the case.) So if you want better multi-core performance,
you MUST accept a single-core penalty.

Frankly, I don't see a problem with saying "Python doesn't make it
easy to write code that floods eight cores with work, therefore I will
choose a different language for this job". It doesn't mean Python is a
bad language. It just means that Python is not the one and only
language that all code must forever be written in.

There's a huge difference between deciding on using some different
language for a project, and going on a massive ire-filled rant.

ChrisA