Ask HN: Why hasn't x86 caught up with Apple M series?
433 points by stephenheron 3d ago 616 comments
Ask HN: Best codebases to study to learn software design?
103 points by pixelworm 5d ago 90 comments
Python: The Documentary [video]
206 chmaynard 66 8/28/2025, 11:27:27 PM youtube.com ↗
Education system in Lithuania had turbo pascal in high-school and mostly java and c/c++ in university and while I really loved pascal in high-school the switch to Java was so jarring - "people really enjoy this? maybe I should do something else" is what I thought during my first year of college. Luckily Python started to become really big online and was such a joy to use and be a part of the community it really cleared up this notion that programming sucks. To this day this experience has stuck to me when approaching any new activity - is there a Python here somewhere that would unsuck this?
I'm quite a polyglot these days and will write Java if needed but Python is still my daily driver and it just feels right. If I'm doing something 10 hours a day, I'd like to feel good while doing it and that's exactly what Python delivers.
> I do show up, but not “live”. For various reasons (mostly related to declining health), I didn’t actively participate. I gave the director (Ida Bechtle) a pile of source material at the start, and that was the last of my involvement. She spliced in some recycled video of an interview I did with the PyPy folks at a PyCon some years ago, but I’m there mostly so people could recite my so-called “Zen of Python”, which an actual historian (Joseph Dragovich) assured me is “the most famous values statement for any programming language community”. https://discuss.python.org/t/python-documentary-going-live-t...
how did i do on my python exam? 5.6 is also a pass!
This is where the guru whispers (3 times) to you the seed letters which one has to imbibe over decades of sadhana by lacs of repetition
this looks similar
#rememberThis
I’m happy that python basically took over the role once filled by matlab, and I’m happy that it became the leader in AI dev instead of something worse (probably Java if gpt2 had hit 5-10 years earlier).
But you’re right. It’s not fun anymore. It feels more like a pseudolanguage for expressing tensors now, because of the influx.
I’m exaggerating only in feigned outrage. In my actions, I’ve been coding in rust, go, and zig ever since ChatGPT came out.
I think that moment made me value python less. When I think about why, it’s because python became less challenging, and the problem space shrank.
It’s been fun to go back to low-level and remember how computers actually work.
mypy --strict in CI & don't let dict[str, Any] pass review if the keys are constants, insist on a dataclass or at least a TypedDict.
On the other hand duck typing is largely a joke. Letting functions take anything as an argument and then just assuming it's a duck with the methods you want is no way to write a robust system. Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project. The GIL will have you jumping through hoops to work around.
As an offline data exploration and research tool limited to an individual or a small team, or for writing small utilities, I totally get it. For anything mission critical I'd much rather be in something like Java or C# where the typing situation is stronger, the performance is going to be much better, I have better access to threads if I need them, the reasons for dropping into native code are fewer, and the cross platform support works more seamlessly without additional layers like Docker.
Everyone keeps harping on type safety, but it just doesn't play out in reality. Linux Kernel is incredibly robust, has never been a broken mess, and has basically no type enforcement, as you can cast pointers into other stuff.
In general, all typing does is move error checking into the compiler/preprocessor instead of testing. And time spent on designing and writing type safe code is almost equivalent to time spent writing tests that serve as an end-to-end contract.
There is a reason why NodeJS was the most used language before all the AI stuff came with Python.
>Performance wise you're boxed into a corner. The slow runtime will have you writing native code in another language, complicating your project.
Most of these performance arguments are similar to arguging that your commuter car needs to be a track spec Ferrari in terms of performance, by people that have very little experience with cars.
Plenty of fast/performant stuff runs on Python. PyPy is a thing also. So is launching small compiled executables like a process, that takes literally one line of code in Python.
>The GIL will have you jumping through hoops to work around.
This is just laughable. Clearly you have extremely little experience with Python.
Yes, as a result of strong development practices, a high skill floor, and where work is done by a small number of people knowledgable in the domain. These things are not mutually exclusive with type checking.
> In general, all typing does is move error checking into the compiler/preprocessor instead of testing
Which is an enormously powerful thing. Having those things be required by tests requires that the test exists for all the cases, which turns your tests into things that not only have to test behaviour but are also simultaneously responsible for checking types.
Compile-time type checking can essentially eliminate all need for type-based tests and is able to do it automatically for any code that exists, whereas this has to be opted in when using tests to check types.
You also don't get the benefit of compile-time tests automatically checking use cases for the types you don't support (which is likely more than the ones you do), whereas leaving this to test-time is practically impossible and you can only test the valid path. I've never seen a codebase that checks the negative paths for the hundreds-upon-thousands of types that aren't supported.
None of this is to say I'm against tests as end-to-end contracts, but moving type checking to compile time gives you a lot of extra kinds of assertions for free that you likely don't get from having tests to check types.
> There is a reason why NodeJS was the most used language
And the reason was? AFAIK Node came along as a runtime option for using a familiar language outside of the browser. Coupled with a single-threaded event-driven concurrency model out of the box it was an enormously practical/easy choice from the perspectives of both language familiarity for developers and fpr the workloads it was given.
Back then the whole OO crowd was with Java though.
Python's Moat was beginner friendliness to write simple scripts, which at the time- Perl was more like a thermonuclear scripting language. Most people who never wanted to graduate to that advanced stage of writing mega million lines of Perl code over a week(which was literally the use of Perl then), realised they needed some thing simpler, easier to learn, and maintain for smaller scripts- Kind of moved to Python.
But then of course simplicity only takes you that far, and its logically impossible to have a simple clean interface to problems that require several variables tweaked. Python had to evolve and is now having the same bloat and complications that plague any other language.
Having said that, I would still use Java if I had to start a backend project.
In fact, many books that the OOP haters attribute to Java, predate its existence.
With no real recent experience (I fell deep down the hole into C/kernel etc), I wouldn't have any authority to judge how it's adapted to time. But the most common complaint I've observed at companies of all size and sophistication is "the deployment story is a disaster". But it also seems like uv allows people to do all the "I want this specific version of such and such and I don't want $OS to know about any of this" well?
Re math/ai it's an interesting comment because a language is one part the syntax/stuff you receive, and one part the community that tells you to do things a certain way. I'd guess that Python has become such a big tent it is a little hard to enforce norms that other languages seem to have. This somewhat reminds me of Bjarne Stroustrup discussing scaling/evolving a language.
Packaging has been a nightmare. PyPI has had its challenges. Dependency management is vastly improved thanks to uv - recently, and with a graveyard of tools in its wake.
The modern Python script feels more like loosely combining a temperamental set of today’s latest library apis, and then dealing with the fallout. Sometimes parallels the Node experience.
I think an actual Python project - using only something remotely modern like 3.2+ standard library and maybe requests - is probably just as clean, resilient, and reliable as it ever was.
A lot of these things are and/or have been improving tremendously. But think to your point the language (or really the ecosystem) is scaling and evolving a ton and there’s growing pains.
Libraries can overtake aspects of a language for better and worse. Ruby seemed really tied to Rails and that was great for it as an example.
It feels like something broke around 2015-ish. Going back, you could make a whole app and gui with Basic. You could make whole websites simply with HTML+PHP, sometimes using nothing but Notepad. You could make portable apps in Java with no libraries - even Swing or whatever was built in.
Now…? Electron, a few languages, a few frameworks, and a few dozen libraries. Just to start.
Bizzare.
— Ronnie Coleman
Best of all with this approach, is that what is in the standard library suffices, no need to mess up with venvs, PYTHONPATH, or whatever is the current trend.
I love reading comments like this because it just makes me feel good about my job security.
You are aware that things like Youtube and Uber back ends all run on Python, right?
You are aware that things like your bank and insurance all run on COBOL, right?
But it seemed like a lot of people overlooked why it was loved. Most of us weren't wishing that our 2k+ line projects were all written in it.
Those little 20-500 line scripts were just so much more fun in Python than anything else though, and it showed up in survey after survey.
It's notable that you've written this in the past tense. These kinds of scripts don't seem to be a focus for Python any more.
In fact, I recently heard as justification for a new Python feature: "it helps us with our 100-million-line Python codebase". The language has become extremely complex as it prioritizes the needs of a few teams writing millions of lines over millions of developers each writing relatively few lines.
The reason is that the design team are all working on these large codebases and, understandably, mostly focused on what makes their own lives easier. I was hopeful that in the transition from a BDFL-based governance system to a Steering Council, we would see a larger variety of experience and opinions designing the language. Instead, I don't think there has ever been a single scientist, finance worker etc on the Steering Council - it's always software developers, almost always employees of large software companies.
The other obvious example of complexity is pattern matching. The feature is very complex, especially how it breaks established rules of the language. It also required fundamental changes to the interpreter to accommodate it: a rewrite of the parser from simple LL(1) to PEG.
Then came Python 3 and it just never felt the same. PyQT projects faltered. Deps split. Strings broke.
However I started using Nim a few years back which has given me that Python 2 feeling – except with static types, better overall language design, meta-programming, and performance!
And except tooling, ecosystem, documentation and practical real-world application.
True the LSP is pretty bad, but Cursor makes up for a lot of that for me. Atlas dependency manager is great. Valgrind and TSan work perfectly. Gdb sorta works now. LLMS solve the docs issue.
The ecosystem is smaller, but I've been able to use it to successfully create tools for an IoT project with Nim running on an embedded esp32, a multi-threaded api server on linux processing images, and a web SPA with Karax in a couple of weeks of programming work. Oh and calling into Python for some datascience.
But this seems like an apples to oranges comparison. Yes, of course a few scripts are very different than "something largeish" written in Python
No comments yet
He was patient, informative and above all extremely thoughtful in his stackoverflow responses. He was also very generous with his talks, all of which added to the rich ecosystem Python had back in the day.
Python has always suffered from the overrepresentation of talkers, and the recent draconian "leadership" that consists of the worst people have driven most developers away apart from some failing corporate projects.
This video tries to revive the spirit that existed in 2000 before many of those developers sold out Python to corporations and turned utterly evil.
Processors and memory have gotten cheap enough were development speed matters more than compute cost.
I was big into Python for over a decade of my career. I spoke at Pycon US and Canada. Wrote a few libraries. It had a great community.
I’ll always be grateful for it.
Reading all the complaints about it recently is a bit surreal. Newer developers can't program without IDEs and "type systems." Packaging was kind of a mess, but feel like uv solved it. Neither issue really affected me, I used setup.py almost exclusively until moving to uv maybe six months ago.
It was always a glue/prototyping language—if you're using it for kernel drivers or multi-threaded Fibonacci servers or worse, that bad decision is yours (or that of your boss). ;-)
Interview: Guido van Rossum Revisits Python’s Life in a New Documentary
https://thenewstack.io/guido-van-rossum-revisits-pythons-lif...
(https://news.ycombinator.com/item?id=45055272)
(https://news.ycombinator.com/item?id=45056377 https://news.ycombinator.com/item?id=45050548)
https://thenewstack.io/guido-van-rossum-revisits-pythons-lif...
The more I use python, the more I hate it. For the inconsistencies and the short comings and the stuff it glosses over and absurdities like having the default queue be thread safe (sacrificing performance). My personal opinion is it is a garbage language.
Why is this absurd? What are you writing where you need to scrape this sort of performance, but are perfectly fine with the overhead of interpreting bytecode at runtime, heap-allocating objects to represent floating-point numbers, not having homogeneous-type arrays that can store their elements contiguously in memory but which must indirect them, etc. etc. etc.?
Alternately, what world are you living in where everything a program does is CPU-bound and must be done efficiently? In this world, what led you to examine or try Python in the first place?
Debugger >> language -- next most popular language manifesto slogan (i hope).
Citation needed
https://survey.stackoverflow.co/2025/technology/#admired-and...