I am about to hit two decades, with lot of pauses. I now use it professionally, but it was still my favorite language a decade ago (then I fell in love with Common Lisp and lately Haskell).

I think you need to look at it historically. Against other languages circa 2000, Python was a huge win. Easy to write (compared to C), consistent (compared to PHP), minimalist (compared to Perl), multi-paradigm and playing well with C (compared to Java), with a great standard library (compared to Lisp).

Today, the landscape is very different. Lot of languages took hints from and got influenced by Python (including Racket I am sure). Functional languages have taken off. Type inference is a standard feature.

History is always changing. There is some potential for a next Python, but we don't know what it will look like yet. I suspect it will be functional, but I don't think it will be in the Lisp family. It probably won't happen until after Rust and/or Julia get lot more adopted. Anyway, just like C, Python will be with us for decades to come, for better or worse.

Two decade Perl programmer who's been using a bunch of Python recently. I don't hate it, but I've not been getting any particularly complicated use-cases. I do miss Moose a lot, and I miss Bread::Board and I miss DBIx::Class, which SQLAlchemy does not make up for. The weird scoping didn't take too long to get right, although string interpolation still takes me too much thinking about.

What I am missing from Perl is library documentation and MetaCPAN. It seems that the go-to solution is that you're meant to create some kind of damn mini-site for any even vaguely complicated project you do using Sphinx, which seems bizarro land. Also the _requests_ documentation looks like it was written by Wes Anderson and wtf I hate it. Also I hate that all libraries have cute rather than descriptive names; yes there's some of that in Perl, but it feels like less. Bah humbug. Other than that it's fine.

This resonates with me. I miss working with Perl greatly (my current employer forbids me to write anything on it), and having to deal with Python instead makes me miss it even more.

I have nightmares of dealing with Python packaging... I finally gave up and just started using PyInstaller to ship binary blobs to people.

That doesn’t even work in all situations. What if the system requires development packages? What if it’s a different OS or architecture? Packaging is a nightmare.

What if you are on Linux and your binary requires a slightly newer version of glibc for some reason etc.

Static, portable binaries on Linux are hard.

That's why Docker is a good idea for packaging things up. You basically get exactly the combination of binaries, libraries, etc. you intend to run. Probably not a bad idea to use it for development as well. Or at least something like pyenv or whatever it is called these days.

Docker saves some pain, but introduces others.

You have a container that will run anywhere, but it has a bigger attack surface and needs updates.

I also would disagree that it's easier than using virtual environments for development, and only for packaging in some narrow use cases.

They aren't too bad IMO. However, you need to set up a build environment/VM with your choice of your earliest-supported Linux+glibc. Build on old, run on new works well.

Linux backwards-compatibility is pretty good, in that a static binary should run just fine on newer systems. I've had far worse experiences with OpenBSD, where a build on an older version of the OS would never seem to run on a newer system.

> Static, portable binaries on Linux are hard.

That’s why it can’t be an afterthought. It must be baked into the language as part of the design (golang)

Why would your binary require glibc if it’s statically linked?

In order to evaluate the relevance of this comment we need to know what else you have been using for 10+ years that you like or at least think is ok.

Thanks for sharing, it certainly makes me feel better about my troubles with accepting python. And "the happy path" might be a state you spend a /minority/ of your time in, depending on project. So first you spend 10% of your time to fix the 80% of easy features, but the tricky stuff can be more awful than it should be.

And packages. I thought I was just stupid, but thankfully there was more to it.

Quite welcome. I think you are on to something. The thought that comes to mind is "Python is a great language if you want to do exactly what everyone else is doing." Most of the love has nothing to do with the language itself, but rather the fact that people can make use of some library that a big engineering effort produced in another language entirely. Thus they conflate Python with access to that functionality. All of my code bases are pure python (in part because of the packaging issues), so maybe that is the difference, people aren't really Python users, they are numpy, pandas, django, sqlalchemy, or requests users. It would be interesting to compare the view of library maintainers vs just 'users.'

Agreed this is it, when people think Python, they think all the default use cases covered by the many libraries that let you "get things done" quickly with syntactic sugar. Alas, there's more to our work than the first few miles of getting things done. There's that scaling part too and python loses it there: no good threading, no enforced typing, bizarre scoping, half baked module system,etc