From where I sit (SRE), I see a lot of Python which is very much mission critical.
I never saw Python actually get used, though, in the projects I worked on.
First, there are two SRE ladders: SRE-SWE and SRE-SysEng. SRE-SWE have the same interviews and hiring bar as SWEs. SysEng have less coding interviews but I think the interview questions are more practical and less algorithm oriented.
Still, SREs are subject to the same rules and policies as SWEs when it comes to submitting code.
And in the end, I don't see why using python on some projects would be a bad engineering practice
Google can definitely afford (in technical terms) to be a follower rather than a leader when it comes to Python.
And that’s without going into all the outside-of-g3 code (of which there is a metric ton, especially if you worked with any teams that deal with hardware or third-party/acquisition stuff).
A lot of people don't realize that the issues that python haters (myself included) have aren't generally about the look and feel of the language, but about how many sharp edges the language has for maintenance and scaling. Python 4 could fix all of these things if they ever did it.
Personal example - the fleet of hardware prototypes (that I used to work on) used for hardware-in-the-loop testing (basically the hardware version of CI/CD) was pretty much reliant on python. Anything that was compact enough to be accomplished by a script and generic enough (open this serial connection, write to that memory address, etc.), the de-facto default choice was almost always python.
But I fully agree with you otherwise, in a sense that I haven’t seen much of a gigantic python codebase consisting of a bunch of interconnected python modules, like you would see with other popular languages at Google (e.g., C++/Java/JS).
Google is also going all in on ML (or AI if you prefer).
These days if you are doing serious work, you simply use Java. Especially if you want something running for years. Java is really the only option you have.
A decade back I interviewed at a major telecommunications firm. Python was the new fashion then, they were trying to rewrite a fairly big Java code base to Python. Anyway I didn't get the job. My friend did. After a few years of this they realised, Python was not a serious alternative for an application of that nature. And abandoned it midway.
I know several other banks that have had a similar arc. Python is an amazing glue language and perfect for lots of automation and adhoc glue work. Its just not meant to be a serious alternative for long term, stable applications which are typically written in Java/C++.
Other languages like golang have come up in the past. While they are really good for smaller applications. They are just not there for something serious. 'Simplicity' has different meanings in different contexts. Either way, I think both Python and Java are here to stay and will be used for tasks where they are good at.
But we are now past the 'Python for everything' days.
It's a language that attracts casuals, but that does not mean it's incapable of being used for serious software engineering. The only scenarios where I wouldn't use python for a "serious backend thing" are scenarios in which there are dramatic cost/performance/etc consequences resulting from the overhead of using python which would be substantially reduced if using $lowLevelLanguage. Even then, there's always the option of outsourcing specific units of functionality to say, c++, anywhere the performance difference actually matters.
I would say that for the vast majority of use cases, acceptable performance could be easily achieved by simply writing better python.
Writing this reply brought to mind some absolutely atrociously inefficient ORM code I encountered in a python codebase recently. If you don't have an understanding of how to utilize SQL efficiently, it doesn't matter what language you're using to construct the SQL queries, the software engineering equivalent of warcrimes is possible in any language.
Python is an absolutely lovely language. It is not the 'perl of it's day'. In my experience, things get hairy when you start building bigger systems that require a lot of collaboration but you can probably do away with most of the pitfalls if you use type hints. Beyond that, it's main downside is performance but you would be shocked how little code you have to convert to C/C++ to remove bottlenecks.
You are right that most large orgs choose a language like java, but I'd also argue that C# and golang are good fits as well. They're fast, and they have a garbage collector. I suppose typescript / node could be in that same category but I steer away from that stack as a backend dev.
Whatever it's coded in, the back-end of reddit is pretty robust and well-done (maybe excluding the video hosting part and whatever new laggy crap they put in)
It's the new front-end of reddit that's a huge dumpster-fire.
The what, now?
Also, Google is IBM at this point, so I would expect a lot of IBM-like moves.