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?
Except for python.
What if the language has a bad design?
Then use it poorly and it’s a double negative.
Has everyone forgotten the art of creating or using performance profiling tools
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.
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.
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.
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.
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.
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 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.
Optimising too early is the root of all evil or something like that
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.
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, likewai,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.Yeah we used hs-opentelemetry at my last paid position. The company was an MS shop, tho so we were using ODBC to connect to MS SQL Server which doesn’t have great in-process profiling. But, at least we could figure out what quer(y/ies) were running long and then we could use the MS tools to look at the plan and fiddle with that. It was also a small org, so it’s not like there was a lot of internal services in one flow – basically everything either stayed in the Web Yesod app or in the IVR app. All our profiling could have been instrumented process profiling instead of having to use otel at all.
So, I haven’t seen how easy/difficult it is to actually use otel across multiple internal service calls to satisfy one external request.
yeah that matches what I see, most of what we run at work is one app and one database, so the slow query log plus looking at the plan gets you like 90% of the way. I never really had the multi service case where otel pays off, I guess at some point it does, but for a small team it felt like a lot of plumbing to end up finding the same n+1 query lol
Compare frameworks more than languages.
Hyper > Gin > FastAPI > NextJS > Laravel > Drupal
Qt > GTK > Tauri > Fyne > Wails > Electron > React Native
BRB, gonna tell my boss we should move our data warehouse to sqlite.
He said “simple comparisons of technologies on a single metric are stupid.”
SQLite > pgsql
Disagree. Different tools for different jobs.
He is right in many aspects. However, for example Guile, Racket or SBCL Lisp are a lot faster than Python, and they are more powerful than Python while being much simpler, which makes them very interesting for prototyping algorithms.
The ideal combo for such things would be a powerful interactive language with debugging capabilities combined with Rust, perhaps even a language similar to Rust. I do not know of any easy solution for that, but it could be made work with Rust’s macro system (since the above languages all provide C ABI FFI).
Also,most of design happens when a program is written first. It is hard to re-design a larger program later, which might be one reason to re-write it. So maybe the main reason for rewriting is to get a better design, not the faster language - the faster language might be an additional reason.
Also, LLMs can produce terribly bloated Rust code - not only by a factor ten larger, but also much slower.
Also, CRUD apps are uninteresting to many programming enthusiasts, and for companies, optimizing them is only interesting if it saves them money.
Bullshit. My experience of Python is that only a small subset of programs are actually IO bound.
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.
Python copium.
Both matter…
I always wonder who is the target audience of such shallow fallacy-filled pretend-insightful faux-wisdom. But then I remember that most people waste a lot of time following <topic> aggregator/discussion sites are young impressionable enthusiasts who don’t know much.
If you think about it, this was also true in the 80s, but because the hardware sucked. Good thing we learned better design so we can have things like AI
