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

101–110 of 228 posts

Re: Meta developer tools: Working at scale

#101

Post by escapecharacter »

qwertywert_ wrote: post #78

If Meta acquires a new company codebase, do they just move it into their monorepo immediately?

Context: I was part of a company acquired by FB in 2019, worked there until Dec 2022. It really depends, based on how independent the acquired company needs to be, and how useful it would be to have overlap with code components & engineering resources with the main monorepo.

In our case, up until Dec 2022, parts our pre-acquisition monorepo were still separate, but gradually components and workflows, such as tests and reviews, were moved into the main repo. From my awareness, we didn't even start merging into the main monorepo until more than a year after we were acquired, though of course there were exploratory efforts before.

In general, I'm pro-monorepo, it makes sense to be able to update multiple interconnected components in lockstep. For the startup, we were still in research mode, so it was less urgent to spend eng/sci/TPM to incorporate with anything on the FB monorepo side...until it was.

Re: Meta developer tools: Working at scale

#102

Post by dmoy »

4ggr0 wrote: post #77
dmoy wrote: post #68

Earlier quoted context omitted.

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

Maybe this is the mailing list you were searching for?[0] [0] https://web.archive.org/web/20210119051414/http://git.661346...

Ah thanks! Yes I think that was it.

Re: Meta developer tools: Working at scale

#103

Post by yodsanklai »

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"

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

SWEs need to learn new tools all the time. This shouldn't be a concern. Besides, it's not like "the real world" only use a single tool. Each company has their own tweaks, even those using open source stuff.

Re: Meta developer tools: Working at scale

#104

Post by thiagocmoraes »

findjashua wrote: post #56
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…

phabricator & scuba are far better than anything i've used anywhere else.

I REALLY miss Phabricator, Scuba and (gasp) Tasks. Would love to have those back in industry. Far better than Github, Superset (?) and of course the dreadful Jira I have to use these days.

Re: Meta developer tools: Working at scale

#105

Post by yodsanklai »

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.

Ethics matters, but not everyone think that Facebook causes "so much harm in our world". At least, not more than other corporations.

Re: Meta developer tools: Working at scale

#106

Post by Kilenaitor »

giraffe_lady wrote: post #80
phyrex wrote: post #67

Earlier quoted context omitted.

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

"drunk driving may kill a lot of people, but it also helps a lot of people get to work on time, so, it;s impossible to say if its bad or not,"

Lmao that is ridiculously unfair since you're starting with a near-universally agreed bad thing.

Better analogy augmenting yours: just cars. Accidents between cars or cars and pedestrians kill lots of people every year.

This works with every tech. Phones have made it easier to coordinate crimes. Printing press and even televisions made mass propaganda possible. There are always tradeoffs.

Re: Meta developer tools: Working at scale

#107

Post by SideburnsOfDoom »

aseipp wrote: post #99
dragonwriter wrote: post #97

Earlier quoted context omitted.

> Stockholm syndrome. Is an intellectually dishonest fantasy invented for the sole purpose of using it to discredit and distract from criticism of the actions of the inventor of the phrase, so should never be ascribed as the source of a position you want to argue against unless your intent is to signal that your own position lacks a reasonable argument and you are just choosing to character-assassinate the opposition…

[flagged]

That comment is neither chat-generated nor baseless: https://www.idiva.com/health-wellness/mental-health/why-the-... https://www.themarysue.com/viral-tweet-exposes-sexist-origin...

"Assume good faith. Please don't post shallow dismissals." https://news.ycombinator.com/newsguidelines.html Please try abiding by that, thank you.

Re: Meta developer tools: Working at scale

#108

Post by howinteresting »

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…

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, by the way. The closest equivalent that Meta has to Piper is their source control server Mononoke.

Re: Meta developer tools: Working at scale

#109

Post by Kilenaitor »

seagullriffic wrote: post #8
arnon wrote: post #2

Surprised to see them use Phabricator (I know it came out of there, but I basically already forgot it existed) I used it briefly but couldn't get most people to adopt it widely enough.

I wonder whether they'll continue using their in-house Phrabricator or choose to support Phorge ( https://we.phorge.it/ ) now that open-source Phabricator is no longer supported.

Internal Phabricator isn't even really Phabricator anymore. In fact, the name changed to just Diffs. I'm pretty sure its entire codebase has been rewritten, at the very least into Hack from PHP. They have a custom API; not Conduit. Etc.

So, no. They wont support Phorge. They really never supported open-source Phabricator after Evan left and made it his own with Phacility.

Re: Meta developer tools: Working at scale

#110

Post by [deleted] »

stcroixx wrote: post #31
voidfunc wrote: post #16

Earlier quoted context omitted.

No see, what happens is you leave then go to some other company and complain about how shitty their tools are then build a crappy half-baked version of whatever you had at $BigTechCorp and when shit hits the fan you boomerang back to $BigTechCorp for a sweet promo and raise.

I avoid hiring people coming from places like this for reasons similar. Extends past tools into libraries and frameworks, databases and other middleware, developer and business workflows. Only knowing proprietary stuff is a handicap. Assuming that proprietary stuff is superior because the big ad companies prefer it is even worse.

[deleted]
Post reply on HN