ESR "Waning of Python" post

[Neil Cerutti]

On 2018-10-10, Paul Rubin <no.email at nospam.invalid> wrote:
> Neil Cerutti <neilc at norwich.edu> writes:
>> As Stephen said, it's sort of silly not to be aware of those
>> issues going in.
>
> If you're saying ESR messed up by using Python in the first
> place for that program, that's not a great advert for Python
> either.

I meant Stefan, by the way. Sorry, Stefan.

I actually do kind of think that, but ESR is a much better
and more experienced programmer than me and a whole lot more
knowledgable about the resource usage his program requires. So take
that part of my opinion with a grain of salt, if you didn't
already have one. Somebody in his comments section was
incredulous that his software could possible bog down with such a
"small" code base.

It concerning to me that he glossed over his decision process
when abandoning the idea of offloading the part of the work
that's getting stuck in one core to a suitable engine. To me,
that has to be easier than rewriting from scratch in a new
language, but we don't have enough information to judge.

One issue I didn't address was his criticism of deploying Python
programs, thanks to library location issues. As I understand it,
Go's library system has it own huge bloc of complainants regaring
versioning hell, with a solution that's vaporware. Python's
library issues can be addressed with virtualenv or py2exe type
tools.

I also disliked how he lumped current problems with Python in
together with "ancient" history.

It was definitely a good enough article for a blog post but would
need rewriting for a journal or a magazine.

>>> the GIL (15/16th of his CPUs are unused..)
>> Channels are a big selling point of Go, no argument there.
>
> The unused CPUs are not about channels (Python has Queue which
> is similar).  They're about the GIL, which is an implementation
> artifact of CPython that's hard to eliminate without modifying
> CPython's C API.  ESR didn't say this explicitly but it came to
> mind when reading his post: It's weird that Python's designers
> were willing to mess up the user language in the 2-to-3
> transition but felt that the C API had to be kept sarcosanct.
> Huge opportunities were blown at multiple levels.

OK. I assumed he planned to parallelize computations in Go by
offloading to concurrent channels--I guess I don't understand why
he can't do that in Python.

>> You must carefully use a different set of functions and
>> operators to regard the bytes as unicode code-points. So Go
>> makes it easy to do things incorrectly
>
> That seems like a deficiency in Go's type system rather than in
> the UTF8 representation per se.  

I agree. Python could've used UTF8 as the internal representation
as well, but there's no need to go back into that jmxfauth horror
show.

>> On the other hand, I only used Go until it made me feel really
>> annoyed
>
> Yeah I haven't used Go a whole lot either, for similar and
> other reasons.  ESR's criticisms of Python are imho mostly
> valid but I don't think Go is the answer.  It's too low level,
> showing its roots in C. Haskell and Ocaml have their own
> deficiencies but I think they are closer to the right
> direction.  I.e. I'd like something with a serious type system
> and a more functional-programming flavor than either Go or
> Python currently have.

A big reason he chose Go in the article is that he regarded it as
more simple to translate Python->Go than those other options.
It's hard to believe that good Python code would make could Go
code, but at least its a starting point. I imagine that if I
stuck with Go long enough I'd develop a new coding style that
didn't inolve creating useful data types. I've used C++ and
Python so long I just don't think that way.

-- 
Neil Cerutti