That's funny about your last line about Messenger. When I was at Facebook in 2020 and 2021 I thought the "Lightspeed" version of Messenger [1] was something of an engineering marvel. Specically the way it was centered around SQLite as the datastore, how the sever side could integrate with it, and how the UI was power by this reactive-style framework written in C. With lots of testing to keep binary size under control and things working reliably. And the DX was not bad for all these constraints. I think CG/SQL [2] is one of the few open source artifacts from this effort.
There were other reasonably nicely engineered things there, like some of the code-as-configuration things in PHP like the ORM and the structured logging. Where you just write and commit code and the databases and data warehouses just get set up automatically.
The choice to have a monolithic web stack at Facebook had some benefits. The latency from landing a diff to being in prod was a couple of hours, not matter what part of the site you touched. And given an arbitrary URL, there was a tool that used static analysis to tell you which file handled that request. Compared to Google where every damn thing is a micro-service with its own variable release schedule and different ways of doing request routing. Trying to figure out where a request goes is combination of dynamic tracing of the RPC trace behind it plus a bunch of grepping through the related code bases.
All that said, I was far away from doing real engineering at Facebook. I accidentally joined a growth team. Which meant our teams remit was churning out all kinds of experiments to see what we could to do to make our team's number go up. I did not find this type of work enjoyable and quit. So I have a narrow perspective.
Also to give these multinational corporations some benefit of the doubt, some of the way they operate is path-dependent. They have hundreds of millions of lines code. So they can get to a point where it makes sense to hire a bunch of compiler engineers to fork PHP and make the Hack language. Whereas a startup would almost certainly never create a new programming language to write their product. To take solutions of this context and apply them to the outside world might not make sense.
There were other reasonably nicely engineered things there, like some of the code-as-configuration things in PHP like the ORM and the structured logging. Where you just write and commit code and the databases and data warehouses just get set up automatically.
The choice to have a monolithic web stack at Facebook had some benefits. The latency from landing a diff to being in prod was a couple of hours, not matter what part of the site you touched. And given an arbitrary URL, there was a tool that used static analysis to tell you which file handled that request. Compared to Google where every damn thing is a micro-service with its own variable release schedule and different ways of doing request routing. Trying to figure out where a request goes is combination of dynamic tracing of the RPC trace behind it plus a bunch of grepping through the related code bases.
All that said, I was far away from doing real engineering at Facebook. I accidentally joined a growth team. Which meant our teams remit was churning out all kinds of experiments to see what we could to do to make our team's number go up. I did not find this type of work enjoyable and quit. So I have a narrow perspective.
Also to give these multinational corporations some benefit of the doubt, some of the way they operate is path-dependent. They have hundreds of millions of lines code. So they can get to a point where it makes sense to hire a bunch of compiler engineers to fork PHP and make the Hack language. Whereas a startup would almost certainly never create a new programming language to write their product. To take solutions of this context and apply them to the outside world might not make sense.
[1]: https://engineering.fb.com/2020/03/02/data-infrastructure/me...
[2]: https://cgsql.dev/