Ask HN: Are you limited in what language you can write in at FAANG?

Google at least is pretty strict about it for server-side software. You're going to be writing in C++, Java, Python, or Go (IIRC even Node.js is forbidden, though they may've relaxed that since I left). For client-side software you use whatever the native language is for the platform - that's Java (and apparently now Kotlin) for Android, Objective-C for iOS/Mac (I'd heard there was an effort to get Swift approved, but it was well after my time), and C# for Windows. Google has a fair number of proprietary languages I won't go into too - the big public one is Sawzall, but that's now deprecated in favor of Go. Some special projects can get special dispensation to use other languages (eg. there was a team that used Haskell while I was there, and a lot of the data scientists use R for prototyping their models), and you can generally use whatever you want for throwaway prototypes that run only on your machine, but you won't get any support from Google tooling if you use something that isn't one of the official languages.

IIUC most Apple teams write code for one of their hardware platforms, so they use the native languages supported by it - Objective C and Swift, with a fair amount of system-level C and C++ code too.

Amazon I've heard is more open; teams can use whatever they want, because everything is exposed through a big SOA anyway.

No idea about Facebook. They hired a bunch of ex-Googlers, so I'm guessing they largely copied the Google model but with different starting languages (eg. they started with PHP then evolved it through HipHop and Hack). Thrift supports a lot more languages than gRPC though, so that may indicate they allow more languages internally.

> If you wanted for example to write a microservice or script in Ruby

Not FAANG per se, but at Uber, you wouldn't be allowed to use Ruby for a new microservice. The only exception to language blacklists is if you're fixing issues in a fork of a 3rd party tool that is already written in an non-official language (e.g. homebrew or phabricator). Official languages get support from platform/infra teams (in terms of libraries, greenkeeping, etc) and are setup for things like security guideline compliance.

Our official stacks are Java (backend), Go (backend), Swift (ios), Java (android) and JS/Node (web).

Of course, there will always be unofficial languages, such as the odd library written in C++ or the odd project written w/ react native or legacy code written in python, but those are minorities, in terms of number of projects.

You're qenerally quite limited in the languages / protocols you can use at any decent shop.

It's not about oppressive top-down control or anything like that. It's a matter of choice. And the better shops tend to make these kinds of choices... very carefully.

If you agree with their choices - then maybe they're great places for you. If you don't - to the extent that you wouldn't want to work there - that's also fine (and they'd probably respect that).

But those "anything goes" shops where you can write a microservice in whatever language you fancy? Those are the places you definitely want to stay away from.

In Fred Brook's book, The Mythical Man Month, there is a chapter on "Adding People to a Late Project Makes it Later". The reason given is the new people have to be brought up to speed (trained) on the project by people already working on a project. This is magnified if the project uses a different programming language, libraries, OS, database than other projects. Multiple programming languages: just say no.

I would think it's highly dependant your team/product and not a global company wide policy. If it can run in a container and is 12-factor there should be no problems deploying and orchestrating it