Meta developer tools: Working at scale • Hacker News Board

Re: Meta developer tools: Working at scale

#161

Post by jsnell » Wed, Jun 28, 2023, 9:18 PM UTC

cletus wrote: post #133

howinteresting wrote: post #108

Earlier quoted context omitted.

A lot of this used to be true but is no longer so. Buck2 is much faster than Buck and pretty great for the set of problems it's trying to solve. (I'm skeptical that the corner that Meta has painted itself into is good , but assuming that that can't change, buck2 is great.) Remote builds are common now, from what I've heard. Sapling is the name for Meta's fork of Mercurial. Piper is not a reimplementation of Perforce,…

> Piper is not a reimplementation of Perforce, by the way. Yes, it is. You are probably confusing Piper, the internal name for the VCS, with Google Piper [1], which is a completely separate and unrelated project. That project seems a closer match to Monomake. This was a common problem with Google, actually. There would be an internal name but once released it would take on a different name. Sometimes that name would…

That link is not to a Google project named Piper. It's to a company named Piper that uses Google Cloud.

Re: Meta developer tools: Working at scale

#162

Post by Maxff » Wed, Jun 28, 2023, 9:18 PM UTC

Efficiency!

- Where are you going?

- I'm going on vacation.

- Have you finished your project?

- Not yet. Just submitted the diff.

[^_^]

Re: Meta developer tools: Working at scale

#163

Post by jarjoura » Wed, Jun 28, 2023, 9:27 PM UTC

zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

As an ex-meta mobile engineer, I 100% agree that I found Eden to be impossible to use productively. I always had to pre-warm the cache, pretty much defeating its stated goals. Maybe it has gotten better since I left a year ago, but I had 2 TB of local storage, and mercurial's sparse checkouts were more than enough for me and far more reliable.

However, all the other tooling around code were just superior in every way. I miss Phabricator, and mercurial and the way it seamlessly integrates into a team. I also miss all of the command line helpers that let me manage all of it.

It used to be the case that legitimate teams could form around and focus just on building internal tools for other teams if it improved engineering velocity. Not sure if that's still the case in this new era of layoff-happy Meta, but it was definitely true when I was there.

Re: Meta developer tools: Working at scale

#164

Post by fuzztester » Wed, Jun 28, 2023, 9:28 PM UTC

zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

>I think Meta's tooling is inferior to industry standard.

s/Meta's tooling/Meta/g

s/inferior/very inferior/g

Re: Meta developer tools: Working at scale

#165

Post by KnobbleMcKnees » Wed, Jun 28, 2023, 9:34 PM UTC

phyrex wrote: post #67

wussboy wrote: post #41

Earlier quoted context omitted.

For me the barrier to working at Facebook is the fact their product is causing so much harm in our world, from elections to the environment to mental health to the breakdown of social capital. I know I’ll be downvoted for taking an ethical rather than financial or technological position, but ethics matter. Especially in technology and finances.

It's also doing a lot of good. It's in the nature of any broadcasting and communications platform

Qualify "good".

Re: Meta developer tools: Working at scale

#166

Post by ynx » Wed, Jun 28, 2023, 9:38 PM UTC

cletus wrote: post #53

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 Nucli…

I've been out for a couple of years, but...

> I'm honestly not sure what sapling is

My rough understanding: arcanist + git evolved into arcanist + hg, hg became a frontend to cHg and then the whole edenfs/sapling stuff started to replace that to optimize sparse checkout workflows.

> - Buck should've been killed and replaced by Bazel. I can't speak to Buck2 but this seems like a pointless investment;

Bazel's open-source version remained significantly less capable than Buck for a long time; Buck migrated towards Skylark just like Blaze, and cleaned things up greatly.

> - Thrift should be killed and replaced with gRPC/Protobuf. Same deal;

In general, agree with the former, but that's because protobufs and especially flatbuffers were already used in many places for many many years.

> FB's code search is just grep

There was also a less popular semantic search that people didn't use nearly as much.

> There's no dependency declaration at all

