What if the language has a bad design?

There are NP problems and you should know how to assess them.

Optimising too early is the root of all evil or something like that

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?

Both matter...

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.

Or if its employee facing only let it get slower and slower to the point where it takes a minute to update one record

People are dumb

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 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.

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.

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.

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.

Too many abstraction layers

Is slow because of both. Using bad languages is one form of bad design itself, in fact.

Electron should have never existed and should be cometeñy banned, yeah

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.

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.

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

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.

Electron is also the worst web based toolkit out there. Solutions that use system webviews instead of running whole Chrome are much lighter.

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.

I compared one single Qt app (QOwnNotes) with one single similar Tauri app (I don't remember the name, I was trying apps because I was looking for something extensible that wasn't Electron-based as Logseq). It was a huge difference for me, at least, more or less 100 MB, and for what I knew, it was not that badly programmed.

And for me, with only 16 GB lf RAM and an Intel Xeon v4 (12C/24T @ 2.20 GHz max) it's even more noticeable, specially because I work in multimedia (music production and sound design) and I have to use a browser and a communications app all the time because I need to research stuff and communicate with some peers and my clients (the very few times I have clients).

Every byte counts, even if you have lots of memory and a huge processor and GPU. Thinking that "1 MB is not that much" is what has led us to this crysis. We should make any and all possible optimizations to be able to ship featureful software that's not overbloated (Suckless dickheads can suck my ass).

I'd say a bit of both. People who are fine with having a DOM worth of overhead don't give me much confidence they are selecting algorithms well, which can absolutely affect performance and efficiency regardless of what language they are written in.

Hell, even with the optimal data structures and algorithms selected, how you set them up can make a huge difference.

Like I once had essentially a data translator that, in order to be generic, used keys in a dictionary to replace the hardcoded data structure that needed to be updated any time the spec changed, even if we didn't care about the new values.

The first version used an array of dictionaries and was slow as fuck. Each line of data would get its own dictionary and just parsing the data into this scheme took a couple minutes IIRC. Since the data was guaranteed to have the same keys each line (we were worried about changes between versions, not lines), I changed it to a dictionary of arrays, where each line would have the same index across the dicts, and it brought parse time down to several seconds. Huge difference even though big O notation would have simplified to the same expression for the two methods.

But if you pick something with a worse big O expression, it gets worse on a whole other level.

The issue is that any time you add another generic layer, it involves another layer of loops for "handle everything" tasks and lookups for "handle this specific thing" tasks. A native app could set a bunch of values for properties by changing them in a single function accessing a single data structure. You might have a single function that does the same thing using frameworks, but that function is potentially going to use accessor functions to reach down each layer to set those values where they matter plus could need to do a bunch of transformations as it traverses each layer (or maybe that's done on the render side).

So then you add a bunch of caching to improve these common scenarios and balloon memory usage, which was already inflated because those layers also need memory to store their data structures.

And these things get worse as they scale, so small scale tests still look snappy and hide how much things can grind to a crawl when it needs to handle the large or normal scale. Not to mention, if you don't have a speedy version to compare to, you might just think that it makes sense for this process to take a couple minutes because it has millions of things to do (despite running on hardware that can do billions of things per second).

Then use it poorly and it's a double negative.

Every method just returns an empty string. Runs fast as hell. Just don't expect it to do anything.