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

131–140 of 228 posts

Re: Meta developer tools: Working at scale

#131

Post by mandeepj »

calvinmorrison wrote: post #93
optymizer wrote: post #60

Earlier quoted context omitted.

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

> get as many copies for whatever development branch

Why would someone need a more than one copy of a dev/feature branch?

Re: Meta developer tools: Working at scale

#132

Post by spookthesunset »

jonathankoren wrote: post #114
TechBro8615 wrote: post #100

Earlier quoted context omitted.

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.

And now it's 2023, and they're inventing the wheel again.

Not a very robust analogy. There are tons of different wheel designs out there. Some are good for racing and suck for rain. Some are great in the snow but are noisy and inefficient on the highway. Etc... Maybe their needs are so special they need a wheel design that doesn't commercially exist?

Re: Meta developer tools: Working at scale

#133

Post by cletus »

howinteresting wrote: post #108
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,…

> 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 conflict with a different internal name, which then made internal searches impossible. I forget the specifics, but Buzz became an external product but was an internal product name for something different.

Dart (the language) was internally known as Dash prior to release. IIRC Google Dash was an external thing for advertisers or something like that.

So when I say Piper I really do mean the internal rewrite of Perforce.

[1]: https://cloud.google.com/customers/piper

Re: Meta developer tools: Working at scale

#134

Post by ben_w »

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…

> No company I've worked at after FB/Meta ships or works even at a non-eng level with the same velocity.

This is a curious thing to see.

As a mere user, and speaking purely about FB not any other Meta IP…

Other than unbreaking things that break when the OS and browsers change under you, has Facebook shipped even one thing in the last five years?

Don't get me wrong, I know it takes a lot of effort to stand still — forgetting the Red Queen effect was Musk's obvious mistake with Twitter even before stuff broke — but Facebook seems completely unchanged.

Re: Meta developer tools: Working at scale

#135

Post by nicce »

SamuelAdams wrote: post #85
nicce wrote: post #32

Earlier quoted context omitted.

… lock developers into the ecosystem and prevent them leaving, since their knowledge is not so valuable elsewhere. A bit cynical, but maybe not so unpopular opinion. Meta as business is all about locking users to the ecosystem.

Same thing applies to most government jobs. The tech is so out of date / niche that you become un-hire-able with those skills.

Unless you hit a job on some consult firm which offers special knowledge about all these!

Re: Meta developer tools: Working at scale

#136

Post by nsonha »

Solvency wrote: post #124
MikeTheRocker wrote: post #71

Earlier quoted context omitted.

Having also written Android code at Meta, I 100% agree.

What's the short version of why Meta did this, wrapping so much up in this internal nonstandard format?

I'm guessing same to why everyone else does that: they want to abstract away the platform. To some people platform intricacies are uninteresting comparing to the problem they are solving, so their abstractions aim to express their problem domain, and hide everything else.

For example for apps you may like to deal with abstractions that can express navigation and pages. They are the same across web, iOS, Android. Unlike Activity, Fragment, View (is that still a thing, I stopped doing android 10 years ago lol) and some slightly different set of abstrations over iOS.

Re: Meta developer tools: Working at scale

#137

Post by ngai_aku »

baggiponte wrote: post #119

I am genuinely curious about wasabi, the python LSP they announced on Meta open source but is not available anywhere. Would love to try that out, there is not enough competition in the LSP space in Python and it would foster new development https://developers.facebook.com/blog/post/2022/07/18/enablin...

In the “Offline + Online Processing” section, are they talking about an external service that needs to run alongside the processing that occurs on your machine? Or am I misunderstanding that?

Re: Meta developer tools: Working at scale

#138

Post by aseipp »

cletus wrote: post #125
aseipp wrote: post #95

Earlier quoted context omitted.

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

I hope Buck2 is better. Like I said, I have no experience with it. My issue is more organizational. Meta, as a company, in my experience, does not put in sufficient investment to build a mature, robust open source project with few exceptions. Even things like the www test infra, which are core to the company when I was there had ~1 FTE SWE. That's not open source but you get my point. Buck (and Thrift) seem to have b…

That's fair, and I agree because honestly almost no companies IMO actually know how to build robust FOSS projects outside their own needs, I wouldn't put that totally on one place. It pretty much actually comes down to the engineers, in my experience, and how much they understand the whole thing. It's a big problem actually. But I know what you mean, Buck2 is definitely a Meta-first project right now, since they're still gearing up to replace everything. They've been pretty receptive to me, at least, but it probably helps that Neil has a bunch of FOSS experience (and we have a bit of rapport with each, so that helps), and there's many more people than just him on the job who all seem to want it to succeed! I think a lot of the technical decisions will help it grow better than Buck1 did, too.

Re: Meta developer tools: Working at scale

#139

Post by calvinmorrison »

mandeepj wrote: post #131
calvinmorrison wrote: post #93

Earlier quoted context omitted.

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

> get as many copies for whatever development branch Why would someone need a more than one copy of a dev/feature branch?

Because its free? You could have a beta server spun up on the fly to do some QA while your dev server is still kicking. It's just spinning servers off of git tags

Re: Meta developer tools: Working at scale

#140

Post by giraffe_lady »

dnissley wrote: post #127
giraffe_lady wrote: post #80

Earlier quoted context omitted.

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

"driving helps a ton of people get around, but sometimes people drive drunk and kill other people, so it's definitely unforgivingly bad"

Bad enough you won't catch me working for a car company. Excellent example really.
Post reply on HN