Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meta developer tools: Working at scale

engineering.fb.com

Post reply on HN
Print view View original

61–70 of 228 posts

Re: Meta developer tools: Working at scale

#61

Post by dmoy »

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…

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

Re: Meta developer tools: Working at scale

#62

Post by mattnewton »

kevinventullo wrote: post #27
typon wrote: post #22

Earlier quoted context omitted.

It's interesting to hear the contrast between Meta and my experience talking with ex-Googlers who complain that open-source or industry standard infrastructure is far inferior to what they were used to at Google. Why such a big chasm between the internal tool quality at Meta and Google?

FWIW I am a Meta-to-Google transplant and I feel the opposite way. There’s a lot of internal tooling and functionality I miss dearly. Most of all, Workplace.

FWIW I did the opposite leap and felt the opposite way- I really disliked workplace’s stream of seemingly randomly sorted information compared to e-mail lists I could filter, control, and search better. I really dislike workplace as a store of institutional knowledge. The chat was definitely way better than hangouts chat though.

I also felt like a lot of the developer tools looked nicer than their google counterparts at the surface but had major reliability problems under the hood where you would need to do a lot of turn it off and on again style operations.

Re: Meta developer tools: Working at scale

#63

Post by Jcampuzano2 »

RandallBrown wrote: post #48
fzeindl wrote: post #45

Earlier quoted context omitted.

The problem with metas approach to tooling from a very high level viewpoint is that they virtualize everything. They abstract all common tasks like building, testing or running by building an entirely new system that builds an abstraction layer. Abstraction layers tend to be slow. What they should focus on is plumbing. Take what exists and connect it in a smart way. Take React: the idea of applying functional program…

Maybe it's not necessary anymore, but wasn't the virtual DOM made for performance reasons since updating the DOM used to be really really slow?

Virtual DOM in any scenario will always be slower than updating the DOM directly. The virtual DOM will always be overhead. The issue is if you are manually updating the DOM yourself you can easily shoot yourself in the foot by doing so in a way that is less performant, or breaks things like scroll position, focus management etc. Its also normally more tedious to do manually. This is where the virtual DOM came in. You just declaratively update the JSX and it handles the updating itself.

But nowadays there are plenty of solutions that do not use virtual DOM (or even use a virtual DOM solution that is just plain faster) but still allow you to use declarative rendering, basically the best of both worlds. They are just not as popular or for some people not as interesting to them as React is. Or they are content with Reacts performance already.

Re: Meta developer tools: Working at scale

#64

Post by anonymoushn »

castlecrasher2 wrote: post #51
rangledangle wrote: post #42

Earlier quoted context omitted.

No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity. I always attributed that to their internal tools, since most of the other companies seem to be using the same crap. Slack is straight up painful compared to their chat system. And don't get me started on the how good the task tool is compared to literally any other ticketing system out there. Everything is behind th…

>Slack is straight up painful compared to their chat system. As someone who vastly prefers Slack over all its competitors, I'm very interested in hearing how Meta's compares. What makes it better than Slack for you?

slack is incredibly, unbearably slow

Re: Meta developer tools: Working at scale

#65

Post by [deleted] »

kevinventullo wrote: post #27
typon wrote: post #22

Earlier quoted context omitted.

It's interesting to hear the contrast between Meta and my experience talking with ex-Googlers who complain that open-source or industry standard infrastructure is far inferior to what they were used to at Google. Why such a big chasm between the internal tool quality at Meta and Google?

FWIW I am a Meta-to-Google transplant and I feel the opposite way. There’s a lot of internal tooling and functionality I miss dearly. Most of all, Workplace.

[deleted]

Re: Meta developer tools: Working at scale

#66

Post by PreachSoup »

optymizer wrote: post #60
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…

For what it's worth, as a Meta employee, I generally disagree with this comment. I mean, calling it 'inferior' is just laughable. It's way better than what open source projects have access to and it's way better than Amazon internal tooling (is that 'industry standard' enough?). The sapling workflow is better than git. I was skeptical when I joined, but between no branches and excellent stack and merge support, it's…

I agree. The tooling is not as good as Google's(expected, Google's internal ides are incredible). But it's definitely better than the rest

Re: Meta developer tools: Working at scale

#67

Post by phyrex »

wussboy wrote: post #41
yawnxyz wrote: post #12

This kind of stuff puts me off from wanting to work at FB. If I got really good at working with these tools (or fell in love with this tooling), I wouldn't really be able to go back to working "in the real world"

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

Re: Meta developer tools: Working at scale

#68

Post by dmoy »

kayson wrote: post #50

I know git is complex, and the UX is sometimes messy, but after really, really learning it (shoutout to the Github training folks), I've never had any problems that couldn't be solved. I understand the desire to simplify some things, and their log looks way better than gits, but I wish they'd contribute back instead of rolling their own entire VCS. The one thing that is super exciting to me is the stacked pull reques…

I think the biggest issue is that back around 2011/2012 ish, when Facebook devs went to git core devs and asked how they could get git to scale to the size of their predicted monorepo, the response was roughly "no, shard it".

git falls over and dies really, really badly when the repo gets stupidly large.

There's an article alluding to the discussion here: https://engineering.fb.com/2014/01/07/core-data/scaling-merc..., but I can't find the original thread on the git mailing list.

Re: Meta developer tools: Working at scale

#69

Post by innagadadavida »

rangledangle wrote: post #42
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…

No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity. I always attributed that to their internal tools, since most of the other companies seem to be using the same crap. Slack is straight up painful compared to their chat system. And don't get me started on the how good the task tool is compared to literally any other ticketing system out there. Everything is behind th…

Shipping faster should not be the only metric, the amount of SEVs should be given much higher weight. The attitude of most engineers is to show impact and if there is a SEV, it is better as it will show even more impact. This slows other people down and causes a gradual decline is actually shipping things that matter - quality over quantity.

Re: Meta developer tools: Working at scale

#70

Post by tekknolagi »

patrec wrote: post #38
skizm wrote: post #15

Earlier quoted context omitted.

Most (all?) of these are open source and can be used outside of Meta infra. https://github.com/facebook/sapling

> Mononoke is the server-side component of Sapling SCM. > While it is used in production within Meta, it currently does not build in an > open source context and is not yet supported for external usage.

You can still use sapling with existing Git repos
Post reply on HN