5 ms·

I’m getting a little tired of this particular brand of lazy cynicism. I’m happy to see people inventing new build systems, programming languages, game engines,

I’m getting a little tired of this particular brand of lazy cynicism. I’m happy to see people inventing new build systems, programming languages, game engines, ORMs, or anything else where the conventional wisdom is to use the existing tools. It may be crazy optimistic but we need people to keep these skill sets alive.

taeric 7y ago
I agree at a personal level. If anyone is pushing a toy project, basically no reason to knock it. Reason that Serenity OS story a few days ago was awesome. However, solutions pushed by corporations with grandiose claims do strike a nerve with me. If only because they are typically pushed with the idea that they will spread through some technical superiority. I'm much more open to this getting more use strictly from who is pushing it, not what it is capable of.
- halflings 7y ago
  Companies using bazel [1]: * Asana * Databricks * Dropbox * Google * Huawei * Lyft * Pinterest * Stripe * TwoSigma * Uber ... This is not a new project that needs pushing. [1] https://github.com/bazelbuild/bazel/wiki/Bazel-Users https://github.com/bazelbuild/bazel/wiki/Bazel-Users
  - taeric 7y ago
    This seems silly. If I was to make a similar list of companies using Make, would that have deterred building bazel? Because I guarantee the number was non-zero and included some major players.
- klodolph 7y ago
  It is successful enough that it has spawned a few clones—Buck, Pants, Please.build, and the thing that Chromium uses now. From what I can tell, before Bazel was open-source, everyone who left Google wanted to use Blaze badly enough to write their own version.
  - taeric 7y ago
    Not exactly ringing endorsements here. In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in. Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes, any automation is welcome after that. None of this is to say it isn't worthwhile. Heck, they have enough manpower on it that it should be a good solution. It still hits a sour note with me, though.
    - beagle3 7y ago
      But the problem is that there were no proper build systems to use, not that they weren’t familiar with them. Gmake, cmake, scons, waf, whatever - non of them provide hermetic deterministic builds, track compiler versions properly, etc. The only build system I had used which could, with crazy effort, provide some of those features, is iirc ClearCase (or whatever it used for version control and management), and it was painful in every way and still didn’t enforce it - just had enough to allow you to do it with great effort (which gmake/cmake don’t even do)
    - klodolph 7y ago
      If this is because Google is pushing it, two things don’t make sense to me. - Why would you clone an open-source product because Google is pushing it? - Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016. > Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. Could you give an example of a “proper build system”? Even if this applies to most folks, Google hires so many people, and there are enough old-timers there (hell, Stuart Feldman was a VP of Engineering) with industry experience. One of the fundamental problems here is that for large enough projects or multi-project repos, it becomes burdensome just to load and evaluate all of the build rules. The inevitable result is that you have to split the build rules across multiple files for different parts of the tree, and people have been doing this for decades, this is nothing new. If you look at existing build systems, there are very precious few that will actually traverse the dependency graph well across these different subinstances. Recursive make sure doesn't do this very well (see Recursive Make Considered Harmful, 1997). IDEs usually do a good job of this but they only solve a narrow set of problems to begin with. Once you start with the goal of solving this particular problem well, my claim is that your solution will have some surprising similarities to Bazel (unless you ditch some other objective like incremental builds).
