Bazel 1.0

A lot of people have it for compliance reasons.

Does anyone know of a real beginners level guide to Bazel that isn’t the docs. Got a typescript monorepo with a few backend services/react frontends I wanted to build and I got a bit lost in the complexity of it due to package.json handling

Java starts up in ~1s, something like Graal could make this faster. But I find this Java criticism more a symptom of Java-derangement syndrome, because python and node build systems have even worse startup times and no one says anything.

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_cod...

We didn't have Bazel on ARM for NixOS because we can't bootstrap openJDK on ARM. There's no source code for a JVM that compiles on ARM afaik. Though in theory we could package binary blobs from oracle and bootstrap JDK and Bazel from there, it means now our trust path for your critical build tool has a random Oracle blob in its trust path there that is extremely hard to get rid off.

Build systems should be easy to build. Bazel is not by a far shot due to java being a mess in this area (ironic given it being advertised as a cross platform language).

These issues are not important for everyone perhaps. (Heck the entire Kubernetes ecosystem pulls random binaries from docker hub without any cryptographic signatures.) but it's still a shame; especially for a build system.