Strictly speaking this is not true, it was just not usually needed.

> There is no way to say "if this file is modified, run this test".

You needed to update the target determinator, but I do think this was possible.

Re: Meta developer tools: Working at scale

#167

Post by radicality » Wed, Jun 28, 2023, 9:40 PM UTC

zug_zug wrote: post #19

I think Meta's tooling is inferior to industry standard. I actually took a survey while I was there, and that wasn't the majority opinion, but frankly I think most outsiders would absolutely agree. Things like Eden were a great idea, but tools had all sorts of issues they gloss over (a virtual file system can be really slow if you have a ton of small files), dev environments would randomly fail a lot, really the only…

Like a few others already commented, I also disagree. Was at FB for 7 years, and now almost 2 years at a place with the “industry standard” things like slack / datadog / github / sourcegraph / (20+ other tools all disconnected from the rest and all behind SSO).

As a backend engineer, the dev experience was just incomparably better at FB. Some things I most most are probably phabricator / stacked diffs workflows, buck dep management with everything in a monorepo, deep integration across all the the tooling etc.

Re: Meta developer tools: Working at scale

#168

Post by zdgeier » Wed, Jun 28, 2023, 9:41 PM UTC

If anyone is interested in an open source VCS that's trying to solve similar problems to these internal tools check out https://jamhub.dev.

(I am the author)

Re: Meta developer tools: Working at scale

#169

Post by erik_seaberg » Wed, Jun 28, 2023, 9:44 PM UTC

vlovich123 wrote: post #159

zug_zug wrote: post #158

Earlier quoted context omitted.

>> Amazon internal tooling (is that 'industry standard' enough?). I'm not sure, maybe? When I say industry-standard tools I mean "Best you can purchase." So I mean a UI as good as github, a platform as good as AWS (meta's doesn't hold a candle to AWS), full-text log searching as good as splunk, chat as fast/searchable as slack (workplace doesn't hold a candle), video chat as fast/clear/clean as Zoom (workplace doesn'…

GitHub's developer workflow is a joke compared with the ticketing, CI, and code review tooling at Meta. I found the tools at Meta made it a lot smoother and faster to write and review code. Also, their automated flaky test detection, suppression, & ticket issuance/resolution is no joke. One of my favorite features. Their feature flagging system was also on point. Also, Workplace is a fantastic replacement of Wiki tha…

Suppressing flaky tests is a little terrifying. Google would just retry them a few times, which is slow but only delays requesting a code review.

Re: Meta developer tools: Working at scale

#170

Post by ynx » Wed, Jun 28, 2023, 9:45 PM UTC

cletus wrote: post #129

ahahahahah wrote: post #116

Earlier quoted context omitted.

Everyone reading this should assume it's talking about FB around 2014 or so, I don't know how it could otherwise be so wrong. > FB's code search is just grep. It's literally called BigGrep. This hasn't been true for a long time, codesearch at FB is more complex than just grep and has some semantic understanding. Here's some discussion here when some of this infrastructure was open sourced: https://news.ycombinator.co…

As for Glean, you concede "some semantic understanding". All I know is as of 2 years ago I couldn't do "Find Usages" of a particular C++ method where I could Google cs 6+ years ago. I did spend way more time doing www than C++ though and Hack was specifically written to facilitate regex searches like being able to search for "SomeClassName::someFunctionName" to find usages as well as the other examples of prohibiting…

> the whole FB C++ build experience was fairly primitive and even worse for iOS/Android

Flatly untrue, on iOS much of the infrastructure was well ahead of what anyone else had aside from Google. It worked so well that a tooling team responsible for upgrading to a new version of Xcode soon after its released declared victory and took credit for the compiler upgrade, as this had been an issue in past years.

They hadn't realized that a compiler team had been quietly running their builds company-wide for nearly two years and fixing compiler bugs on the bleeding edge of clang/llvm the whole time, so by the time the compiler was branched for Xcode and released from Apple, the fixes were already complete, open-sourced, and merged fully upstream.