
Ask HN: Are you limited in what language you can write in at FAANG? - paulz_
Hello I was having a discussion with a friend and found that one of my assumptions about how FAANG companies tend to operate may actually not be true.<p>Hoping someone from Facebook or another could comment.<p>Each tech company has it&#x27;s preferred languages - but I&#x27;m wondering how strict those guidelines are and how far they extend. If you wanted for example to write a microservice or script in Ruby at Facebook would you be allowed to? Or are the guidelines more strict for what languages you&#x27;re allowed to use?<p>Thanks in advance for taking the time to read &#x2F; respond.
======
nostrademons
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.

------
lhorie
> 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.

~~~
drugme
Without getting into a language debate per se - what does Uber have against
Python?

(If indeed, as it sounds, there's an across-the-board ban against it).

~~~
lhorie
The decision was from before my time, so I'm not sure what the specifics are.
As I understand, the main motivations to move away from Python were that
Java/Go provided better performance (e.g. memory usage) and reliability (read:
static typing)

~~~
drugme
Fair enough - I just like to understand where people are coming from on this
issue.

~~~
lhorie
On a side note, my brother works at Duolingo and wrote an article detailing a
very similar migration (from Python to Scala) here:
[http://making.duolingo.com/rewriting-duolingos-engine-in-
sca...](http://making.duolingo.com/rewriting-duolingos-engine-in-scala) and
lists very similar reasons for the switch.

------
drugme
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.

------
moondev
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

------
RNeff
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.

