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

91–100 of 228 posts

Re: Meta developer tools: Working at scale

#91

Post by aseipp »

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've never had any problems that couldn't be solved.

Stockholm syndrome. I've used Git for 15 years, early GitHub user, etc. Yes, you can solve many of these things, but until recently even things like "I am changing patch 2 in a series of 5 and need to rebase the following 3" were ridiculously painful. This is a common workflow many people like (including the Linux kernel devs) and Git was bad at it.

Git submodules. I'm not even going to go into this, they're so bad. That's a problem I wish Git had never "Solved" to spare us the burden.

There are tons of minor nits in Git all over the place. "Solving" something is completely different from actually having something that can be easily used for your team. There's no amount of contributing Facebook could have done to fix Git, because they'd be turning Git into something else that it fundamentally is not. And it doesn't matter if you have a trillion dollars, it's often not practical to just overhaul someone else's whole project when these goals don't align.

Re: Meta developer tools: Working at scale

#92

Post by charcircuit »

jonathankoren wrote: post #36

I stopped reading when I reached that they made their own CVS. This is a solved problem, and even if it isn’t, there’s entire communities dedicated to it. There’s literally no reason why Facebook needs to be in the business of reinventing the wheel from scratch beyond some dude trying to show “impact”. It’s a distraction from core business problems.

>they made their own CVS.

It is a fork of Mercurial and there wasn't a community dedicated to making it scale to the scale Meta was reaching hence why they invented resources in making Mercurial scale.

Re: Meta developer tools: Working at scale

#93

Post by calvinmorrison »

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…

Fastmail had great developer tooling. Give yourself about two minutes from a issued command via slack or CLI and you'd have a brand new tagged developer box the live system that was a self contained infrastructure in a box of everything from the imap server to the user interface. Another command you could get as many copies for whatever development branch, etc.

The entire system replicated the real system (not user data but the software) and you could spin up test addresses and accounts and all sorts trivially. Beautiful!

Re: Meta developer tools: Working at scale

#94

Post by steve1977 »

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…

For me as a customer/user, Facebook seems to be the same since 5 or more years. So that velocity doesn’t translate to user experience unfortunately.

Re: Meta developer tools: Working at scale

#95

Post by aseipp »

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…

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

Re: Meta developer tools: Working at scale

#96

Post by charcircuit »

ghnws wrote: post #54

The linked article has a section about IDE that this one does not touch. I was surprised they are locking them selves in to one tool with their workflow. I'm a bit worried about the dominance of VS Code. I can't stand the editor and it's popularity just grows and grows.

They aren't locking themselves in. It just makes sense to support less IDEs than more IDEs. You can move faster if you don't have to duplicate your work between vscode, intellij, android studio, emacs, vim, etc. Nothing is stop developers from using ed, the standard editor, if they wanted to.

Re: Meta developer tools: Working at scale

#97

Post by dragonwriter »

aseipp wrote: post #91
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've never had any problems that couldn't be solved. Stockholm syndrome. I've used Git for 15 years, early GitHub user, etc. Yes, you can solve many of these things, but until recently even things like "I am changing patch 2 in a series of 5 and need to rebase the following 3" were ridiculously painful. This is a common workflow many people like (including the Linux kernel devs) and Git was bad at it. Git submodule…

> 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 to cover for that.

Re: Meta developer tools: Working at scale

#98

Post by TechBro8615 »

Off topic, but why haven't they migrated these kind of sites to the meta.com domain? I mean, these are Meta tools, right? Not FB tools? Unless... the rename was more of an exercise in liability obfuscation than it was an indication of any kind of reorganization...

Re: Meta developer tools: Working at scale

#99

Post by aseipp »

dragonwriter wrote: post #97
aseipp wrote: post #91

Earlier quoted context omitted.

> I've never had any problems that couldn't be solved. Stockholm syndrome. I've used Git for 15 years, early GitHub user, etc. Yes, you can solve many of these things, but until recently even things like "I am changing patch 2 in a series of 5 and need to rebase the following 3" were ridiculously painful. This is a common workflow many people like (including the Linux kernel devs) and Git was bad at it. Git submodule…

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

Re: Meta developer tools: Working at scale

#100

Post by TechBro8615 »

morgannewman wrote: post #72
jonathankoren wrote: post #36

I stopped reading when I reached that they made their own CVS. This is a solved problem, and even if it isn’t, there’s entire communities dedicated to it. There’s literally no reason why Facebook needs to be in the business of reinventing the wheel from scratch beyond some dude trying to show “impact”. It’s a distraction from core business problems.

You might be surprised to learn that it was not and still is not a solved problem for companies like Meta. Here is an earlier write-up about this topic from Meta: https://engineering.fb.com/2014/01/07/core-data/scaling-merc...

Also keep in mind they've been in hypergrowth mode since 2010 or earlier. Regardless of whether Git is the clear solution today, it definitely wasn't at that time. So it makes sense they invested in building their own tooling.
Post reply on HN