4 ms·

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 languag

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.
  - benreesman 6y ago
    There was a time when F14 and Swiss were internally available and not in open source. You think there aren’t other things that aren’t open source yet that those guys have? folly/absl/gtest/glog/tf/pytorch/etc/etc aren’t perfect, but they have stuff that no one else has, and they had it before Github did. “The guy who wrote the book” so to speak often works at one of these places, and while some of the stuff makes it into open source some of the time, some of it doesn’t. Google gets Borg, OSS gets k8s. Citing NIH is kinda flamey as an alternative to citing examples IMHO.
    - notacoward 6y ago
      The "g" in "gtest" and "glog" doesn't stand for Facebook, so I don't even know why you include those. Folly is open source. PyTorch is open source. You can't be "better than anything" in a category that you're in yourself. Yes, there's stuff in folly that's available internally before it's open sourced. Yes, some of it's good stuff. Some of it's so Facebook-specific that it's only useful inside, or it's just plain junk that the rest of the world is spared. After eight years working solely on open source at Red Hat, I've seen nothing particularly exceptional about the quality of Facebook's proprietary code. People who have no experience beyond school see something new, they think it's the bees' knees, surely they think they must be blessed to work at a place where such things are created ... but they're not uniquely blessed. There are people all over this industry pushing the state of the art. Facebook engineers think that Facebook hires the best people in the world, but people at Google think that they do, and people at Apple think that they do, and people at random startups think that they do. Not without reason in any case, but still incorrectly. It's a common kind of sampling error. The reality is that there's good and bad code everywhere, and the larger a company is the more it tends to regress toward the mean.
      - benreesman 6y ago
        I mention Swiss/glog/gtest/tf because I was always talking about FANG companies, high finance (Renaissance, Jump, etc.) and to a lesser extent some of the unicorns. You know, the elite places with boundless budgets and counter-productively high technical hiring bars. Hence “these places”. When it comes to “who hires the best?” it gets a bit fuzzy and anecdotal, but roughly RenTech hires the best. Google hires the best on average in the valley, though FB has made multiple deep cuts through their top quartile with money, which is why so much Facebook stuff seems like “close but not quite” Google stuff. Other massively resourced companies also get quite good people, and there are plenty of little pockets of genius at various universities and think tanks (INRIA comes to mind). I don’t know exactly why a tangent about having F14FastMap or MPMCQueue (and proprietary friends) before the rest of the world has evoked such a strong reaction in a point about C++ making sense at MegaCorp du jour, but calling people who think the cutting-edge internal stuff at the elite companies is a plus for C++ new grads is where I step off this train. I share your frustration with the consolidation of power, money, and talent at a small number of elite institutions to some degree, but you can take it out on someone else.
- secondcoming 6y ago
  Doesn't Rust have build time issues too?
  - steveklabnik 6y ago
    Yes, it is slower than we'd like. Comparisons to C++ are really complex though, with some people thinking they're better, and some thinking they're worse. There's a lot of details here, and we'll also see how the Rust work shakes out, as well as C++20 modules.
  - benreesman 6y ago
    I haven’t done enough with Rust to speak conclusively to that, I imagine this comment will get a sibling from someone better informed. Rust can at least in principle do better than “recursive textual substitution of massive amounts of redundant code into translation units” and I imagine the Rust leadership is probably sharp enough to know that this is the chink in the armor of an otherwise rapidly improving safety and usability story for a deeply entrenched incumbent.
- jldugger 6y ago
  I promise you the antibodies that prevent people from using one of the approved languages don't have permissions or disclosures at Apple to actually implement any language bans.
  - Bahamut 6y ago
    I laughed, this is very true.
- higerordermap 6y ago
  LoL. As if rust build times are much better than C++. The rust compiler / internals section has very few experts. The compiler produces poor LLVM IR and compile times are as poor as C++ __Despite having modules__. Basic performance improvements like ```TrustedLen``` took a lot of time to surface despite everyone touting "zero cost abstractions". Given the hype rust is getting by ruby/js hipsters learning it, you would think they would have a better, faster compiler backend instead of depending on LLVM cruft which can't even utilize rust's Mutable Xor Shared guarantees.
  - SomeoneFromCA 6y ago
    C++ code, CAN be in theory rewritten to compile fast. Small, trivial C++ code compiles blazingly fast even on very old hardware. I have an old Sandy Bridge Celeron, and a 5000 lines of C++ compiles in 5 seconds, with optimization on. Even 100 lines of Rust takes longer than that to compile.
    - higerordermap 6y ago
      Yeah, even considering similarly template heavy C++, rust compiler generates large amounts of LLVM IR and crate-as-compilation-unit doesn't help.
