Both matter…
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’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.
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 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.
Had the same experience when I was testing zed. Was thinking it would be a lot better since it’s written in rust but there wasn’t any difference in memory/CPU usage between it and VSCodium, which is electron app.
Even nvim will eat up about 5GB of RAM when used as an IDE. MCP alone will use that much of RAM independent of the editor.
From what I remember, Vscode has quite a fair bit native code in various areas to make it perform better. So it may not be the representative Electron app for comparison.
I’ve done tests like that too, and I can’t agree with you.
Plus, GTK is a bad comparison. One of the worst native toolkits, if not the worst one along with any and all immediate mode ones.
I’ve also compared native Rust library (egui? don’t remember exactly) with Tauri and the difference wasn’t that big. What did you compare? As I said, native solutions should use less memory if you run a lot of them at the same time as they will load shared libraries only once. So I guess if you run KDE and start single Qt app it will look better than running single Qt app under Awesome WM or cosmos.
Web development and using browser renderers for GUIs is one of my most hated aspects of modern software. 🤢
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.
Electron should have never existed and should be cometeñy banned, yeah
Too many abstraction layers
Is slow because of both. Using bad languages is one form of bad design itself, in fact.
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
Except for python.
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.”
…I don’t use Goog’s search, just like probably many people on Lemmy.
Yeah, I long ago switched to ddg and I also turn off the ddg ai stuff. I hear the paid search is also out-performing Google for people that care their search results are accurate.
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.
I’d like you to name 1 that’s multi-hundred MB.
I saw something where the NYT webside takes up over 100MB if RAM.
Can’t, I was thinking of MSN.com but they had a redesign sometime, they come in at 5.6mb now
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.
This neglects to include the massive amount of additional front-end code Google (and other large tech companies) toss on their webpages for things that are purely for their own benefit while being of zero or negative value to the users. Mouse tracking, analytics, fingerprinting, and all kinds of other harmful content that tech companies put out go a long way towards reaching that 4MB figure.
Never understood the idea of, “if it needs to be fast, that part is in a faster language.” Why not just use the faster language? Most of the libraries that have Python wrappers also come with c headers. Sometimes you wind up in the reverse situation where your dependency doesn’t have a Python wrapper and now you’re stuck managing silly boilerplate. Python just feels like an extra thing in the way to wrangle for little gain.
Also, hotspot-only optimization doesn’t seem to have held up in reality, right? We can all agree that software is getting slower every day. The infrastructure is slow.
All feels like cope, through and through.
IMHO it’s easier to quickly iterate with Python than with C++. If you aren’t even sure what you want and you’re just writing stuff, then Python is great. Is “4” true? Ofc it is.
Why not just use the faster language?
Because the other language is more developer-friendly or faster to write/read even if slower to execute. Some code doesn’t need to be fast because it is always waiting on other things anyway.
Some languages effectively prevent whole classes of runtime failures / bad code. But, they do that by doing more which takes longer, at compile-time, run time, or both.
Some programs can’t avoid graph-structured data dependencies. In that case, the simplest solution is a garbage collector, and one built into the runtime is capable of being more efficient (and less buggy) than one written for a specific program.
Anyway, there are many factors that determine which language is “best”, and not all of them are objective. That’s why we don’t just use the fastest language. (Currently, I do all my coding in either Idris or Purescript, but I’m also unemployed and just programing for myself, for now.)
All programming is a trade-off between what’s easy for the developer and what’s fast for the machine.
Sure, you could theoretically write everything in Assembly and it’d be blazingly fast; but unless you’re a particularly elite developer, that process would take forever for any program more complicated than a calculator, the result would be super buggy, and those bugs would be very hard to fix.
On the other end of the spectrum, you might imagine a natural language machine learning compiler which translated directly from human prose to binary. It would be dead simple to “program” anything in; but such an application would probably be unbelievably slow, and again, have a staggering number of difficult-to-fix bugs.
Somewhere in the middle are modern programming languages that abstract away all of the stuff that’s necessary but hard for humans to wrap their minds around (memory management, API interaction, network stack, etc) and let the human write clear and unambitious code to handle all of the business logic and displaying it to the user. The result won’t run as blisteringly fast as writing directly in Assembly, and it won’t be as quick to market as Vibes-to-ASM, but the application will be developed in a reasonable amount of time and be reasonably easy to maintain.
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.
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.
What if the language has a bad design?
Then use it poorly and it’s a double negative.
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.
Optimising too early is the root of all evil or something like that
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?
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
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.
