upvote
20 years working on Python. Two things have driven its success.

First, it's easy to learn and reasonably powerful. You can make a lot of useful things really quickly, which was true even 15 years ago. It's only gotten easier since, and the ecosystem has continued to grow.

Second, ML latched onto it. That gave Python a lot of credibility for people coming through CS programs and into industry, especially as AI use cases were picking up momentum. Think Tensorflow starting 10-ish years ago, then Pytorch, and so on.

[opinion time] Unfortunately, ML has contributed to disaster. The quality of software engineering in ML applications lags badly behind that in other segments, and there's where most Python development is happening now. The feedback loop of training Bad Python into LLMs is only making it worse. The skill floor was dropping, and now it's practically zero.

It also wasn't helped much by language design decisions. Gradual typing was a huge mistake. It would have been much better to go the Typescript route and define a superset of the language that compiles to native Python. The grafted-in typing features that rely on runtime behavior and never got an actual spec for a type system haven't helped.

reply
It's incredibly easy for new engineers to pick up. On the spectrum between "features easy for beginners but nightmarish for experienced engineers" and "features complex for beginners but great for experienced engineers" it always makes the tradeoff for the former.
reply
Yes, just like Go, it's a junior developer onboarding language, that somehow managed to overstay its welcome.
reply
Go is awesome and has great ecosystem. I think if you want to just deliver Go is one of the best language out there. Of course as long as the project makes sense(I.e no client side/GUI stuff, there it gets messy)
reply
Some people live to shit on Go since you can't really do "crazy cool shit" as someone I knew put it.

Apparently you can't be a senior dev unless you "just here to deliver"

reply
C++ is the "just here to deliver" language.

It can do everything, it's a nightmare to write correctly and is so full of warts that really only a mother could love it.

Go is "elegant" and properly designed, which leads to fundamental unassailable limitations; like its GUI story or writing a backend for other languages (cgo is so slow and -build-mode=c-shared is a hog).

No operator overloading makes it difficult for numerical/scientific work - Python is stronger here.

"just get stuff done" is your crappy dump truck which is welded together out of spare bits and is barely hanging on, this is how I feel about C++.

Go is a lot more elegant and well designed, but it requires "smooth roads" (An OS and Runtime) and goes fast... it's more like a Dodge Hellcat..

EDIT: if we consider speed a function of development time rather than runtime, of course at runtime C++ can be as fast as it gets.

reply
The dump truck that is C++ definitely goes just as fast if not faster than that Hellcat, though.

To me it seems more like C++ is the metal shop's old school 3-axis mill: effective and dangerous. Can do almost anything, including easily maim you unless you're continually vigilant.

Go seems like a CNC machine: just as effective, much less dangerous because it relies on digital safeguards and embedded controllers. You need to go to extreme lengths to make it do something it wasn't designed to do.

Python seems like lego. Shit simple to build things with, lets you start building immediately, fantastic for prototypes, but finished product is still just press-fit plastic bricks

reply
Well, if we consider speed of development rather than speed of the runtime, the analogy holds better.
reply
If Go is a junior developer onboarding language, then I proclaim myself a perpetual onboarding junior.
reply
And that's ok.
reply
https://en.wikipedia.org/wiki/Worse_is_better

We've known for a very long time that shitty things can become very successful in this field and why.

reply
Probably the batteries included Standard Library.

Cross platform interpreter.

NumPy and SciPy really set the stage.

reply
It's definitely a better language than Matlab, and Numpy made it actually fast for that purpose. AI research really took advantage of that even before LLMs hit the scene.
reply
I'm not the OP, but it seemed to me that major teaching institutions settled on Python as a pedagogic language after previously having rallied around Java for same, and various other languages before that.
reply
BASIC rebooted. Right at the right time too, BASIC was never going to thrive in the days of the internet.

I'll give Python one thing though, it is by far the most elegant way to glue together a large number of otherwise incompatible C libraries.

reply
They provide binaries for almost every open source library for every popular platform. If you need something, whatever it is, python was and is probably the easiest way to install and use it.
reply
well, for one, my boss can use it and kinda understand it, so it must be dead simple
reply
Definitely ease of use...
reply
It was the first language that actually felt ready-to-use, available for free-as-in-speech. Batteries included, robust online development community, sensible featureset, main libs that were designed bottom-up instead of top-down. I remember learning Java 1.2 or 1.4 after learning Python and it felt like a huge regression. Swing was a joke compared to TkInter (which was weak compared to proper GUI editors like VB but at least made nice scalable native-feeling GUIs and had a sensible API) and the standard collections were miserable without generics.

But Python peaked like 20 years ago. The later features were too ugly, and it was too slow to fill the obvious gaps in the language.

reply
Marketing in academia, decent C-API that led to use in scientific Python.

The language is a disaster since it deviated from its original purpose. The community is ruled by insane, mediocre narcissists who drove away all reasonable people.

reply
- Math + visualization libraries (which ironically have to break out of Python to do their job)

- Reasonable ergonomics for describing data flows, as long as you never run the code, which you often don't care about if you're a mathematician

- Adoption by people who optimize pumping citations, not reproducible results -- non-working code is a feature when you're trying to BS

reply