When I worked at NetApp, this was a problem there too.
IIRC, the fix was for directory entries were later stored in sorted buckets (aka hash map) and only the corresponding bucket for the file name would get locked. This reduced scope of lock for atomic operations like rename and also allowed faster lookup instead of O(n) based scan.
Assuming Google uses gRPC and protobufs extensively, I can only imagine a chaotic polyglot environment where buffers are copied and transformed very often.
I work at a fairly large Python shop using libraries in C. Cost of FFI is non-trivial, memory management and moving data is the usual culprit.
I work at a fairly large Python shop and we have some real performance problems with Python.
Most real world software will use many core libraries implemented in C/C++ for doing the heavy lifting. Just the FFI and creating all those Python objects makes it slow.
Python is a great language for prototyping and/or usage as a glue code.
Personally, I am more inclined to use Go for anything quick and performant. If Carbon language becomes a reality, I would bet on that since it allows seamless interoperability with C++ (and there is a large existing eco system). Else, time to learn Rust.
Over a video call, the interviewer asked a coding question and immediately put on headphones and I am sure was listening to music. There was no dialogue and I had to use visual cues to get his attention.
I coded using C++ and pass by reference. He had never seen it in his life. He refused to believe modification on a reference would modify the value in the calling function!
I hoping he would be willing to discuss or run the code, this was a total let down.
Having gone through a very similar journey, it took around 2 years for me to completely disassociate myself from a specific programming language. It was more a 'me' problem since I leaned on to a programming language rather than a problem domain.
I still consider myself a systems programmer mostly writing glue code in Go/Python and jumping into C/C++ as required to improve performance when required.
Apple does not seem to think this is a problem. Their default Message app supporting both SMS/text and iMessage. They have an opt-in to send via SMS if iMessage fails and this gives it more reliability too.