Comment by yosefk 3 days ago
The reasons for all this stuff having been developed in Python also make Python interesting right now, all by themselves. It did not happen by accident; this stuff was developed fairly recently and there was no shortage of mature languages to choose from.
Python has many issues that are quite clear when you operate at some kind of scale and need proper multiprocessing/multithreading support. And its not just the GIL, you get very unexpected behaviors when dealing with exit handlers and signal handlers in edge cases. Having seen what other languages look like it just doesn’t feel like a language that was designed well for running at scale.
The tooling has markedly improved though. Things like typing and compile time checks, great. But its also funny to me that some of the fastest tools for python are being built in rust (eg uv).
I’ve always found Python to be sort of loved on HN. Not by everyone or course but I guess it depends on each of our experiences on here. I’m usually rather surprised when I meet people who genuinely dislike Python, because that seems like such an odd occurrence. Even if people don’t “love” the language most people seem to have had rather fond experiences or memories of it. Usually criticism comes down to its inefficiencies, but those aren’t exactly unreasonable critiques.
As I said it’s anecdotal, but in my experience Python gets a lot of love compared to something like Java or C#. Both of which are often met with real harshness. Hell I’ve ranted unseemly about C# myself.
My only big critism is the CPython folks resistance to any kind of performance improvements, and the way PyPy efforts have been largely ignored, making Python the last major dynamic language to finally start caring about performance and having a JIT in the box.
Finally thanks to data science, and people getting fed up with always writing bindings, this is changing, and Python can join Common Lisp, Scheme, Smalltalk, SELF, JavaScript, Ruby, Lua, Dylan, Julia, BASIC club.
To be fair, Ruby YJIT can still somehow be slower than Python 3.11+ at times. Lua JIT is a bit of a separate effort and the ones that truly try the hardest here are Julia (which is not necessarily interpreted, it's really difficult to call it a pure scripting language at this point) and JavaScript engine implementations. I can see pretty good numbers for SBCL on BenchmarksGame too.
I mean, even on HN, I'd say if there's derision, it's mostly one uttered with a yawn rather than genuine hate. And that's almost justified; while I spend a lot of my time with lots of different languages (I can't think of a single one I outright hate btw), Python is the one that pays for my things and... Well, there's not much drama there is there (now that we're lost 2->3 anyway)? It's a glue language that's easy to learn, but offers tons of depth should you want it. My primary annoyance at Python used to be the typing, but type annotations have made this less of an issue. It's a nice language and you can do almost everything with it. It's a bit boring, but I guess that's a good thing.
As a former Perl hacker who started using Python in 2005, I saw Python ride several waves. (Numerical computation, data science, deep learning)
Perl was the leading tool for scripting and text parsing. Python didn’t really supplant it for a long time — until people started writing more complicated scripts that had to be maintained. Perl reads like line noise after 6 months whereas I can look at Python code from 20 years ago, prettify it with black, and understand it.
Python got picked up by the scientific computing community, which gave it some its earliest libraries like numpy, f2py, scipy. Some of us who were on MATLAB moved over.
Then data science happened. Pandas built off the scientific computation foundations and eventually libraries like scikit and matplotlib (mimicking matlab’s plotting) came along.
Then tensorflow came along and built on the foundation of numerical libraries. PyTorch followed.
Other systems like Django came and made python popular for building database backed websites.
Suddenly there was momentum and today almost all numerical software have a python API — this includes proprietary stuff like CPLEX and what have you.
Python was the glue language that had the lowest barrier of entry. For instance, Spark was written in Scala and has a performant Scala API but everyone uses PySpark because it’s much more accessible, despite the interop cost.
The counterfactual to all this was Ruby. It had much nicer syntax than Python but when I tried to use it in grad school I was quickly stymied by the lack of numerical libraries. Ruby never found a niche outside of Rails and config management.
Essentially Python — like Nvidia today — bet on linear algebra (and more broadly on data processing) and won.
I get why there’s hate for Python — it’s not a perfect language. Yet those of us pragmatists who use it understand the trade offs. You trade off on the metal performance for programmer performance. You trade off packaging difficulties for something that works. You trade off an imperfect syntax for getting things done.
I could have used Ruby — a much more beautiful lanaguage — in grad school and worked around its lacks, but I would have not graduated on time. Python was pragmatic choice for me and continues to be one for me today (outside of situations requiring raw performance)
I agree with you, and I'll put it slightly stronger. Ruby is a better language than Python in every way except the very most important two:
- Imports in Ruby seriously suck compared to Python. Everything requires into a global scope and an ecosystem like bundler which encourages centralizing all imports for your entire codebase into one file.
- Python has docstrings encouraging in code documentation.
Add common ecosystem things like the Ruby community encouraging generated methods, magical "do what I mean" parameters, and REPL poke-driven development, and this leads to the effect that Python codebases are almost always well documented and easy to understand. You can tell where every symbol comes from, and you can usually find a documentation entry for every single method. It's not uncommon for a Ruby library, even a popular one, to be documented solely through a scattering of sparsely-explained examples with literally no real API documentation. Inheriting a long-lived Ruby project can be a serious ordeal just to discover where all the code that's running is running, why it's running, where things are preloaded into a builtin class, and with Rails and Railties, a Gem can auto insert behavior and Middleware just by existing, without ever being explicitly mentioned in any code or configs other than the Gemfile. It's an absolute headache.
My dream language would be Ruby with Python-style imports and docstrings.
I think your comment needs to mention that Python has syntax for type annotations and two mature type checkers (mypy and pyright) with more under development. Python is thus very much part of the modern statically typed languages scene (moreso than Go) whereas Ruby isn't at all. Many people wouldn't touch Python today if it weren't for this.
> Python is thus very much part of the modern statically typed languages scene (moreso than Go)
Python’s type system is substantially more complex than Go’s - it’s probably more complete, but given it’s optional nature, less sound.
In “modern” type systems, is completeness considered more important than soundness? The success of TypeScript suggests it is.
> two mature type checkers
I’ve never quite understood how this works. Surely a type system is absolutely fundamental to a language - how can you have multiple incompatible ones?
Do you need to choose a particular type checker for each project? Are you limited to only using third-party libraries that use the same type checker?
Hard agree on the global Ruby import issues. I remember inspecting large custom Rails or Capistrano codebases in pry and having thousands of names imported. That and monkey patching had me wishing for Python with imports only having module scope and being a lot more explicit.
It's a shame Python has a strong anti-FP stance with crippled lambdas. And an OO system that looks like it has been bolted in, compared to Ruby which is essentially a Smalltalk with Perl-like syntax and some Lisp influence.
These two issues would have been quite easy to fix and would have led to a completely different development experience. Python had a good implementation with a nice C FFI (CPython) right from the beginning, whereas Ruby MRI had lots of efficiency issues with long-running computations. IMHO this is one of the reasons why Python won. Building a numerics stack on top of MRI did not look very promising.
> an OO system that looks like it has been bolted in, compared to Ruby
I think the two languages just have different design philosophies. In Python, functions are fundamental and classes are built on top of them. In Ruby, objects are fundamental and functions (i.e. Procs etc) are themselves objects.
You could just as well claim that in Ruby, functions look like they have been bolted in. For example, you can’t call a Proc itself but need to call one of its methods.
Pragmatic use of $LANGUAGE is a telltale sign of the wizened programmer; one who understands the use-case and solution set well enough to know when the tool fits.
I wrote Ruby when I got started because it was the most accessible and the Rails learning content was top notch. Now I use python when I need more than a few `bash` pipes to accomplish anything, but if I were to solve a capital-P Problem, of course the tool often chooses the project after constraints.
As someone that did the Perl to Python transition back in 2003, for UNIX scripting tasks, the way to do OOP with packages and blessed references was clunky, and having to always go back to the manuals for some clever programming tricks from team mates was tiresome, while Python provided something nicer, and I wasn't really into the sed/awk like features in Perl anyway.
However due to being a interpreted scripting language I never bothered to use Python for anything beyond OS scripting.
Using Python as C and C++ REPL of sorts has been common in academia since it took the scripting crown away from Perl and Tcl, which were used during the late 90's.
Example see the Bioinformatics papers from that period, and the Perl tooling used alongside the research.
Already in 2003 CERN was using Python on some of their build infrastructure (see CMT), Grid Computing scripting efforts, and we had Python trainings available to us.
Now there is a difference between a REPL of sorts, scripting OS tasks, and going full blown applications with a pure interpreter.
The people disliking the language are very vocal about it, but there is a huge amount of silent people that loves it and an even bigger amount that just like it as much as alternatives. It's mainstream now, not trending like 10 years ago, so there is no hype about it anymore. We just use it to do stuff.
Add to that the existing excellent ecosystem, the strong culture of scientific stacks and a very good story for providing c-extentions (actually the best one in all scripting languages because of things like cibuildwheel).
It's only in small tech bubbles like HN that devs find it surprising.