I think the better way to put it that "we" stopped caring about performance both on the client (think Electron) and on the server (ORMs & dynamic languages, as already mentioned) at some point of time in favour of faster time to market, cheaper. Just so that the output is "good enough".

But honestly, I agree with that approach to a certain (!) extent. I don't want to write all of my backend in C++. I use Java or Python instead. Thousand reasons: maven/pip, portability etc.

So, I would say we need to come to terms with ourselves and agree that the productivity is sometimes increased at the expense of the system quality. After that, I think it's okay to keep doing that if both us and our customers are OK with the tradeoff.

Just to illustrate: do I like the RAM consumption & the startup time of my Slack app? No. But I am a free user, so I can't complain. In the end, the Slack team probably made the right choice.

UPD: 500 error is gone. Gitlab also needs to manage costs and be friendly to the OSS contributors. Ruby was also probably a good choice for them. If you want top-notch software, be prepared to stomach NASA-grade costs, because the rumour is that 1 LOC in Shuttle ended up costing $1500 [1].

P.S. Thanks a lot for the [2] paper reference!

[1] https://www.johndcook.com/blog/2009/10/08/nasa-buggy-softwar...