Users don't care about your tech stack

$ rustc --version && rustc hello.rs && ls -alh hello

rustc 1.84.1 e71f9a9a9 2025-01-27 -rwxr-xr-x 1 user user 9.1M hello

So 9.1 MB on my machine. And as I pointed out in a comment below, your release binary of 440k is still larger than necessary by a factor 2000x or so.

Windows 95 came on 13x 3.5" floppies, so 22MB. The rust compiler package takes up 240mb on my machine. That means rust is about 10x larger than a fully functional desktop OS from 30 years ago.

For me,

3.8M Feb 21 11:56 target/debug/helloworld

I have never seen it used like that. I have always seen it used like parent said: to justify awful technical choices which hurt the user.

I have written performant high quality products in weird tech stacks where performance can be s bit tricky to get: Ruby, PL/PgSQL, Perl, etc. But it was done by a team who cared a lot about technology and their tech stack. Otherwise it would not have been possible to do.

Look at every single discussion about Electron ;)

"It's a basic tool that sits hidden in my tray 99.9% of the time and it should not use 500MB of memory when it's not doing anything" is part of product quality.

Businesses need to learn that, like it or not, code quality and architecture quality is a part of product quality

You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time

This is why startups can outcompete incumbents sometimes

Suddenly there's a market shift and a startup can actually build your entire product and the new competitive edge in less time than it takes you to add just the new competitive edge, because your code and architecture has atrophied to the point it takes longer to update it than it would to rebuild from scratch

Maybe this isn't as common as I think, I don't know. But I am pretty sure it does happen

> No, it means that product quality is all that matters

But it says that in such a roundabout way that non technical people use it as an argument for MBAs to dictate technical decisions in the name of moving fast and breaking things.

> product quality is all that matters

I don't know what technology was used to build the audio mixer that I got from Temu. I do know that it's a massive pile of garbage because I can hear it when I plug it in. The tech stack IS the product quality.

I don't think that's broadly true. The unfortunate truth about our profession is that there is no floor to how bad code can be while yet generating billions of dollars.

If users care so much about product quality why is everyone using the most shitty software ever produced — such as Teams?

For 99% of users, what you describe really isn't something they know or care about.

alacritty (in the arch repo) is 8MB decompressed

alacritty is also written in rust and gpu accelerated, so the other vte must just be just be plain bad

Edit: Just tried turning on a couple bin-size optimizations which yielded a 3.3M binary

I saw an HN post recently where a classic HN commentator was angry that another person was using .NET Blazor for a frontend; with the mandatory 2MB~3MB WASM module download.

He responded by saying that he wasn’t a front-end developer, and to build the fancy lightweight frontend would be extremely demanding of him, so what’s the alternative? His customers find immensely more value in the product existing at all, than by its technical prowess. Doing more things decently well is better than doing few things perfectly.

Although, look around here - the world’s great tech stack would be shredded here because the images weren’t perfectly resized to pixel-perfect fit their frames, forcing the browser to resize the image, which is slower, and wastes CPU cycles every time, when it could have been only once server side, oh the humanity, think about how much ice you’ve melted on the polar ice caps with your carelessness.

My point was that many programmers have no conception of much functionality you can fit in a program of a few megabytes.

Here is a pastebin[1] of a Python program that creates a "Hello world" x64 elf binary.

How large do you think the ELF binary is? Not 1kb. Not 10kb. Not 100kb. Not 263kb.

The executable is 175 bytes.

[1] https://pastebin.com/p7VzLYxS

(Again, the point is not that Rust is bad or bloated but that people forget that 1 megabyte is actually a lot of data.)

Thanks for pointing this out.

It does seem weird to complain about the file size of a debug build not a release build.

When I was at Google, our team kept RUM metrics for a bunch of common user actions. We had a zero regression policy and a common part of coding a new feature was running benchmarks to show that performance didn't regress. We also had a small "forbidden list" of JavaScript coding constructs that we measured to be particularly slow in at least one of Chrome/Firefox/Internet Explorer.

Outside contributors to our team absolutely hated us for it (and honestly some of the people on the team hated it too); everyone likes it when their product is fast, and nobody likes being held to the standard of keeping it that way. When you ask them to rewrite their functional coding as a series of `for` loops because the function overhead is measurably 30% slower across browsers[0], they get so mad.

[0] This was in 2010, I have no idea what the performance difference is in the Year of Our Lord 2025.

> They instead make completely unfounded assertions that are wrong more than 80% of the time and when they are wrong they tend to be wrong by several orders of magnitude.

I completely agree. It blows my mind how fifteen minutes of testing something gets replaced with a guess. The most common situation I see this in (over and over again) is with DB indexes.

The query is slow? Add a bunch of random indexes. Let's not look at the EXPLAIN and make sure the index improves the situation.

I just recently worked with a really strong engineer that kept saying we were going to need to shard our DB soon, but we're way to small of a company for that to be justified. Our DB shouldn't be working that hard (it was all CPU load), there had to be a bad query in there. He even started drafting plans for sharding because he was adamant that it was needed. Then we checked RDS Performance Insights and saw it was one rogue query (as one should expect). It was about about a 45 minute fix and after downsizing one notch on RDS, we're sitting at about 4% most of the time on the DB.

But this is a common thing. Some engineers will _think_ there's going to be an issue, or when there is one, completely guess what it is without getting any data.

Another anecdote from a past company was them upsizing their RDS instance way more than they should need for their load because they dealt with really high connection counts. There was no way this number of connections should be going on based on request frequency. After a very small amount of digging, I found that they would open a new DB connection per object they created (this was PHP). Sometimes they'd create 20 objects in a loop. All the code was synchronous. You ended up with some very simple HTTP requests that would cause 30 DB connections to be established and then dropped.

My plex server was down and my lazy solution was to connect directly to the NAS. I was surprised just how much I noticed the responsiveness after getting used to web players. A week ago I wouldn't have said web player bothered me at all. Now I can't not notice.

Can you show me any longitudinal studies that show examples of a causal connection between incrementality of latency and churn? It’s easy to make such a claim and follow up with “go measure it”. That takes work. There are numerous other things a company may choose to measure instead that are stronger predictors of business impact.

There is probably some connection. Anchoring to 10ms is a bit extreme IMO because it’s indirectly implying that latency is incredibly important which isn’t universally true - each product’s metrics that are predictive of success are much more nuanced and may even have something akin to the set of LLM neurons called “polysemantic” - it may be a combination of several metrics expressed via some nontrivial function that are the best predictor.

For SaaS, if we did want to simplify things and pick just one - usage. That’s the strongest churn signal.

Takeaway: don’t just measure. Be deliberate about what you choose to measure. Measuring everything creates noise and can actually be detrimental.

Soooooo, my "totally in the works" post about how direct connection to your RDMS is the next API may not be so tongue in cheek. No rest, no graphQL, no http overhead. Just plain SQL over the wire.

Authentication? Already baked-in. Discoverability? Already in. Authorization? You get it almost for free. User throttling? Some offer it.

Caching is for weak apps.

60hz screens update every 16.7 ms. So if you add 10 ms to your frame time you will probably miss that 16.7 ms window.

Almost all can see the difference between 60 and 120 fps. Most probably don't care though.

That's fine, but I am responding directly to the article.

> [Questions like] “Is this framework more performant than the other?” keep coming up. But the truth is: users don’t care about any of that.

Amazon nowadays has a near monopoly powered by ad money due to the low margin on selling products versus ad spend. So unless you happen to be in the same position using them nowadays as an example isn't going to be very helpful. If they increased sales 20% at the cost of 1% less ad spend then they'd probably be at a net loss as a result.

They absolutely do not. In fact, relatively few do. Every single Electron app (which is a depressing number of apps) is a bloated mess. Most web pages are a bloated mess where you load the page and it isn't actually loaded, visibly loading more elements as the "loaded" page sits there.

Software sucks to use in 2025 because developers have stopped giving a shit about performance.

This is so true, and yet. . . Bad, sluggish performance is everywhere. I sometimes use my phone for online shopping, and I'm always amazed how slow ecommerce companies can make something as simple as opening a menu.

Having worked on similar solutions that use Java and Python, I can't say I agree (the former obviously being much faster).

That's also an aphorism that may or may not correspond to reality.

Not only there are companies with highly capable teams that are able to move fast using a complex mix of technologies, but also there are customers who have very little interest in new features.

This is the point of my comment: these maxims are not universal truths, and taking them as such is a mistake. They are general models of good ideas, but they are just starter models.

