Meta formalizes its server-side language lineup

Meta has published the internal guidance its engineers use when picking a programming language for server-side work. The list — Hack, C++, Rust, and Python — represents the languages the company fully supports for new projects, with Rust being the most recent addition.

The distinction matters internally. A supported language at Meta comes with guarantees around tooling, debugging, build and deployment, plus access to core libraries and interoperability. Engineers are expected to keep using that language, not migrate off it. Anything outside that short list is community supported: usable, but with fewer guarantees, and teams choosing such a language accept the maintenance burden themselves. For most new applications, Meta steers engineers away from community-supported options unless the team already has deep investment in them.

Choosing by workload

Meta’s recommendations are workload-specific rather than one-size-fits-all:

  • C++ and Rust are the picks for performance-sensitive back-end services. Rust’s footprint inside Meta has been growing quickly, and the company says it is committing to the language long-term.
  • Rust is also now the recommended choice for CLI tools — a guidance update that landed this year.
  • Hack remains the default for business logic and relatively stateless applications, where its ecosystem offers the highest degree of automation and support internally.
  • Python continues to be heavily supported, especially for data science, ML workloads, and Instagram, where Meta keeps investing in the developer experience.
  • Java, Erlang, Haskell, and Go are supported only for specific use cases and are not broadly recommended.

Why the bar for new languages is high

Meta is deliberately conservative about expanding the supported list. The cost of supporting a language at Meta scale is spread across the whole engineering organization, not just the teams that use it. Several factors drive that cost:

  • Core libraries. Fewer languages means less burden on shared libraries that many services depend on.
  • Security and privacy. A fragmented stack makes it harder to build security and privacy features consistently across services.
  • Operational risk. Incident response depends on engineers being able to read, understand, and debug any service in production. Avoiding fragmentation keeps that expertise reliable.
  • Critical mass of experts. Meta needs enough engineers with deep knowledge of each supported language.
  • Developer experience. Supported languages get dedicated work on IDE integration, build speed, debugging, and related tooling.

A poor language choice is expensive in time and productivity, so each candidate gets heavy scrutiny before being adopted. Rust earned that examination: since Meta began using it in 2021, the number of Rust projects inside the company has accelerated. Adding Rust to the supported list signals Meta’s long-term commitment to the language’s ecosystem, giving engineers another tool with the same guarantees they expect from the other fully supported languages.