3 ms·

> Companies don’t let you use production code in any language you choose. You might be surprised. At most companies I've worked at (over a dozen) that's largel

> Companies don’t let you use production code in any language you choose. You might be surprised. At most companies I've worked at (over a dozen) that's largely true. Three jobs ago I was product architect for the entire company and spent a significant part of my time fighting just this kind of language proliferation. However, it's a very different story at a large company. Google seems to try pretty hard to keep this under control. OTOH, Facebook (where I work) prides itself on a "bottom up" "engineer driven" culture in which any such top-down prescriptivism doesn't fly. Don't know where the others fit in along that spectrum. The situation gets even murkier when code is inherited via acquisition or imported from open source. So such code often exists, whether it's "supposed to" or not.

pjmlp 6y ago
I had a couple of consulting projects which were basically porting non-official-language into one of the official internal stacks.
nindalf 6y ago
Interesting that you mention Facebook. A team at Facebook can choose whatever language they want, but they're on the hook for creating and maintaining libraries that talk to internal services (config, database etc). There's a tendency to choose one of the existing popular languages (C++, Python, Java) so you get those libraries for free. Therefore in practice, giving engineers the freedom to make their choices doesn't lead to an explosion in the number of languages used in production. An engineering team that can get started with a new, esoteric language without having to first build internal libraries is much more likely to try that new language.
- biztos 6y ago
  Particularly in the case of Java, wouldn't a lot of people be tempted to try languages that can use Java libraries? Like Scala or Kotlin for example?
  - nindalf 6y ago
    It’s not just libraries though. All software needs to build when invoked with “buck build” and it’s dependencies need to be specified in buck’s configuration format. Scala’s build is different enough that it can’t piggyback off Java here. This requirement is a stumbling block for many languages. For example when compiling Rust, no one actually calls rustc directly, everyone uses cargo. Effectively this meant someone had to reimplement cargo within buck.

pjmlp 6y ago

I had a couple of consulting projects which were basically porting non-official-language into one of the official internal stacks.

nindalf 6y ago

Interesting that you mention Facebook. A team at Facebook can choose whatever language they want, but they're on the hook for creating and maintaining libraries that talk to internal services (config, database etc). There's a tendency to choose one of the existing popular languages (C++, Python, Java) so you get those libraries for free. Therefore in practice, giving engineers the freedom to make their choices doesn't lead to an explosion in the number of languages used in production. An engineering team that can get started with a new, esoteric language without having to first build internal libraries is much more likely to try that new language.

biztos 6y ago
Particularly in the case of Java, wouldn't a lot of people be tempted to try languages that can use Java libraries? Like Scala or Kotlin for example?
- nindalf 6y ago
  It’s not just libraries though. All software needs to build when invoked with “buck build” and it’s dependencies need to be specified in buck’s configuration format. Scala’s build is different enough that it can’t piggyback off Java here. This requirement is a stumbling block for many languages. For example when compiling Rust, no one actually calls rustc directly, everyone uses cargo. Effectively this meant someone had to reimplement cargo within buck.