taneq 7y ago
Sure, but don't ignore the fact that new things are technical debt. Maybe they're worth it, but they're still debt.
- klodolph 7y ago
  I don’t think that you and I have the same idea of what “technical debt” is. Technical debt is when you prioritize short-term gains and pay for it with additional maintenance burdens long-term. In my experience, Bazel adoption can be the opposite—replace your custom scripts with Bazel, make the investment now, and deal with less maintenance later. I’ve dealt with some really painful in-house build systems, and migrated some of them to Bazel. That was paying off technical debt.
  - taneq 7y ago
    Oh, definitely. Painful in-house build systems are way more technical debt than a nice standardized one, so this could definitely be a winning move. Just remember that all code is still debt.
    - xpe 7y ago
      I'd like to share two responses to the sentence "all code is technical debt". 1. A user named gnus-migrate [1] says it well: "I think you completely misunderstood the concept of technical debt. It was just a metaphor created to explain to non-technical managers the need for refactoring. Saying all code is technical debt makes the term meaningless. / I think that you're saying that even clean code needs to be maintained. While that is true it has nothing to do with the idea of technical debt." 2. Eleenrood responds: "Actually it is logical consequence of Cunningham['s] idea. If you assume that overcomplicated solutions generate debt, you can also assume that best solution generate also some amount of debt. Just way smaller than non-optimal solutions. It actually simplify it, cause you don't have to come up with magical line between "debt clear code" and "code adding technical debt". Instead you weight code, which adds more technical debt than other. Your best solution in this case is the one with smallest technical debt weight." I will admit my preference, at the start of writing this comment, was for the first. It just sees nicer to define perfect code as 0 technical debt, right? On the other hand, I agree that all code has maintenance costs. (At the bare minimum, from time to time, someone has to read it to revel its perfection and convince themselves that it still remains untarnished given changing business requirements!) So, more points for definition #2. Next, let's compare software development to factories and machines (what could go wrong with this metaphor?). Yes, running and maintaining factory equipment has ongoing costs. But I would not say that planning for maintenance costs is the same as incurring debt. Hmmm, more points for definition #1. On the other hand, if a factory is given the choice between (a) buying outright and doing its own maintenance versus (b) renting equipment that includes both the cost of the equipment and the maintenance, you would expect in a perfect (idealized) market that both would cost the same. ... (Slight tangent: Accountants are sticklers about how companies account for costs. Some systems differ in how owned equipment and rented equipment are treated. I'm not expert, but I have a healthy, painful respect for these considerations.) ... All of which would suggest that sooner or later, one way or another, you have to pay for that maintenance. Call it a cost or call it debt, does it really matter? In both cases, if you want to make widgets, you have to pay it. So, points for definition #2 for acknowledging that code requires maintenance which, like it or not, implies a debt/cost. So, I can see why people prefer either. I kind of like to embrace the tension, so I like both. But if you need resolution, it can be found! :) The difference between these views is only a matter of the baseline. Another Arbitrary Table technical debt technical debt option definition 1 definition two ------ -------------- -------------- perfect code 0 300 imperfect code 400 700 In both cases, the net difference is 400. Of course, this works for addition, but not so well for division. Since division by zero is undefined, I tend to prefer definition #2! [1]: https://www.reddit.com/r/programming/comments/8w8s03/all_code_is_technical_debt/ https://www.reddit.com/r/programming/comments/8w8s03/all_cod...
throwaway1777 7y ago
Bazel is hardly new, it’s been in use at Google for many many years as Blaze.
- willtim 7y ago
  This is misleading. Bazel is full of brand new code and only parts of it have been in use at Google as part of Blaze.
  - laurentlb 7y ago
    No. I work on Blaze/Bazel. The vast majority of the code is shared between Blaze and Bazel. Examples of Bazel-specific code include support for Windows and support for external deps (needed for multirepos and interaction with package managers). The core is exactly the same.
    - willtim 7y ago
      My employer encountered lots of basic bugs, like file handle exhaustion, which together with the amount of recent activity in GitHub, suggested to me that there is a lot of new code in Bazel. If it's essentially the same as Blaze as you say, then why the new name?
      - hanwenn 7y ago
        I was there when the name was selected. It turns out "blaze" suggests speed, which is why it was a popular name for other software, and some of it was registered as trademark.
_the_inflator 7y ago
I side with you. Why build Angular, React? There was jQuery... After all, there are only tools. If you need a better tool, build it and ignore the naysayers. Everything is an experiment. If it inspires people, the better.

taeric 7y ago

I agree at a personal level. If anyone is pushing a toy project, basically no reason to knock it. Reason that Serenity OS story a few days ago was awesome. However, solutions pushed by corporations with grandiose claims do strike a nerve with me. If only because they are typically pushed with the idea that they will spread through some technical superiority. I'm much more open to this getting more use strictly from who is pushing it, not what it is capable of.

halflings 7y ago
Companies using bazel [1]: * Asana * Databricks * Dropbox * Google * Huawei * Lyft * Pinterest * Stripe * TwoSigma * Uber ... This is not a new project that needs pushing. [1] https://github.com/bazelbuild/bazel/wiki/Bazel-Users https://github.com/bazelbuild/bazel/wiki/Bazel-Users
- taeric 7y ago
  This seems silly. If I was to make a similar list of companies using Make, would that have deterred building bazel? Because I guarantee the number was non-zero and included some major players.
klodolph 7y ago
It is successful enough that it has spawned a few clones—Buck, Pants, Please.build, and the thing that Chromium uses now. From what I can tell, before Bazel was open-source, everyone who left Google wanted to use Blaze badly enough to write their own version.
- taeric 7y ago
  Not exactly ringing endorsements here. In large, most of the clones you are talking about are because this is a google pushed product. Chromium specifically is because google pushed it in. Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. It is not uncommon for college or earlier users to just use whatever their IDE does for them. Such that, yes, any automation is welcome after that. None of this is to say it isn't worthwhile. Heck, they have enough manpower on it that it should be a good solution. It still hits a sour note with me, though.
  - beagle3 7y ago
    But the problem is that there were no proper build systems to use, not that they weren’t familiar with them. Gmake, cmake, scons, waf, whatever - non of them provide hermetic deterministic builds, track compiler versions properly, etc. The only build system I had used which could, with crazy effort, provide some of those features, is iirc ClearCase (or whatever it used for version control and management), and it was painful in every way and still didn’t enforce it - just had enough to allow you to do it with great effort (which gmake/cmake don’t even do)
  - klodolph 7y ago
    If this is because Google is pushing it, two things don’t make sense to me. - Why would you clone an open-source product because Google is pushing it? - Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016. > Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all. Could you give an example of a “proper build system”? Even if this applies to most folks, Google hires so many people, and there are enough old-timers there (hell, Stuart Feldman was a VP of Engineering) with industry experience. One of the fundamental problems here is that for large enough projects or multi-project repos, it becomes burdensome just to load and evaluate all of the build rules. The inevitable result is that you have to split the build rules across multiple files for different parts of the tree, and people have been doing this for decades, this is nothing new. If you look at existing build systems, there are very precious few that will actually traverse the dependency graph well across these different subinstances. Recursive make sure doesn't do this very well (see Recursive Make Considered Harmful, 1997). IDEs usually do a good job of this but they only solve a narrow set of problems to begin with. Once you start with the goal of solving this particular problem well, my claim is that your solution will have some surprising similarities to Bazel (unless you ditch some other objective like incremental builds).

taneq 7y ago

Sure, but don't ignore the fact that new things are technical debt. Maybe they're worth it, but they're still debt.

klodolph 7y ago
I don’t think that you and I have the same idea of what “technical debt” is. Technical debt is when you prioritize short-term gains and pay for it with additional maintenance burdens long-term. In my experience, Bazel adoption can be the opposite—replace your custom scripts with Bazel, make the investment now, and deal with less maintenance later. I’ve dealt with some really painful in-house build systems, and migrated some of them to Bazel. That was paying off technical debt.
- taneq 7y ago
  Oh, definitely. Painful in-house build systems are way more technical debt than a nice standardized one, so this could definitely be a winning move. Just remember that all code is still debt.
  - xpe 7y ago
    I'd like to share two responses to the sentence "all code is technical debt". 1. A user named gnus-migrate [1] says it well: "I think you completely misunderstood the concept of technical debt. It was just a metaphor created to explain to non-technical managers the need for refactoring. Saying all code is technical debt makes the term meaningless. / I think that you're saying that even clean code needs to be maintained. While that is true it has nothing to do with the idea of technical debt." 2. Eleenrood responds: "Actually it is logical consequence of Cunningham['s] idea. If you assume that overcomplicated solutions generate debt, you can also assume that best solution generate also some amount of debt. Just way smaller than non-optimal solutions. It actually simplify it, cause you don't have to come up with magical line between "debt clear code" and "code adding technical debt". Instead you weight code, which adds more technical debt than other. Your best solution in this case is the one with smallest technical debt weight." I will admit my preference, at the start of writing this comment, was for the first. It just sees nicer to define perfect code as 0 technical debt, right? On the other hand, I agree that all code has maintenance costs. (At the bare minimum, from time to time, someone has to read it to revel its perfection and convince themselves that it still remains untarnished given changing business requirements!) So, more points for definition #2. Next, let's compare software development to factories and machines (what could go wrong with this metaphor?). Yes, running and maintaining factory equipment has ongoing costs. But I would not say that planning for maintenance costs is the same as incurring debt. Hmmm, more points for definition #1. On the other hand, if a factory is given the choice between (a) buying outright and doing its own maintenance versus (b) renting equipment that includes both the cost of the equipment and the maintenance, you would expect in a perfect (idealized) market that both would cost the same. ... (Slight tangent: Accountants are sticklers about how companies account for costs. Some systems differ in how owned equipment and rented equipment are treated. I'm not expert, but I have a healthy, painful respect for these considerations.) ... All of which would suggest that sooner or later, one way or another, you have to pay for that maintenance. Call it a cost or call it debt, does it really matter? In both cases, if you want to make widgets, you have to pay it. So, points for definition #2 for acknowledging that code requires maintenance which, like it or not, implies a debt/cost. So, I can see why people prefer either. I kind of like to embrace the tension, so I like both. But if you need resolution, it can be found! :) The difference between these views is only a matter of the baseline. Another Arbitrary Table technical debt technical debt option definition 1 definition two ------ -------------- -------------- perfect code 0 300 imperfect code 400 700 In both cases, the net difference is 400. Of course, this works for addition, but not so well for division. Since division by zero is undefined, I tend to prefer definition #2! [1]: https://www.reddit.com/r/programming/comments/8w8s03/all_code_is_technical_debt/ https://www.reddit.com/r/programming/comments/8w8s03/all_cod...

throwaway1777 7y ago

Bazel is hardly new, it’s been in use at Google for many many years as Blaze.

willtim 7y ago
This is misleading. Bazel is full of brand new code and only parts of it have been in use at Google as part of Blaze.
- laurentlb 7y ago
  No. I work on Blaze/Bazel. The vast majority of the code is shared between Blaze and Bazel. Examples of Bazel-specific code include support for Windows and support for external deps (needed for multirepos and interaction with package managers). The core is exactly the same.
  - willtim 7y ago
    My employer encountered lots of basic bugs, like file handle exhaustion, which together with the amount of recent activity in GitHub, suggested to me that there is a lot of new code in Bazel. If it's essentially the same as Blaze as you say, then why the new name?
    - hanwenn 7y ago
      I was there when the name was selected. It turns out "blaze" suggests speed, which is why it was a popular name for other software, and some of it was registered as trademark.

_the_inflator 7y ago

I side with you. Why build Angular, React? There was jQuery... After all, there are only tools. If you need a better tool, build it and ignore the naysayers. Everything is an experiment. If it inspires people, the better.