331
Software is slow because of bad design, not slow languages
(www.seangoedecke.com)
Too many abstraction layers
Is slow because of both. Using bad languages is one form of bad design itself, in fact.
Both matter...
What if the language has a bad design?
The title itself is provably wrong. Take the Matrix spec / protocol, install Synapse (written in Python) and watch your 16GB ram, 4 cors shit itself live under 0 load; or run tuwunel (written in Rust) and watch it using 100MB of RAM and a single core while handling a hundred users (Dendrite written in go was also great but it's incomplete). Same for some Mastodon implementations, even Elixir wasn't great and I was disappointed.
Now if you are building some ETL or a thin API wrapper, where the bottleneck is somewhere else like a DB or another API, then yes, don't bother, Python would do.
I don't think you're making the kind of argument you intended to make. Those are two different programs with two different development teams behind them. The design behind them (the literal thing the article is talking about) are likely completely different from each other. Comparing the languages based on two different implementations of the same spec is a bit more than disingenuous. If you want to actually compare you need to recreate the same implementation as closely as feasible. Something like this https://youtu.be/WB7v-ezqcJM
Comparing the languages based on two different implementations of the same spec
I don't think you realize how ridiculous this reads
I hate these kinds of comments that have no other purpose than to sling shit and start arguments.
Since this is a programming community (and giving you the benefit of the doubt, I assume you're not a vibe coder), you know your argument is nonsense. Writing something in Python doesn't automatically make it slow or use a lot of RAM or whatever. Synapse is shitty because Synapse is shitty. You can write slow and inefficient software in any language, and it feels really tedious to type this out because it's obvious and common sense.
You can write slow and inefficient software in any language
Yes, but you can't write snappy fast software in any language, high level languages like python, lua and php carry alot of overhead from the get go, because of dynamic typing, heavy abstractions, and heavy garbage collectors.
Your entire comment adds nothing, like 0 value. I provided two counter examples of verifiable, publicly available, familiar to tech people and programmers projects people can inspect now. Your comment doesn't even bother to bring something real, an LLM could put together a better counter argument by actually inspecting the github repos.
Synapse is shitty
I get the feeling you are wasting everyone's time and you have no idea what are you talking about. Show us your cooler projects?
Optimising too early is the root of all evil or something like that
Has everyone forgotten the art of creating or using performance profiling tools
I was in a meeting with a senior software engineer, who makes a shit ton more than me. While sharing my screen he saw flame graph I had for one program I was working on. They asked "what is that?", I was taken back, and said it's for looking at which functions are taking more time. Then I was asked "where did you find it?" I was shell shocked, didn't know how to answer that. Similar things have happened before where I taught them certain things, and they go "great find", like dude, I didn't find it just now. That's basic knowledge if you work with database.
I am not even a developer hire, I'm self learned, and because the company doesn't have many developers they gave me some of the tasks and I'm doing it because it's more fun than my job responsibilities, and when I don't have enough tasks.
Ive used them to help a lot in the past, but they often didnt give enough detail. Like I would know the area something was a problem, but pinpointing exactly what it was was still up to me, and would take some time. It worked but it could have been better.
Turns out there was a library you can add which adds that extra missing detail, and with that it was possible to highlight the exact issue. Wish id known about that sooner. That was on me though.
Flame graphs have really only been a thing for the last decade or so. The free tooling for profiling code has been shitty and difficult to understand for most of my career. And most companies aren't willing to pay for it if the product runs "good enough". These days companies lock down their shit so tight that you can't even install an unapproved app no matter how free or useful.
I think that's true for many tools. Programming tools are the one thing that has most advancement because so many programmer are there to improve on them. And even if you don't use it, not knowing about it completely makes it a bit odd. Although most tools I have used to make flamegraph were as easy as just running the program as a argument to another program that tracks the function calls.
You see, performance is rarely a talking point in retrospectives unless its egregious. If you say a piece of compute is struggling the solution is to always buy more compute. It is rare that anyone would think of optimization unless you're writing libraries.
I think that's one of the problem with people that are only of a "finish this task cheaply for now" mind.
Having something run in 0.1 second vs 1 second is fine when a user is running it for one thing. So they consider it good or instantaneous. And later they have to do it for 1000 other things, and they don't think that saving time in that "instantaneous result" there would save so much more time. They just go "it's 1000 of these so it takes time". I've found functions that open a db file, read one entry and close it. Then that function is called for each entry they have to read later. In a preprocessing step where they know all the entries they need beforehand. And even the data tyoe to store it is nor preallocated, they just append it on every data read; again on a fixed number of entries they need.
I understand performance not being the most important thing, but I'd expect least a basic understanding of design that has unnecessary processing.
Or if its employee facing only let it get slower and slower to the point where it takes a minute to update one record
Which is exactly why western AI companies are bankrupting themselves building data centers while China is easily keeping pace with a fraction of the resources. They're not magic. They just do basic things like make things more efficient.
Pay me to do it and I'll gladly do it. Most companies, however, don't really care much about whether the customers take an extra 100 milliseconds for every request or not. And when it's promotion time, you're often judged by how many tasks you get done, not how fast your code is.
There are NP problems and you should know how to assess them.
muh io bound
🤣
If the DB is IO-bound, and "slow languages" don't matter because "IO bound", then show me the DB you're using implemented in a slow language.
It's hilarious how op is being this stupidly unaware, even within his stupid false argument which is provided as a supposed given.
How are people seriously engaging with this blog fart full of false premises and contradictions?
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
Profiling complex systems can be quite difficult. That said, I believe in the adage "Profile twice, optimize once.", adapted from the old carpenters adage of "Measure twice, cut once."
Slowness is rarely essential, but I can be far away from where you expect it.
That's what Open Telemetry is for, honestly, specifically tracing. I'm in the process of adding tracing for all of our web handlers, http client calls, database transactions/individual queries, and asynchronous jobs. Should give us a pretty good view into the performance of the system, and allow us to monitor for things like performance regressions without any dedicated profiling needed (though we certainly could add additional profiling information through Otel down the road). Since I know you're a Haskeller (recognize your handle), the hs-opentelemetryecosystem is quite solid and has integrations with a lot of libraries in the wider ecosystem, like wai, persistent, postgresql-simple, conduit, and a bunch more. I haven't needed to write too much of our own instrumentation, aside from our job system since that's a bespoke system.
load more comments
(1 replies)
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.
Web development and using browser renderers for GUIs is one of my most hated aspects of modern software. 🤢
Electron should have never existed and should be cometeñy banned, yeah
Sorry guys, back in 2008, I asked a monkey's paw for better first party software support for desktop Linux, and this is what we got.
load more comments
(9 replies)
I worked at a place where a site had to show the number of members, but for some reason it didn't show the correct number. The reason was the query to the database was wrong, I corrected it in five minutes and the boss told me to put numbers manually, increasing them until we could display the correct query result because apparently the problem was there a long time before I started working there and it would make a bad image for the company if it was so easily corrected.
On other project a friend of mine told me about things were so slow and getting slower with time. Database didn't have keys, indexes, nothing you should expect a relational database to have.
I haven't worked in a while because of my health issues and I can assure you I'd be happier getting paid for watering plants than working with computers.
Nah, software is slow because it runs a web engine for GUI.
load more comments
(10 replies)
I wrote a program in Python to read some huge Json files. It took forever to finish. Turned out I could optimize it with some simple changes, which reduced 10 minutes to 10 seconds (not literally, just figurative) and made a difference in huge files only. Later I rewrote the program in Rust. And you know what happened? It was slower than the Python version. Only after understanding what I was doing and making right changes made the Rust version faster.
Most of the time its the design of the code or libraries that slows down. The language might play a huge role in performance, but it depends on what type of code and application it is.
I actually wanted write a blog post about this... if I still have the project data I might explain what happened. BTW this had nothing to do with Ai.
As an OPS guy you know what really grinds my gears? Developers not paying attention to shit like this.
We have a job in production that is a powershell script calling a powershell script calling a java applet. Now you may already be thinking "what is this abomination?" And you're right, but that java application is set to DEBUG. IN PRODUCTION. So every time it runs it generates 1gb of logs.
Do they fix it? No of course not because if it's not broken don't fix it. But Jesus Christ we have people developing without understanding fundamentals like "YOU DONT LEAVE DEBUG ON IN PRODUCTION".
I don't understand how this is even possible.
People are dumb
load more comments
(32 replies)
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."
load more comments
(7 replies)
view more: next ›
this post was submitted on 23 Oct 2026
331 points (96.4% liked)
Programming
28952 readers
793 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS