Nah, software is slow because it runs a web engine for GUI.
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.
Yes and no. It’s not usually the fault of the programming language.
But programming languages have a unique ability: The design of the language itself can and will instill bad or good habits into the code of oneself. These languages are designed pretty deliberately, so those habits are a direct consequence of the design of a language. In fact, Sean Goedecke’s own C-to-Rust example makes this point implicitly: Cantrill’s port got faster not because the redesign was really clever, but because Rust’s borrow checker and standard library actively steered him toward a more cache friendly Binary tree. There are probably many more examples out there that had a real world impact.
There are no bad languages, every language has its place somewhere. But design decisions matter.
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.
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.”
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.
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.
yeah, sometimes it feels like the same people complaining about python speed are the ones writing “C” code in python.
What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?
Or the fact that you can’t do concurrency especially across the language barrier from another language without multiple python runtimes orchestrated with a queue and IPC because of possible process-wide global state and similar concerns/assumptions for any python library dependency that is not all native across its own dependency chain?
“languages are just tools” and “use the right tool for the job” were already stupid catch phrases. Pretending languages don’t matter is a big further step into this shallow faux-intellectualism masquerading as wisdom.
And we didn’t even get to low level stuff yet.
What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?
While Python’s start-up time is a lot slower than a corresponding compiled program, in most cases it’s not slow enough to matter even if the process itself is short-lived:
$ hyperfine 'python3 -c "pass"' Benchmark 1: python3 -c "pass" (412 runs) mean ± σ min … max Wall Time 7.1 ms ± 0.2 ms 6.7 ms … 8.4 ms Memory 9.4 MiB ± 0.1 MiB 9.1 MiB … 9.5 MiBIf you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article’s thesis
At that point just call the person messy and move on. They just want to flex their brain.
The thing is also that you can’t separate a language from its ecosystem.
Because it is possible to write the fastest programs in C/C++ and Rust, folks that actually need the fastest performance will use these languages and will go around opening pull requests to fix performance problems in commonly-used libraries.
So, you do often end up with the most performant design anyways, just because the language itself is fast on paper.
I wrote a draft of a service that would take hours to complete. when I optimized it for multithreaded operation instead of taking hours it took around 60 seconds.
write software like you write research papers. first draft > second draft > final draft > publication
I’d argue a combination of bad design and/or bad implementation, which i would consider different things.
It’s a difference that becomes more pronounced the larger the team grows.
A somewhat reasonable design can be absolutely destroyed by a poor implementation of that design
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.
deleted by creator
