6 ms·

Companies don’t let you use production code in any language you choose. There is usually a discussion. I was in a Perl shop many years ago and introducing Pyth

Companies don’t let you use production code in any language you choose. There is usually a discussion. I was in a Perl shop many years ago and introducing Python was strongly discouraged.

notacoward 6y ago
> 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.
xixixao 6y ago
Parent mentioned FAANG and to my knowledge of FB, Google and Apple, they all let their teams choose whatever is the best tool for the job, including new languages (including developing new languages, for example Reason).
- benreesman 6y ago
  I was at FB from 2011-2018, and things may have changed since, but at that time it required serious buy-in to do anything that wasn’t in Hack, C++, Python, Java, or one of the mainstream mobile languages (JS/Swift/etc.) There were pilots of various things that made it into prod (Haskell had a modest niche and I spent a year on that team). When you think about the dizzying array of touch points (logging, metrics/monitoring, service publishing and discovery, and on and on) that even the smallest component needs, the absurd wealth of libraries better than anything in open source, the standards-committee level expertise an email away that you have in one of the mainstream languages it becomes clear that you’d need more than a large incremental improvement in the language itself to break even. The thing that might get Rust over the threshold isn’t memory safety (modern C++ with hardcore warnings-as-errors static analysis and automated ASAN/TSAN/UBSAN runs is rather solid), it’s build times. Build times are the thing that will kill C++ unless they can come up with a modules solution that is cheaper to migrate than rewriting everything. At some point you just can’t fucking build the thing no matter how many boxes you throw at it. Rust may have a window of opportunity before C++ finds an answer on that.
  - notacoward 6y ago
    > When you think about the dizzying array of touch points Thrift generators and/or a decent FFI can resolve a lot of those. Yes, other teams might try to make noise and threaten not to support you, but I've yet to see one go so far as to blacklist a service because they disagreed with its implementation choices (including language). > libraries better than anything in open source Only in their authors' minds, in most cases. NIH at its worst. > Build times are the thing that will kill C++ Certainly up there, and I wish more people realized this. Every test/deploy pipeline is an order of magnitude slower than it should be because of this, and perpetuating it is part of why I think those libraries aren't really better. In fact many of them make it worse, because they're the most aggressive users of features that increase compilation time.
swagonomixxx 6y ago
I've noticed that at smaller shops - IME - choosing a new language wasn't frowned upon. However once you start getting into very heavily used production services, choosing a different platform becomes increasingly difficult.
thrwn_frthr_awy 6y ago
This is not the case at Apple.
gautamdivgi 6y ago
I work for a large communications company. We had this top-down approach for a really long time. It doesn't work too well. Essentially you're blocked from using something until its a "standard" at the company and the larger the development team the longer they take to converge on a "standard". The standards still exist now, but they're more guidelines. If you use the standards (Python/Java) you have a lot of existing tooling that you can utilize to get your project off the ground (e.g. APM tooling, docker build templates, SDK for internal apps, etc.). You can use other languages if you want to but you're going to have to do the tooling yourself. So, although Go isn't a "standard" for app development it is used to create k8s operators, etc.

Companies don’t let you use production code in any language you choose. There is usually a discussion. I was in a Perl shop many years ago and introducing Python was strongly discouraged.

notacoward 6y ago

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

xixixao 6y ago

Parent mentioned FAANG and to my knowledge of FB, Google and Apple, they all let their teams choose whatever is the best tool for the job, including new languages (including developing new languages, for example Reason).

benreesman 6y ago
I was at FB from 2011-2018, and things may have changed since, but at that time it required serious buy-in to do anything that wasn’t in Hack, C++, Python, Java, or one of the mainstream mobile languages (JS/Swift/etc.) There were pilots of various things that made it into prod (Haskell had a modest niche and I spent a year on that team). When you think about the dizzying array of touch points (logging, metrics/monitoring, service publishing and discovery, and on and on) that even the smallest component needs, the absurd wealth of libraries better than anything in open source, the standards-committee level expertise an email away that you have in one of the mainstream languages it becomes clear that you’d need more than a large incremental improvement in the language itself to break even. The thing that might get Rust over the threshold isn’t memory safety (modern C++ with hardcore warnings-as-errors static analysis and automated ASAN/TSAN/UBSAN runs is rather solid), it’s build times. Build times are the thing that will kill C++ unless they can come up with a modules solution that is cheaper to migrate than rewriting everything. At some point you just can’t fucking build the thing no matter how many boxes you throw at it. Rust may have a window of opportunity before C++ finds an answer on that.
- notacoward 6y ago
  > When you think about the dizzying array of touch points Thrift generators and/or a decent FFI can resolve a lot of those. Yes, other teams might try to make noise and threaten not to support you, but I've yet to see one go so far as to blacklist a service because they disagreed with its implementation choices (including language). > libraries better than anything in open source Only in their authors' minds, in most cases. NIH at its worst. > Build times are the thing that will kill C++ Certainly up there, and I wish more people realized this. Every test/deploy pipeline is an order of magnitude slower than it should be because of this, and perpetuating it is part of why I think those libraries aren't really better. In fact many of them make it worse, because they're the most aggressive users of features that increase compilation time.

swagonomixxx 6y ago

I've noticed that at smaller shops - IME - choosing a new language wasn't frowned upon. However once you start getting into very heavily used production services, choosing a different platform becomes increasingly difficult.

thrwn_frthr_awy 6y ago

This is not the case at Apple.

gautamdivgi 6y ago

I work for a large communications company. We had this top-down approach for a really long time. It doesn't work too well. Essentially you're blocked from using something until its a "standard" at the company and the larger the development team the longer they take to converge on a "standard". The standards still exist now, but they're more guidelines. If you use the standards (Python/Java) you have a lot of existing tooling that you can utilize to get your project off the ground (e.g. APM tooling, docker build templates, SDK for internal apps, etc.). You can use other languages if you want to but you're going to have to do the tooling yourself. So, although Go isn't a "standard" for app development it is used to create k8s operators, etc.