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

Buck – A build system developed and used by Facebook

buckbuild.com

Post reply on HN
Print view View original

11–20 of 131 posts

Re: Buck – A build system developed and used by Facebook

#11

Post by beefsack »

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems.

We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them.

Maybe I'm just being bitter because I've had a bad experience, but it's been a maintenance nightmare for us in the office.

Re: Buck – A build system developed and used by Facebook

#12

Post by m_mueller »

danso wrote: post #8

I don't work in a shop where performance/speed is important, but I am looking for other ways to do things I would do in Make but...not in Make. For example, my use-case is similar to what Mike Bostock described in "Why Use Make" [0] when explaining how he uses Make to build out his data tranformation process. Most of my work is data transformation/small-scale ETL, but I just haven't been able to get into Make beyond…

So far I've also always found `make` to be the best option for what I need, especially because it's already available everywhere (albeit sadly in very subtly incompatible versions).

Anyways, one thing that has always bothered me about make is that it so much depends on file modification dates. Imagine if it would instead use a very optimised hashing algorithm over the input content. Content can be a file or any URI, so it uses wget/curl and ssh as a dependency. Hashing is optimized such that it fails early - e.g. hash in n kB increments, mark as new and return if changed.

Imagine how well this would now suddenly integrate into our modern web service based landscape. You could hook together services quite easily:

    all: report.csv

    report.csv: ${customers_json_uri} ${earnings_json_uri}
        ${report_executable} $^ > $@
Has anyone built something like this already?

Re: Buck – A build system developed and used by Facebook

#16

Post by skrebbel »

beefsack wrote: post #11

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems. We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them. Ma…

That's not Facebook's fault, that's fanboyism's fault.

I fail to see how the world gets worse from large companies releasing internal tools as open source.

Re: Buck – A build system developed and used by Facebook

#17

Post by BinaryIdiot »

beefsack wrote: post #11

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems. We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them. Ma…

To be fair a majority of the big technology companies all write their own tooling for many things that already exist because they didn't quite fit the way they needed them to and they had the resources to re-invent whatever they want.

Sure when they open source them it further fragments the market and you always get the rush of "Facebook has almost 2 billion users therefore their tools must be the best!" which further exacerbates the issue but I don't blame Facebook for these issues.

It sounds like, in your situation, perhaps there are too many tools being introduced into your projects. Too often I see developers abuse the hell out of npm and the like to just include whatever they need with zero regard for the newly introduced dependency tree and the new tooling that needs to now be maintained.

Re: Buck – A build system developed and used by Facebook

#18

Post by perlgeek »

beefsack wrote: post #11

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems. We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them. Ma…

It seems you lack technical leadership in your organization. Don't blame facebook for it :-)

Re: Buck – A build system developed and used by Facebook

#19

Post by cwyers »

BinaryIdiot wrote: post #17
beefsack wrote: post #11

Continuing the trend of Facebook creating competing tools more often than persisting with and improving existing ones, which I feel dilutes effort and has fragmented a number of ecosystems. We've got a couple of Facebook fans at work, which has left us with a number of our systems using different tools to accomplish essentially the same tasks, and no strong case on either side for us to standardise on one of them. Ma…

To be fair a majority of the big technology companies all write their own tooling for many things that already exist because they didn't quite fit the way they needed them to and they had the resources to re-invent whatever they want. Sure when they open source them it further fragments the market and you always get the rush of "Facebook has almost 2 billion users therefore their tools must be the best!" which furthe…

When Facebook wrote this, the tooling that already existed wasn't available to them -- ex-Google engineers at Facebook wanted something like Bazel/Blaze, but Google had yet to release that publicly. So this is a Hadoop situation where Google had this internal tool that someone else really wanted and because Google didn't open-source it they wrote their own version.
Post reply on HN