buck

One thing you might be missing is that this is Buck2. Buck (https://github.com/facebook/buck) has been open sourced for nearly 10 years now. The lore I've heard is that former Googlers went to Facebook, built Buck based on Blaze, and Facebook open sourced that before Google open sourced Blaze (as Bazel). The first pull to the Buck github repo was on May 8, 2013 (https://github.com/facebook/buck/pulls?q=is%3Apr+sort%3Acrea...). The first to Bazel was Sep 30, 2014 (https://github.com/bazelbuild/bazel/pulls?q=is%3Apr+sort%3Ac...).

I’m feeling sorry for everyone affected. Let’s hope that this isn’t going to impact Buck [0] too much. It’s one of the best things Facebook has ever made. [0]: https://github.com/facebook/buck/tree/dev

At least it’s open source: https://github.com/facebook/buck/blob/master/LICENSE I do agree. Facebook doesn’t get a pass regardless.

Looking at https://github.com/facebook/buck/graphs/contributors it seems like there hasn't been any commits to the Buck master branch in over a year. I loved using Buck in 2014 when it was the best open source Blaze. At least until 2015 when Google made Blaze open source. So why didn't Facebook give up on Buck sooner? Perhaps it's for the same reasons I now use make. I saw how angry Bazel made many open source people. I suspect part of it is that asking people to install a new build system just to use your project is a big ask, and it's an even bigger ask when that build system depends on things like the JDK. If Facebook rewrites it all in Rust and manages to ship single-file executables similar to what I can already do today with GNU Make, then it might be a positive improvement.

https://github.com/facebook/buck You’re welcome.

why I'm consider that using pkg-config in buck may break reproducibility: https://github.com/facebook/buck/issues/1430

Here's an example I'm rather proud of. It involves setting getpid(2) as a signal handler(2) via JNA. https://github.com/facebook/buck/commit/48f1e201a966b9e2adab...

>> what immutable has that checker framework doesn't. Functionality overlap is not particularly clear with Checker framework, in fact Immutable users often use Checker framework also. There are other tools like AutoValue, FreeBuilder, Lombok where I can see more similarities, but with important differences. >> Looks like immutables transform the code in even more spaghettis. I would not agree, but you should look at real world codebases like [1] or [2] which use immutables. >> Just looking at the "get started", it looks like the author voluntarily ignores all the java conventions around variables and getters/setters. Immutables support getters convention and you can configure any other convention you have, see [3]. >> I might be wrong on this, but I suspect this framework heavily relies on introspection, which in my experience has always