ndmitchell

Neil from the Buck2 team here. I think your points are pretty much spot on - everything we use internally is battle tested, everything we don't is less tested. We've tried to use that to our advantage by making as much as we can available externally, so its really just talking to services that only exist internally that are custom written for open source.

We're very willing to take PRs explicitly for community usage, with the standard caveats that it needs to be maintainable, testable, not regress other behaviours etc. But those shouldn't be insurmountable. Best way to tell for real is go through our PR backlog.

We schedule tasks mostly using tokio - without any particular care. It's mostly good, but occasionally causes some performance headaches. I think in the fullness of time we might need to invest more in careful scheduling.

I think of Shake as a library for implementing build systems, and was hoping that libraries would emerge that described how to implement rules like C++, and how they should compose together so you can compile C++/Haskell/Python all together happily. A few libraries emerged, but the overall design never emerged. Sorry you got burned :(

Buck2 is at a higher level than Shake - the rules/providers concepts pretty much force you into a pattern of composable rules. The fact that Meta has lots of languages, and that we were able to release those rules, hopefully means it's starting from the point of view of a working ecosystem. Writing those rules took a phenomenal amount of effort from a huge range of experts, so perhaps it was naive that Shake could ever get there on only open source volunteer effort.

Thanks for the comments! There are two levels at which you could make Buck2/Bazel compatible:

* At the BUILD/BUCK file level. I imagine you can get close, but there are details between each other that will be hard to overcome. Buck2 doesn't have the WORKSPACE concept, so that will be hard to emulate. Bazel doesn't have dynamic dependencies which means that things like OCaml are written as multiple rules for a single library, while Buck2 just has a single rule. I think it should be possible to define a macro layer that was common enough so that it could be implemented by both Bazel and Buck2, and then open source users could just support the unified Bazck build system. * At the rules level. These might be harder, as the subtle details tend to be quite important. Things like tsets vs depsets is likely to be an issue, as they are approximately the same mechanism, but one wired into the dependency graph and one not, which is going to show up everywhere.

There's no such thing as a phony target, but there is both `buck2 build` and `buck2 run` - each target can say how to run and how to build it separately. So you can have a shell script in the repo, write an export_file rule for it, then do `buck2 run :my_script` and it will run.

These were from an open source contributor - out the box Buck2 doesn't really have support for Nix. But because the rules are flexible, you can write your own version of Nix-aware Buck2.

It can use watchman, but for open source we default to inotify (and platform equivalent versions on Mac/Windows) to avoid you having to install anything.

> Until they re-implement it again :)

As the paper says, every previous implementation started nicely and got horrible towards the end. This time, that hasn't happened, so _hopefully_ it's the final one. But, of course, never say never.

> How about using libfuse?

What about Windows? Certainly you could use something like libfuse, and we're trying other solutions - if we manage to build a cross-platform API Shake will be able to use it easily.

The old GHC build system did do everything in 3 phases. And they were pretty magic phases. It's not clear there's any upper bound on the number of phases, and maintaining each phase separation is very tricky.