
Python's Caduceus Syndrome - rbanffy
https://vicki.substack.com/p/pythons-caduceus-syndrome
======
lioning
Python has always been sort of an odd language to me. Its syntax has always
had a certain strong appeal to a large number of people, but there have always
been these underlying performance issues that have been swept under the rug. I
was surprised when it started being adopted so much in AI research because of
the performance issues (I understand it's really C and other things doing the
performing, but at some point you have to do something other than call C,
otherwise you might as well just use C).

I do understand the appeal; I think its ergonomics are exemplary and worth
being studied by language designers as a success case (if not a perfect or
unique one).

Going forward, though, I'd like to see more adoption of languages like Nim,
Kotlin, or Julia, that have similar levels of expressiveness but are more
performant. The issues discussed in the article aren't really growing pains;
they've been there from the beginning.

~~~
roryrjb
I think there's a lot of worth using a high level language and integrating
with C. It depends on the interface of course, XS (Perl) isn't too user
friendly, but actually just using the Python C APIs is straightforward, rather
than say Cython for example. I think you get the best of both worlds, but
really it depends on what you are trying to achieve. If you want more type
safety, then OK maybe not but if you want to interface with some low level
components, or want to write a faster algorithm. Basically you can be more
focused and granular with the unsafe and more error prone C side and tame it
with a higher level language. Anyway, this is just my opinion but I've enjoyed
this area very much and it has worked well for me.

~~~
Rotareti
> I think there's a lot of worth using a high level language and integrating
> with C.

I agree.

Python is an awesome high level interface to low level libraries and
algorithms. As which it became even more appealing since you can write your
low level code in Rust and call it from Python via PyO3 [0].

[0]: [https://github.com/PyO3/pyo3](https://github.com/PyO3/pyo3)

------
guitarbill
> But the other problem, though, is that because Python is (was?) so simple
> and so ergonomic to use, new developers have been flocking to it, and
> adopting it for use in building large production systems that might have
> been better off written in different languages that are much less suited to
> exploring but more suited to long-term, stable systems.

That statement... first, there isn't any evidence this is true. For the
Instagram example, if you're that big, you're going to have scaling issues,
but it's an incredible position to be in. I've seen Java GC issues at large
scale. That's the price you pay for GC.

That is to say this is a feature, not a bug. CPU is cheap. Productivity is
hard. C code can be slow if written badly. Obviously Python isn't without it's
trade-offs, but to imply it isn't suited for long-term, stable projects is
incorrect.

It takes time for developers to learn a new language. Who's to say they
wouldn't have made similar mistakes in other languages?

Again, course there's a trade-off, and Python isn't without it's flaws. But to
pretend another language would have solved everything - development doesn't
work that way. And scaling issues are a sign of success. You might not have
made it that far with another language.

So pick wisely, and build stuff, and remember the choice isn't final.

~~~
ggregoire
The part you quoted is not about scalability.

~~~
gloflo
Would you mind being so kind as to explain what it is about then? Saying
something is wrong without saying why or how is just noise.

~~~
ggregoire
She's talking about Python being a dynamically-typed & interpreted language,
making it "simple and so ergonomic to use [for] new developers" and
"[suitable] to exploring", but "[less suitable] to long-term, stable systems".

It's not specific to Python. Big projects written in dynamically-typed
languages are hard to reason about and maintain. And the lack of compiler
makes it harder to catch typos, incorrect types, non-handled null/None values,
etc… before runtime.

~~~
guitarbill
> And the lack of compiler makes it harder to catch typos, incorrect types,
> non-handled null/None values, etc… before runtime.

linters exist for a reason. it isn't so clear-cut any more, either, with type
hints in python that can now be enforced, although honestly i haven't
experimented with that much, since i don't think it's necessary.

> Big projects written in dynamically-typed languages are hard to reason about
> and maintain.

let's not pretend statically-typed languages are always easier to reason
about. throw enough interfaces into a Java project or templates into a C++
project and they're also hard to reason with.

you may have had bad experiences with dynamically-typed stuff, or simply
prefer static typing, but these seem more opinions than facts.

and again, i'm happy to argue that it's hard to predict the future. many
projects benefit more from the increased velocity dynamically-typed languages
offer at the start (the exploration if you will), than trying to build a
system for millions of users from the start. that probably makes sense for
FAANG projects, but for most it's overkill. so the suitability towards "long-
term, stable systems" is half true. hindsight can be powerful, but can also be
misleading.

------
taneq
> Python became the second-most beloved programming language (behind Rust,
> which is the language people most love telling you they’re learning
> aspirationally.)

As an aspirational Rust-learner (well, I've read the first chapter of the
book) this is spot on. :P

