Engineering at Meta

While that is technically correct, they haven't been running vanilla PHP for quite some time - it's jitted into x86 and run natively on the machine. It's also pretty extensively optimized. And the VM that does the jitting is all C++. Their MySQL deployment is also an internal fork that's been heavily modified for scalability (storage/compute separation, sharding, RocksDB based storage engine instead of InnoDB, Raft for synchronous replication, etc.). Lots of really fantastic engineering work has gone into making their backend infra scale.

Some worthwhile references:

[1] https://engineering.fb.com/2016/08/31/core-data/myrocks-a-space-and-write-optimized-mysql-database/

[2] https://research.facebook.com/file/529018501538081/hhvm-jit-a-profile-guided-region-based-compiler-for-php-and-hack.pdf

[3] https://research.facebook.com/file/700800348487709/HHVM_ICPE_2023-(1).pdf

> Anytime Meta, Oracle, Microsoft, or anyone else announces another AI bit barn, a juicy power purchase agreement usually follows. Meta's mega DC being birthed in the bayou was announced alongside a 2.2GW gas generator plant — so much for those sustainability and carbon neutrality pledges.

Ouch, I grew up where Meta created its first data center and while it is very efficient (https://engineering.fb.com/2011/04/14/core-infra/designing-a-very-efficient-data-center/) I remember a more recent article about how they are zero net emissions (https://tech.facebook.com/engineering/2021/11/10-years-world-class-data-centers/). I wonder if they have kept that in this AI rush (along with most of the datacenter companies).

EDIT: a direct link to net zero for Meta: https://tech.facebook.com/ideas/2020/9/facebooks-path-to-net-zero/

This seems like offshoot tech from the Facebook messenger rewrite that claimed to lower as much as possible to the database for cross-platform sharing - https://engineering.fb.com/2020/03/02/data-infrastructure/messenger/

The proposed architecture seems cool, until you realize that instead of writing the languages your mobile devs know, instead you end up writing a lot of C (or generating a lot of C) to be cross platform, and the overlap of C developers and mobile / consumer-oriented developers in Silicon Valley is quite slim. I heard through the grapevine that the success of that rewrite was greatly overstated and it turned into a pain quite quickly.

All that said, I have a cross-platform app using SQLite… and I’m okay with C… maybe I can con the mobile team at my company into using this to ensure more job security?

Instagram's backend is a Django monolith "with several million lines of code and a few thousand Django endpoints" as of 2019, and the same architecture was used for Threads! They now run Django on a JIT-enabled fork of CPython, and leverage a ton of internal tooling for static analysis and strong typing.

https://instagram-engineering.com/types-for-python-http-apis-an-instagram-story-d3c3a207fdb7

https://engineering.fb.com/2023/09/07/culture/threads-inside-story-metas-newest-social-app/

https://engineering.fb.com/2022/05/02/open-source/cinder-jits-instagram/

https://engineering.fb.com/?s=django

Django is also excellent for e-commerce with projects like https://github.com/saleor/saleor - or you can roll your own e-commerce system quite easily, which we've done at my travel startup.

Not quite. According to a more recent article, Facebook's PHP, Hack, is still a primary language:

> For business logic and relatively stateless applications, the Hack ecosystem has the highest level of automation and support at Meta and is the recommended language.

On a related note, their Rust usage has grown significantly:

> For performance-sensitive back-end services, we encourage C++ and Rust. Rust is a new addition to this list. There’s a rapidly increasing Rust footprint in our products and services, and we’re committing to Rust long-term and welcome early adopters. For CLI tools, we recommend Rust. This is a new recommendation for this year.

https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta

> At Meta we call an individual set of changes made to the codebase a “diff.”

I don't work at Meta and I still don't have any idea which of you is right.

A commit would satisfy the description above.

As would a pull/merge request, which the image in the article perhaps fits better: https://engineering.fb.com/wp-content/uploads/2022/11/Code-Reviews-at-Meta-image2.png

Of course, it's possible to review each individual commit as well, but who does that?

I know that some folks love to mess around as much as they need in their local branches, commit often and then do an interactive rebase, to maybe end up with one or just a few commits that can then be the basis for a pull/merge request, then the difference matter a little bit less.