3 ms·

Not just that it doesn't integrate well with external tools. Cmake works better here. We had a googler at our company switch everything to bazel and it just sl

Not just that it doesn't integrate well with external tools. Cmake works better here. We had a googler at our company switch everything to bazel and it just slowed everyone down. There really is something about Google engineers, this sort of subtle arrogance that the Google way is superior to everything else is existence. Maybe I'm the ass hole but I wonder if anyone can relate?

simplotek 4y ago
> We had a googler at our company switch everything to bazel and it just slowed everyone down. I'd love to hear if anyone can make a case for Bazel knowing that cmake+build cache tools like ccache buy far better performance improvements than any full or incremental build.
- fsociety 4y ago
  If I want near-instantaneous compile times with my build system I'll just make a bash script or Makefile and use a single compilation unit (which Rust does not really do). When I use Bazel it is because: - I want to build nearly everything from source in a controlled hermetic environment. No more "well it works on my machine"... only to learn the developer's libs leaked into the build environment. - I want to do this with a single build system that works across many languages, and to build libraries which are used in many different languages. - I want to do this within a sandboxed environment for peace of mind when compiling thousands of dependencies. - I am willing to pay the money and time to setup remote executors to keep performance acceptable.
- bjackman 4y ago
  FWIW performance is not really in the picture when I say "I wish everything was Bazel". Configured properly, CMake and Make are probably unbeatable for speed. It's just that I really really hate maintaining Makefiles and CMake configs. Admittedly in the latter case it's because I have never grokked CMake, but also... I don't want to grok CMake, I grok a perfectly good way of building C++ already. And it can also build Go and Rust and Typescript and Proto and JSonnet and it can run my janky codegen shell scripts and if we migrate to Carbon it will build that too and I won't even have to read the documentation. Not saying I think everyone should migrate to Bazel (I hope I will not become That Ex-Googler), just explaining where the urge comes from.
  - simplotek 4y ago
    > It's just that I really really hate maintaining Makefiles and CMake configs. CMake is a high level makefile/build system generator. There is nothing to maintain in modern cmake. You just set what executables/libraries you want to build, set their dependencies, and you're done. And of all alternatives you chose to push, you pick Bazel of all things? Feature-incomplete and requiring all sorts of low-level maintenance?
    - HervalFreire 4y ago
      I don't like bazel, but cmake is a piece of shit too. The logic is convoluted, documentation is over complicated and the language contains too many primitive functions and ways to shoot yourself in the foot. There's really nothing good that's available.
habitue 4y ago
I don't think it's arrogance, it's just that blaze inside google is really nice, and they assume that using the tool outside google will also be really nice. The issue is that to make it really nice: - you have to convert everything to it, not just almost everything - you need to set up build servers and lightning fast caching servers - you need a team dedicated to building bazel rules for whatever doesn't already have rules (see: you must convert everything). This team is a bottleneck Regular google engineers aren't exposed to these issues, because inside google it just works. It's only once they try to deploy it themselves that they realize it's a sisyphean task. The thing is, bazel actually is really good at solving the issues it was designed for, it's just most companies do not have those particular problems acutely enough that it's worth paying the cost to switch to bazel.
- HervalFreire 4y ago
  >- you need a team dedicated to building bazel rules for whatever doesn't already have rules (see: you must convert everything). This team is a bottleneck This is a major issue. A good build tool shouldn't require a dedicated team. Ideally a build tool should function as sort of a settings menu for the project.
  - fsociety 4y ago
    > This is a major issue. A good build tool shouldn't require a dedicated team. Build systems are complex because they solve issues which only exist because of how OSes handle libraries and executables. I am pessimistic we can ever solve that issue in a capitalist society. I will be optimistic if we have a new major OS that isn't Windows, Linux, or MacOS in our lifetime or we solve death.
deleted 4y ago
[deleted]

simplotek 4y ago

> We had a googler at our company switch everything to bazel and it just slowed everyone down. I'd love to hear if anyone can make a case for Bazel knowing that cmake+build cache tools like ccache buy far better performance improvements than any full or incremental build.

fsociety 4y ago
If I want near-instantaneous compile times with my build system I'll just make a bash script or Makefile and use a single compilation unit (which Rust does not really do). When I use Bazel it is because: - I want to build nearly everything from source in a controlled hermetic environment. No more "well it works on my machine"... only to learn the developer's libs leaked into the build environment. - I want to do this with a single build system that works across many languages, and to build libraries which are used in many different languages. - I want to do this within a sandboxed environment for peace of mind when compiling thousands of dependencies. - I am willing to pay the money and time to setup remote executors to keep performance acceptable.
bjackman 4y ago
FWIW performance is not really in the picture when I say "I wish everything was Bazel". Configured properly, CMake and Make are probably unbeatable for speed. It's just that I really really hate maintaining Makefiles and CMake configs. Admittedly in the latter case it's because I have never grokked CMake, but also... I don't want to grok CMake, I grok a perfectly good way of building C++ already. And it can also build Go and Rust and Typescript and Proto and JSonnet and it can run my janky codegen shell scripts and if we migrate to Carbon it will build that too and I won't even have to read the documentation. Not saying I think everyone should migrate to Bazel (I hope I will not become That Ex-Googler), just explaining where the urge comes from.
- simplotek 4y ago
  > It's just that I really really hate maintaining Makefiles and CMake configs. CMake is a high level makefile/build system generator. There is nothing to maintain in modern cmake. You just set what executables/libraries you want to build, set their dependencies, and you're done. And of all alternatives you chose to push, you pick Bazel of all things? Feature-incomplete and requiring all sorts of low-level maintenance?
  - HervalFreire 4y ago
    I don't like bazel, but cmake is a piece of shit too. The logic is convoluted, documentation is over complicated and the language contains too many primitive functions and ways to shoot yourself in the foot. There's really nothing good that's available.

habitue 4y ago

I don't think it's arrogance, it's just that blaze inside google is really nice, and they assume that using the tool outside google will also be really nice. The issue is that to make it really nice: - you have to convert everything to it, not just almost everything - you need to set up build servers and lightning fast caching servers - you need a team dedicated to building bazel rules for whatever doesn't already have rules (see: you must convert everything). This team is a bottleneck Regular google engineers aren't exposed to these issues, because inside google it just works. It's only once they try to deploy it themselves that they realize it's a sisyphean task. The thing is, bazel actually is really good at solving the issues it was designed for, it's just most companies do not have those particular problems acutely enough that it's worth paying the cost to switch to bazel.

HervalFreire 4y ago
>- you need a team dedicated to building bazel rules for whatever doesn't already have rules (see: you must convert everything). This team is a bottleneck This is a major issue. A good build tool shouldn't require a dedicated team. Ideally a build tool should function as sort of a settings menu for the project.
- fsociety 4y ago
  > This is a major issue. A good build tool shouldn't require a dedicated team. Build systems are complex because they solve issues which only exist because of how OSes handle libraries and executables. I am pessimistic we can ever solve that issue in a capitalist society. I will be optimistic if we have a new major OS that isn't Windows, Linux, or MacOS in our lifetime or we solve death.

deleted 4y ago

[deleted]