Bazel Release 1.0
I am going to be hated and downvoted for that but let&#x27;s go...<p>Bazel, like Bucks and other, try to bring on table a build system &#x2F; deployment system that is multi-language, multi-platform and developer oriented. A holy Graal that many developer ( like me ) looked for decade and that many (large) organizations more or less tried to do one day (and most failed)<p>It is a good idea. It is a required tool to improve productivity. However, if the idea is good on paper, in the implementation, Bazel is damn wrong.<p>- Bazel is centered around &quot;mono-repo&quot; culture, making it much harder to integrated with multi-source, multi-repo, multi-version projects like many of us have. If I have no doubt that it is great at Google, the external world is not google.<p>- Bazel is made in JAVA, requires the JVM and this is a problem. That make Bazel  not a &quot;light&quot; tool easy to deploy in a fresh VM or in a container.<p>- Bazel mix the concepts Build System ( like Make, ant, co ) and Deployment System like ( rpm, pkgsrc, etc). That makes Bazel pretty hard to integrate with projects that have existing build system, and almost impossible to integrate <i>INSIDE</i> an other Deployment System (usual package manager, deployment pipeline). The problem that Bazel faces with some languages ( python, go ) is a cause of that.<p>- Bazel venerates and follows the cult of &quot;DO NOT INSTALL&quot;: compile and execute in workspace, there is no &quot;make install&quot;, not installation phase. If &quot;convenient&quot; in mono-repo, this is often a nightmare because the boundary between components can be easily violated... and you finish by having many project that use internal headers or interface.<p>- Bazel makes mandatory ( almost ) to have internet to compile. This is a problem, a major problem in many organization (like mine) where downloading random source and binary from the Web is not acceptable for security reasons. Try to run Bazel in a sandbox.... and cry.<p>- Related to what I said before, Bazel mixes Build system and Deployment system. Doing so, it makes the same mistake that many &quot;language specific&quot; package manager and make uselessly hard to depend on an already installed, local library &#x2F; component.<p>- And finally, last but not least... The options.... Bazel throw away 30 years of conventions &#x2F; naming from the ( GNU &#x2F; BSD world ) to create its own.... That make the learning curve difficult... Specially with a (up to recently) very sparse and outdated documentation.<p>I have no doubt that inside Google or Facebook, Bazel or Bucks are amazing.But they have been released too late for the external world in my mind.<p>Nowadays platform independant package managers like spack (<a href="https:&#x2F;&#x2F;github.com&#x2F;spack&#x2F;spack" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;spack&#x2F;spack</a>), Nix (<a href="https:&#x2F;&#x2F;nixos.org&#x2F;nix&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nixos.org&#x2F;nix&#x2F;</a>), GUIX (<a href="http:&#x2F;&#x2F;guix.gnu.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;guix.gnu.org&#x2F;</a>) gives 95% of the advantages of Bazel without the pains of it.