A company needs to attend to its own needs and solve its own problems. The way this goes might be surprisingly different from common sense.

How big is your team?

One person writing a stack in 6 languages is different from a team of 100 using 6 languages.

The problem emerges if you have some eccentric person who likes using a niche language no one else on the team knows. Three months into development they decide they hate software engineering and move to a farm in North Carolina.

Who else is going to be able to pick up their tasks, are you going to be able to quickly on board someone else. Or are you going to have to hire someone new with a specialty in this specific language.

This is a part of why NodeJS quickly ate the world. A lot of web studios had a bunch of front end programmers who were already really good with JavaScript. While NodeJS and frontend JS aren't 100% the same, it's not hard to learn both.

Try to get a front end dev to learn Spring in a week...

> Your customer does care about how quickly you can iterate new features over time

How true this is depends on your particular target market. There is a very large population of customers that are displeased by frequent iterations and feature additions/changes.

I heavily dislike GraphQL for all of the reasons. But I'll say that for a lot of developers, if you are already setting up an API gateway, you might as well batch the calls, and simplify the frontend code.

I don't buy it :) but I can see the reasoning.

C++ is often the best answer for users, but this is about how bad the other options are, and not that C++ is good. Options like Rust doesn't have the mature frameworks that C++ does. (rust-qt is often used as a hack instead of a pure rust framework). There is a big difference between modern C++ and the old C++98 as well, and the more you force you code to be modern C++ the less the footguns in C++ will hit you. The C++ committee is also driving forward in eliminating the things people don't like about C++.

Users don't care about your tech stack. They care about things like battery life, and how fast your program runs, how fast your program starts - places where C++ does really well. (C, rust... also do very well). Remember this is real world benchmarks, you can find micro benchmarks where python is just as fast as well written C, but if write a large application in python they will be 30-60 times slower than the same written in C++.

Note however that users only care about security after it is too late. C++ can be much better than C, but since it is really easy to write C style code in C++ you need a lot more care than you would want.

If for your application Rust or ada does have mature enough frameworks to work with then I wouldn't write C++, but all too often the long history of C++ means it is the best choice. In some applications managed languages like Java works well, but in others the limits of the runtime (startup, worse battery life) make it a bad choice. Many things are scripts you won't run very much and so python is just fine despite how slow it is. Make the right choice, but don't call C++ a bad choice just because for you it is bad.

For real time audio synthesis or video game engines then C++ is the industry standard.

It's true, and of course, all models are wrong, especially as you go into deeper detail, so I can't really argue an edge case here. Indeed, C++ is rarely the best answer. But we all know of trading systems and gaming engines that rely heavily on C++ (for now, may Rust keep growing).

...unless you do HFT...

And thus when I clicked on the link to a NPR story just now it was 10 seconds before the page was reasable on my computer.

Now my computer (pinebook pro) was never known as fast, but still it runs circles around the first computer I ran a browser. (I'm not sure which computer that was, but likely the CPU was running at 25mhz, could have been a 80486 or a Sparc CPU though - now get off my lawn you kids)

Those are things developers say to keep themselves employable.

Your users feel otherwise. If you actually care at all about the quality of the software you produce, stop rationalizing slow software.

Ive been working in Elixir since 2015. I love the ecosystem and think its the best choice for building a web app from a pure tech/stability/scalability/productivity perspective (I also have a decade+ experience in Ruby on rails, Nodejs, and Php laravel, plus Rust to a lesser extent).

I am however having trouble in the human side of it. Ive got a strong resume but I was laid off in Nov 2024 and Im having trouble even getting Elixir interviews (with 9+ years of production Elixir experience!). Hiring people with experience was also hard when I was the hiring manager. It is becoming less niche these days. I love it too much to leave for other ecosystems in the web sphere

I couldn't even begin to speak to Elixir. Never used it.

Most of my work is client-side (native Apple app development, in Swift).

For server-side stuff, I tend to use PHP (not a popular language, hereabouts). Works great.

Elixir can be used for scripting tasks, config and test rig are usually scripts. In theory you can use the platform for desktop GUI too, one of the bespoke monitoring tools is built that way. Since a few years back there are libraries for numeric and ML computing too.

The opinionated people I disagree with sure like saying "language doesn't matter", as long as it preserves their status quo.