Bento: Jupyter Notebooks at Meta

Post by landedgentry » Wed, Sep 18, 2024, 7:13 PM UTC

extr wrote: post #8

Random_BSD_Geek wrote: post #4

Earlier quoted context omitted.

Polar opposite of my experience. To achieve the technical equivalent of changing a lightbulb, spend the entire day wrangling a dozen tools which are broken in different ways, maintained by teams that no longer exist or have completely rolled over, only to arrive at the finish line and discover we don't use those lightbulbs anymore. Move things and break fast.

Yeah 100%. I found it immensely frustrating to be using tools with no community (except internally), so-so documentation, and features that were clearly broken in a way that would be unacceptable for a regular consumer product. If you have a question or error not covered by an internal search or documentation, good luck, you'll need it. Literally part of the reason I left the company.

Post by grantsucceeded » Wed, Sep 18, 2024, 7:27 PM UTC

ipsum2 wrote: post #36

JohnMakin wrote: post #23

Earlier quoted context omitted.

One of the crazier things a L4 meta colleague of mine told me, that I still don’t believe entirely, is that meta pretty much has their own fork of everything , even tools like git. is this true?

Yep. Zeus is a fork of Zookeeper, Hack is a fork of PHP, etc. It's usually needed to make it work with the internal environment. The few things that don't have forks are usually the open source projects like React or PyTorch, but even those have some custom features added to make it work with FB internals.

Post by kridsdale3 » Wed, Sep 18, 2024, 7:47 PM UTC

moandcompany wrote: post #41

web3aj wrote: post #2

The internal tools at Meta are incredible tbh. There’s an ecosystem of well-designed internal tools that talk to each other. That was my favorite part of working there.

My opinion: Many Meta tools and processes seem like they were created by former Googlers that sought to recreate something they previously had at Google, during the Google->FB Exodus, but also changed aspects of the tool that were annoying or diverged from their needs. This is not a bad thing. Since Bento doesn't appear to be usable by the public, aparallel version of this that people can get a feel for cross-tool in…

Post by zhengyi13 » Wed, Sep 18, 2024, 8:11 PM UTC

gcr wrote: post #45

ipsum2 wrote: post #36

Earlier quoted context omitted.

Yep. Zeus is a fork of Zookeeper, Hack is a fork of PHP, etc. It's usually needed to make it work with the internal environment. The few things that don't have forks are usually the open source projects like React or PyTorch, but even those have some custom features added to make it work with FB internals.

This is also how things work at Google. Google also maintains a monorepo with "forks" of all software that they use. History diverges, but is occasionally synchronized for things like security updates etc.

Post by [deleted] » Wed, Sep 18, 2024, 8:39 PM UTC

kridsdale3 wrote: post #56

tqi wrote: post #28

Earlier quoted context omitted.

Facebook actually doesn't use git, they use mercurial ( https://graphite.dev/blog/why-facebook-doesnt-use-git ). That decision is also illustrative of why they end up forking most things - Facebook's usage patterns at the far extreme end for almost any tool, and things thats are non-issues with fewer engineers or a smaller codebase become complete blockers.

Yes when I used to talk about this to interviewees, I described that every tool people commonly use is somewhere on the Big-O curves for scaling. Most of the time we don't really care if a tool is O(n) or O(10 n) or whatever. At Meta, N tends to be hundreds of billions to hundreds of trillions. So your algorithm REALLY matters. And git has a Big-O that is worse than Mercurial, so we had to switch.