4 ms·

I've worked for both Facebook and Google so can make informed comments on this with two exceptions: Buck2 came after I left and I'm honestly not sure what sapli

by cletus 3y ago

I've worked for both Facebook and Google so can make informed comments on this with two exceptions: Buck2 came after I left and I'm honestly not sure what sapling is. Is it some Mercurial-like re-implementation a bit like how Google's Piper is a re-implementation of Perforce? The tl;dr is that Google's developer tooling and ifnrastructure is superior in almost every way. Examples: - When I started at FB we used Nuclide, an internal fork of the Atom editor. While I was there it was replaced by VS Code. It's better but honestly they should've built their tooling off of Jetbrains products. Jetbrains make IDEs. VS Code is a text editor like vim or emacs. There's a massive difference; - Buck should've been killed and replaced by Bazel. I can't speak to Buck2 but this seems like a pointless investment; - Thrift should be killed and replaced with gRPC/Protobuf. Same deal; - FB's code search is just grep. It's literally called BigGrep. Grep can get you pretty far but it's just not the same as something with semantic understanding. Google has codesearch, which does understand code, and it's miles ahead. This has all sorts of weird side effects too, like Hack code at FB can't use namespaces or type aliasing because then grep wouldn't be able to find it. When there were name conflicts you'd sometimes be forced to rename something to get something to compile; - Tupperware (FB's container system) is a pale shadow of Borg; - Pushing www code at FB is a very good experience overall. You commit something and it'll get pushed to production possibly within an hour or two or, at busier times, it might take to the next day. This requires no release process or manual build. It's basically automatic; Google's build and release process tends to be way more onerous; - The big achillees heel in FB's www code is that it is one giant binary. There's no dependency declaration at all. This means there's an automatic system to detect if your change affects other things and that process often fails. This leads to trunk getting broken. A lot. - Because of the above problem there is a system to determine what tests to run for a given commit. This is partially about what the affected components are but also longer-running tests aren't run-on-commit and often those tests would've found the problem. There is no way to say "if this file is modified, run this test". That's a huge problem; - FB has a consistent system for running experiements and having features behind flags (ie gatekeeper). This wasn't the case when I was at Google. It may well have changed; - Creating a UI for an internal tool or a new page is incredibly easy at FB. There are standard components with the correct styling for everything. If you want to write an internal tool, you can start at 9am and have it in production by noon if it's not terribly complicated; - The build system for C++ at FB is, well, trash. For Buck (and Bazel), the build system creates a DAG of the build artifacts to decide what to build. FB C++ might take 2 minutes just to load the DAG before it builds anything. This is essentially instant at Google because a lot of infrastructure has been built to solve this problem. This is a combination of SrcFS and ObjFS. Incremental builds at FB to run tests doesn't really work as a workflow; - All non-www builds at FB are local builds. Nothing at Google (on Google3 at least) is built locally, including mobile apps. This is way faster because of build artifact cachcing and you have beefier build machines. - There tends to be less choices as to what to use for FB code (eg storage systems). I consider this largely a good thing. You will typically find 5 different way of doing anything at Google and then need to consider why. You will often find different teams solving the same problem in slightly different ways or even the exact same way. - There are people at FB who work on system-wide refactors (eg Web security, storage). These people can often only commit their diffs that might touch thousnads of files on weekends. - A lot of generated code is committed at FB that isn't at Google. This exacerbates the previous problem. FB has a ton of partially and completely generated files that mean a change to the generating code has a massive effect. At Google, for example, the protobuf generated code is genearted at build time and isn't in the repo. There's probably more but that's what comes to mind.

dmoy 3y ago
> FB's code search is just grep. It's literally called BigGrep. Grep can get you pretty far but it's just not the same as something with semantic understanding. Google has codesearch, which does understand code, and it's miles ahead. Pedantically, codesearch is also grep. But codesearch calls out to Kythe (nee Grok) which has a semantic graph of the code. But.... internally everyone thinks the Kythe team is just codesearch anyways, so that's about right lol. Kythe is partially open source, but critically a lot of the postprocessing to get it to work at massive monorepo scale is not, so FB would have a bunch of work to do to replicating it. Also we don't have a PHP indexer, because nobody's written one.
jeffbee 3y ago
> A lot of generated code is committed at FB that isn't at Google. This exacerbates the previous problem. FB has a ton of partially and completely generated files that mean a change to the generating code has a massive effect. At Google, for example, the protobuf generated code is genearted at build time and isn't in the repo. What's nice about this scheme at Google is all manner of generated code is indexed, so you can navigate up and down the caller-callee graph between artisanal code and generated code. Really works well.
aseipp 3y ago
Buck2 is IMO much better than even Bazel is from a design POV, because it actually cleanly separates all user rules from the build engine, and has a coherent modern design around a sound theoretical basis. Neil, one of the leads and author of this post, has written many build systems, so it's not like he's unaware of Bazel; his taxonomy of build systems and ones like Bazel in "Build Systems a la Carte" is worth reading even for Bazel users. It also has a snappy UX and is fast on the command line, which Bazel still lags at a bit. Bazel has all the mindshare, though, and a lot of good features and libraries. But Buck2 is in a different league from Buck1 completely, and in many ways even from Bazel, IMO. Even then, it's not like rewriting a billion lines of BUCK files to use Bazel was even practical. Realistically any solution had to have a direct migration path from Buck1 without rewriting everything. I don't even work there, this is just pretty obvious from the design constraints and talking with the dev team, though. Frankly, I'm pretty impressed they were both able to meet the goals they had (migration from Buck1, better performance, more extensible), while still jam-packing the thing full of good design decisions and features like they have. It's good work. (I am a pretty happy, non-Facebook user of Buck2 already, FWIW.)

by cletus 3y ago

dmoy 3y ago

> FB's code search is just grep. It's literally called BigGrep. Grep can get you pretty far but it's just not the same as something with semantic understanding. Google has codesearch, which does understand code, and it's miles ahead. Pedantically, codesearch is also grep. But codesearch calls out to Kythe (nee Grok) which has a semantic graph of the code. But.... internally everyone thinks the Kythe team is just codesearch anyways, so that's about right lol. Kythe is partially open source, but critically a lot of the postprocessing to get it to work at massive monorepo scale is not, so FB would have a bunch of work to do to replicating it. Also we don't have a PHP indexer, because nobody's written one.

jeffbee 3y ago

> A lot of generated code is committed at FB that isn't at Google. This exacerbates the previous problem. FB has a ton of partially and completely generated files that mean a change to the generating code has a massive effect. At Google, for example, the protobuf generated code is genearted at build time and isn't in the repo. What's nice about this scheme at Google is all manner of generated code is indexed, so you can navigate up and down the caller-callee graph between artisanal code and generated code. Really works well.

aseipp 3y ago

Buck2 is IMO much better than even Bazel is from a design POV, because it actually cleanly separates all user rules from the build engine, and has a coherent modern design around a sound theoretical basis. Neil, one of the leads and author of this post, has written many build systems, so it's not like he's unaware of Bazel; his taxonomy of build systems and ones like Bazel in "Build Systems a la Carte" is worth reading even for Bazel users. It also has a snappy UX and is fast on the command line, which Bazel still lags at a bit. Bazel has all the mindshare, though, and a lot of good features and libraries. But Buck2 is in a different league from Buck1 completely, and in many ways even from Bazel, IMO. Even then, it's not like rewriting a billion lines of BUCK files to use Bazel was even practical. Realistically any solution had to have a direct migration path from Buck1 without rewriting everything. I don't even work there, this is just pretty obvious from the design constraints and talking with the dev team, though. Frankly, I'm pretty impressed they were both able to meet the goals they had (migration from Buck1, better performance, more extensible), while still jam-packing the thing full of good design decisions and features like they have. It's good work. (I am a pretty happy, non-Facebook user of Buck2 already, FWIW.)