hocuspocus 6y ago
That's not really what I hear from friends at Google. Lumping Apple together with software companies illustrates well why using this acronym out of context is silly. Apple is incredibly silo'ed in comparison. Teams have a lot more freedom since they don't need to reuse internal infrastructure so much.

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.
- benreesman 6y ago
  There was a time when F14 and Swiss were internally available and not in open source. You think there aren’t other things that aren’t open source yet that those guys have? folly/absl/gtest/glog/tf/pytorch/etc/etc aren’t perfect, but they have stuff that no one else has, and they had it before Github did. “The guy who wrote the book” so to speak often works at one of these places, and while some of the stuff makes it into open source some of the time, some of it doesn’t. Google gets Borg, OSS gets k8s. Citing NIH is kinda flamey as an alternative to citing examples IMHO.
  - notacoward 6y ago
    The "g" in "gtest" and "glog" doesn't stand for Facebook, so I don't even know why you include those. Folly is open source. PyTorch is open source. You can't be "better than anything" in a category that you're in yourself. Yes, there's stuff in folly that's available internally before it's open sourced. Yes, some of it's good stuff. Some of it's so Facebook-specific that it's only useful inside, or it's just plain junk that the rest of the world is spared. After eight years working solely on open source at Red Hat, I've seen nothing particularly exceptional about the quality of Facebook's proprietary code. People who have no experience beyond school see something new, they think it's the bees' knees, surely they think they must be blessed to work at a place where such things are created ... but they're not uniquely blessed. There are people all over this industry pushing the state of the art. Facebook engineers think that Facebook hires the best people in the world, but people at Google think that they do, and people at Apple think that they do, and people at random startups think that they do. Not without reason in any case, but still incorrectly. It's a common kind of sampling error. The reality is that there's good and bad code everywhere, and the larger a company is the more it tends to regress toward the mean.
    - benreesman 6y ago
      I mention Swiss/glog/gtest/tf because I was always talking about FANG companies, high finance (Renaissance, Jump, etc.) and to a lesser extent some of the unicorns. You know, the elite places with boundless budgets and counter-productively high technical hiring bars. Hence “these places”. When it comes to “who hires the best?” it gets a bit fuzzy and anecdotal, but roughly RenTech hires the best. Google hires the best on average in the valley, though FB has made multiple deep cuts through their top quartile with money, which is why so much Facebook stuff seems like “close but not quite” Google stuff. Other massively resourced companies also get quite good people, and there are plenty of little pockets of genius at various universities and think tanks (INRIA comes to mind). I don’t know exactly why a tangent about having F14FastMap or MPMCQueue (and proprietary friends) before the rest of the world has evoked such a strong reaction in a point about C++ making sense at MegaCorp du jour, but calling people who think the cutting-edge internal stuff at the elite companies is a plus for C++ new grads is where I step off this train. I share your frustration with the consolidation of power, money, and talent at a small number of elite institutions to some degree, but you can take it out on someone else.
secondcoming 6y ago
Doesn't Rust have build time issues too?
- steveklabnik 6y ago
  Yes, it is slower than we'd like. Comparisons to C++ are really complex though, with some people thinking they're better, and some thinking they're worse. There's a lot of details here, and we'll also see how the Rust work shakes out, as well as C++20 modules.
- benreesman 6y ago
  I haven’t done enough with Rust to speak conclusively to that, I imagine this comment will get a sibling from someone better informed. Rust can at least in principle do better than “recursive textual substitution of massive amounts of redundant code into translation units” and I imagine the Rust leadership is probably sharp enough to know that this is the chink in the armor of an otherwise rapidly improving safety and usability story for a deeply entrenched incumbent.
jldugger 6y ago
I promise you the antibodies that prevent people from using one of the approved languages don't have permissions or disclosures at Apple to actually implement any language bans.
- Bahamut 6y ago
  I laughed, this is very true.
higerordermap 6y ago
LoL. As if rust build times are much better than C++. The rust compiler / internals section has very few experts. The compiler produces poor LLVM IR and compile times are as poor as C++ __Despite having modules__. Basic performance improvements like ```TrustedLen``` took a lot of time to surface despite everyone touting "zero cost abstractions". Given the hype rust is getting by ruby/js hipsters learning it, you would think they would have a better, faster compiler backend instead of depending on LLVM cruft which can't even utilize rust's Mutable Xor Shared guarantees.
- SomeoneFromCA 6y ago
  C++ code, CAN be in theory rewritten to compile fast. Small, trivial C++ code compiles blazingly fast even on very old hardware. I have an old Sandy Bridge Celeron, and a 5000 lines of C++ compiles in 5 seconds, with optimization on. Even 100 lines of Rust takes longer than that to compile.
  - higerordermap 6y ago
    Yeah, even considering similarly template heavy C++, rust compiler generates large amounts of LLVM IR and crate-as-compilation-unit doesn't help.

hocuspocus 6y ago

That's not really what I hear from friends at Google. Lumping Apple together with software companies illustrates well why using this acronym out of context is silly. Apple is incredibly silo'ed in comparison. Teams have a lot more freedom since they don't need to reuse internal infrastructure so much.