Comment by pradn
3 years ago
It's clear that the biggest problem is companies prioritizing their cost, at the expense of user experience.
But after that, the biggest problem is clearly the framework/language you use. The maxim "premature optimization is the root of all evil" has done damage here. The problem with frameworks/languages is that by the time you finish your features and profile your code, you're already doomed. There's no way to speed up the entire framework/language, because it's part of everything you do - death by a thousand cuts. Nothing you do can improve upon the fundamental fact of running in an interpreter, with a garbage collector, with complex layout calculations (a la HTML/CSS instead of Win32), or with major choices like processes over threads, sync IO over async IO.
Well, there is a step beyond framework hell that can work, which is "living inside your own black box"[0]. This strategy intentionally supersedes the lower-level abstraction layers with a higher-level, application-focused one that eases rewriting the underlying stack "sometime down the road". It's nearly the only way you can get that.
But it does require a good understanding of what the application is and does, and a lot of software isn't that: it's just more stuff that has a behavior when you click around and press keys.
[0] https://prog21.dadgum.com/66.html
Actually I suspect unnecessary use of async IO is what makes many Rust applications slow. It surely makes things slower to compile (+100s of crates dependencies for the Tokio ecosystem), it makes the binaries bigger, which in turn makes the application slower to cold start and download.
Isn't all this stuff written in C++? I suspect the slowness is bad system design.