It's not surprising that Python doesn't work well in such a high-delay dev environment.
That's putting it nicely. Based on experience, I'd say it's arguing about preferences while demanding that code be coupled because "that's how we do things here".
> culture is far more like academia anyway
Academia is actually based on research and correctness to a much higher degree. The lack of focus on correctness in code worked on at Google is, honestly, appalling. Until, of course, you realize that all other FAANG employees still write loads of concurrency bugs and pronounce themselves gods for doing so.
That's certainly not been my experience (and I get the exact opposite impression from people involved in the formal readability process).
> Academia is actually based on research and correctness to a much higher degree.
This depends, greatly, on what part of academia you're in. In many ways, Google is much better about correctness than much of academia (reproducibility, for example, is often near trivial at Google but uncommon in most non-theoretical areas of academia).
> The lack of focus on correctness in code worked on at Google is, honestly, appaling
There are tradeoffs here. On the one hand, you have tens of thousands of engineers, you're not going to be able to enforce perfection by every single one with the tools available today with a reasonable cost. On the one hand, I see evidence that Google is willing to invest huge amounts into improving software correctness at the lowest levels (like proposing and upstreaming changes to languages to improve correctness-by-default).
To my eyes, we still develop software in plain text and the same languages are still dominant. It's still Linux and http.
It's not just Linux and http anymore. It's frameworks towering up to the heavens.
On the one hand I agree with you, in that these liabilities you describe are much like the legacy systems I see in our local banking sector.
On the other hand, these legacy systems just work. And adopting newer / more modern systems might definitely have advantages, but doing so creates a bunch of other liabilities - as I've seen take place in our new startup banks.
Stuck between a rock and a hard place.
Of course that's just in banking. I most certainly don't have the experience to comment on whether the same liability tradeoff would happen at FAANGs.
Its not being stuck between a rock and a hard place, you just need strong management that understands that changing whole systems is never a good idea without clear benefit, other than "technical debt" which is such a bad term for reliable software. Software doesn't age, im not sure how software engineers don't understand this, or maybe they do and want to write more s/w.
And that's besides tribal knowledge that goes away as people leave or retire.