Bullshit. My experience of Python is that only a small subset of programs are actually IO bound.

https://github.com/hagezi/dns-blocklists/issues/11017

https://github.com/hagezi/dns-blocklists/issues/12026

Respectfully, your opinions are about 3 months out of date. Astra and Opus 5.5 are really a big step up, and most of the decisions they make are reasonable. They also ask you for decisions quite well.

And you don't really need a "spec". You need to describe in detail what you want, but the flow is more like "I want to make a customer forum. The only supported login email should be a magic email link. Write the server in Go using it's html templating. Keep the CSS simple and only use dependencies when it makes sense. Come up with a plan and let me review it."

Then you just review it, a few more rounds of testing, and boom, job done.

You don't really need to be a skilled programmer to do that.

Why would that slow it down exactly? Nothing really slow about GPU accelerated graphics these days?

Would love to hear the technical reasons. You need to have UI kits for GUIs. Responsive and accessible UI kits are hard. The web solved them a decade ago and made them easier to achieve than ever before. Why invent the wheel twice?

I/O is the slowest thing ever. The more I/O dependent your app is, the slower it will be. It is not easy to make a slow web UI with zero I/O. Very easy to make a slow UI with a native toolkit and high I/O usage. Network calls are I/O. Analytics are I/O. Most enterprise apps these days demand so much analytics they effectively have spyware on their own users to optimize and A/B test against.

I'd add that most of the time nobody actually measured anything. at work we inherit slow sites all the time and the first guess is always "the stack", then you profile it and it's one query running per item in a loop or something like that. I had the same with my own side project, was sure I needed a bigger server and after measuring the problem was somewhere else completely. measuring first is boring but it's cheaper than any rewrite I guess

anything that is functioning well enough gets you assigned the next ticket at work.

I've been vibecoding pyqt based python apps lately. The performance even one of the so called "slowest" languages can do is more than fine. Not using Electron, or actually optimizing matter more than the language itself, most of the time anyway.

Sure, yes, Rust has lots of quality libraries too. I'm thinking of doing the core in D and the GUI in Rust Slint. Plug-in protocol interface modules can be written in whatever, but Rust has some interesting libraries.

I agree that dependencies and package management is a real problem in programming nowadays, but it is not a problem unique to Rust. In fact, I struggle to name a single popular language nowadays that doesn't have the exact same problems.

It's not so much "But that’s not how you build stable software." It's more like "But that’s not how you build software [at all today]." Modern software is powered by loads of shared packages, that's just how all modern languages work. This is equally true for Rust and Python.

Rust still has the edge here btw. Rust libraries (crates) are often very high quality with very good documentation. The language again helps here a lot, by providing extensive tooling for automatic documentation generation. Documentation in other languages are is far less helpful or poorly written. This is also again something that helps an AI write better code (just as it helps humans write better code).

The packaging also helps elevate Rust to a high-level language, because you can build easily usable abstractions in packages that can be used in simple programs. All the complexity can be hidden away in a crate and suddenly Rust feels more like Python. I think that's actually a good thing from package managers.

Nah, software is slow because it runs a web engine for GUI.

But the reason people (re) write programs in Rust is because Rust as a language has a lot of guardrails that help make a program more stable, more correct. That reliability is the real reason for Rust.

Yeah, but then the Node-like atomic packaging runs contrary to optimization and security by shoving 500 MB of code in your cli-tool. And sure, the compiler optimizes 90% of it away. But that's not how you build stable software.

Right now everyone is asking their AI agents to rewrite programs in Rust or C or assembly. This is fun, but it’s not a serious attempt at optimization.

C or assembly seems pointless and only for performance. But the reason people (re) write programs in Rust is because Rust as a language has a lot of guardrails that help make a program more stable, more correct. That reliability is the real reason for Rust. The performance is just a cherry on top.

This is actually exactly what you want in a language for AI. This is anecdotal from my side, but in my experience, an AI writing Rust will write far less sloppy crap than an AI writing Python.

Most of the argument against Rust has historically been that prototyping is slow and the language is a bother to write because the compiler makes it hard. But this only holds if humans are the bottleneck for writing the code! Rust therefore has all of the benefits but basically none of the downsides when having an AI write it.

Except for python.

I once did some testing comparing very simple apps built with Tauri (using system webview) and native library and the difference in memory usage was not that big. I'm looking now at a simple PDF viewer in GTK and it's using 120MB. My app written in Tauri is using 150MB. In theory native apps will use less memory when you run a lot of them at the same time but if you check the size of native Linux app they are not that tiny. They still will easily use hundredths of MB of RAM. Simple, native todo app will easily use 150MB. Yes, badly written electron app will use way more than that but you have webview tools that are really good and not that heavy.

Yes and no. It's not usually the fault of the programming language.

But programming languages have a unique ability: The design of the language itself can and will instill bad or good habits into the code of oneself. These languages are designed pretty deliberately, so those habits are a direct consequence of the design of a language. In fact, Sean Goedecke's own C-to-Rust example makes this point implicitly: Cantrill's port got faster not because the redesign was really clever, but because Rust's borrow checker and standard library actively steered him toward a more cache friendly Binary tree. There are probably many more examples out there that had a real world impact.

There are no bad languages, every language has its place somewhere. But design decisions matter.

Noticeable speed? Sure. But I am so pissed if a fucking todo list app is a 100mb download and consumed 300mb memory when running, all because this fucker bundles and loads a whole browser engine to render itself.

I therefore do think tech stack matters as well.

I'd love that but it's difficult when it's not really my project and anything that is functioning well enough gets you assigned the next ticket at work.

What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?

While Python's start-up time is a lot slower than a corresponding compiled program, in most cases it's not slow enough to matter even if the process itself is short-lived:

$ hyperfine 'python3 -c "pass"'
Benchmark 1: python3 -c "pass" (412 runs)
                mean     ±       σ          min     …     max
  Wall Time      7.1 ms  ±     0.2 ms       6.7 ms  …     8.4 ms
  Memory         9.4 MiB ±     0.1 MiB      9.1 MiB …     9.5 MiB

If you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article's thesis

Software engineer and can confirm this is mostly the case. Adding a spinner or cute animation to placate users is way easier than solving fundamental issues. There are definitely teams out there that absolutely care about performance but mostly in large scale scenarios where an extra 10ms per record adds up to 3 extra hours to finish a batch.

I'd like you to name 1 that's multi-hundred MB.

Google is a bad example, historically the landing page has been interestingly optimised.

Lots of corporate websites are multi-hundred MB things though you are right.

Edit I take it back, the worst ones I checked have been redesigned

Choice of language is part of the design, but it's probably more "runtime" than the language itself as it could just be a spec with multiple implementations.

Ship in the minimum amount of time possible, by any means, to be first to market. And this means poor design and smooshing together all kind of fat general-purpose frameworks and libraries to get something out the door.

Sure, it's slow. Google's landing page is 4 MB for a small graphic, a text form, and some buttons. But what are you going to do? Not use it? They won. They don't have to fix shit.

And now with LLMs they can produce bloat faster than ever and pay even less attention to speed or quality.

"The goal was never quality software."

At that point just call the person messy and move on. They just want to flex their brain.

The thing is also that you can't separate a language from its ecosystem.

Because it is possible to write the fastest programs in C/C++ and Rust, folks that actually need the fastest performance will use these languages and will go around opening pull requests to fix performance problems in commonly-used libraries.

So, you do often end up with the most performant design anyways, just because the language itself is fast on paper.