> But the amount of money going by is so huge they can take a tiny percent of it to pay their server bills.
I think that's an oversimplification that doesn't do justice to the complexity or difficulty of the issue. Both sides of the argument can make a really good case.
Slow programs (due to language or other factors) increase server costs, but that's only part of the problem. They also increase operational and architectural complexity, meaning you spend more time, effort and specialized expertise on these secondary effects. Note that some of that shimmers through in the article, mentioning "CI flakiness": It's probable that the baseline performance and its effects is a factor there. Performance has a viral effect on everything, positively or negatively. They also complain about async not being a part of the story here, which is also a performance issue.
On the other hand, this shop has hundreds of developers. That means deep expertise, institutional knowledge, tooling, familiarity with each line of code and a particular style that they follow. Ruby is also a language that is optimized for programmer experience, and is apparently a fun language to work with. All those things are very essential investments, individually and as a whole. Then we can assume that they use Ruby like most glue languages are used and either write C/C++ modules where appropriate or attach high performing components into their architecture (DBs, queues, caches etc.)
The reason I'm harping on this point is because I think it's important to acknowledge a more complete reality than the "hardware is cheap, people are expensive" statement. I assume it's very likely a throwaway line and not a hill you'd die on. But it masks two interesting and important things: Performance matters a lot and impacts cost transitively, but people and culture ultimately dominate for very good reasons.
I think you could have very happy devs working on a system like Stripe in either Java or Ruby, the choice of language is less important than everything else.
Personally I would judge an engineering manager on how seriously they take issues with the build. The industry standard is that a junior dev having trouble with the build is told he's on his own, the gold standard is that he gets a checklist and if the checklist doesn't work it is treated as if the dev had said "I have cancer".
A fast language can be slow to build. [1] If you were really designing a system for long term maintainability fast and sensible tests and solid CI would be determining factors. The only velocity metric which needs to be measured is the build time.
At the moment I have a side project I'm doing which is a port of the arangodb API to postgresql intended to bring a few arangodb applications into the open source world. I test at the level where I make a new postgres db and do real operations against it because I really need to do that to soak up all the uncertainty in my mind, never mind test the handful of stored procs that the system depends on. I have 5 big tests instead of the 300 little tests I wish I had because it takes 0.2s to set up an tear down the fixtures and if the tests take too long to run that's really a decision that I'm not going to do any maintenance on the thing in the future.
I am working on a React system which is still in an old version where test frameworks can't tell if all the callbacks are done running which means practically I don't write tests because even though I'm a believer in tests, it already takes 50 sec to run the test suite and frequently as much time to update tests as it takes to make changes. Had I been writing tests at the rate I want my tests would take 500 sec to run.
[1] Though I'd argue that performance concerns are one reason we can't have nice things when it comes to flexible parsers and metaprogramming; Python's use of PEG grammars has so far fallen so short of what it should have been because of these concerns, no unparser to go with the parser, no "mash up SQL or some other language into a certain slot in the Python grammar"
I think that's an oversimplification that doesn't do justice to the complexity or difficulty of the issue. Both sides of the argument can make a really good case.
Slow programs (due to language or other factors) increase server costs, but that's only part of the problem. They also increase operational and architectural complexity, meaning you spend more time, effort and specialized expertise on these secondary effects. Note that some of that shimmers through in the article, mentioning "CI flakiness": It's probable that the baseline performance and its effects is a factor there. Performance has a viral effect on everything, positively or negatively. They also complain about async not being a part of the story here, which is also a performance issue.
On the other hand, this shop has hundreds of developers. That means deep expertise, institutional knowledge, tooling, familiarity with each line of code and a particular style that they follow. Ruby is also a language that is optimized for programmer experience, and is apparently a fun language to work with. All those things are very essential investments, individually and as a whole. Then we can assume that they use Ruby like most glue languages are used and either write C/C++ modules where appropriate or attach high performing components into their architecture (DBs, queues, caches etc.)
The reason I'm harping on this point is because I think it's important to acknowledge a more complete reality than the "hardware is cheap, people are expensive" statement. I assume it's very likely a throwaway line and not a hill you'd die on. But it masks two interesting and important things: Performance matters a lot and impacts cost transitively, but people and culture ultimately dominate for very good reasons.