4 ms·

I worked at Coinbase for four years, where Bazel is the build system of choice. It's so so much worse than the homegrown software it replaced. Hermetic sounds

I worked at Coinbase for four years, where Bazel is the build system of choice. It's so so much worse than the homegrown software it replaced. Hermetic sounds nice in theory, but doesn't actually matter and comes with a massive cost. 1. Bazel is slow. Like really fucking slow compared to your native build tools. Startup time can be insane if you use multiple rules (languages) in your repo. There's a great feeling when you get to work in the morning to build your go project but you have to install the latest python, nodejs, and ruby toolchains because someone updated them on master. The cache works well, except with a 1000 devs something will always be invalidated on master. 2. The documentation sucks. It's written to explain concepts with how things work, with no examples of how to actually complete tasks you care about. Of course that wouldn't help either because the bazel setup you're using is heavily customised. 3. Everyone on your team now has to learn yet another DSL, and a bunch of commands to run. I would easily spend 5 hours per week either waiting for, or debugging some issue in bazel. All this for what benefit? Everyone's on the same version of a dependency? Not even sure this is a desirable property. Also the monorepo is slow as jelly to work with and many tools or editors struggle to open it. Good luck getting code completion to work well too. It's one of those ideas that are nice in theory, but awful in practice. It's possible that with enough manpower you may be able to use it effectively, but we certainly were not.

zquestz 4y ago
I second this. Bazel is more trouble than it's worth.
traceroute66 4y ago
> Bazel is slow. Like really fucking slow .... Probably because its written in Java. What sane person writes Java in the 2020s ? I mean, aside from having to dance the JVM maintenance dance, you're also faced with the fact that Java is a memory hog unless you spend half your life tweaking obscure parameters in XML files. The sooner Java dies the better, frankly. Java was great back in the day, even ahead of its time, but today it's just a relic. Use Go, use Rust ... hell, practically anything is better than Java.
- mi_lk 4y ago
  lulz, the audacity to naively claim Java should die in favor of other cool kids, couldn't be more HN than that
- Cthulhu_ 4y ago
  Java itself isn't necessarily slow, it's the application design. Would it benefit from being compiled with GraalVM?
  - bheadmaster 4y ago
    > Java itself isn't necessarily slow, it's the application design. Java itself is a language, and cannot be slow or fast. However, the most popular (and thus well-supported) implementations of Java are slow. On those implementations, the idiomatic way of writing Java leads to massive amounts of memory allocations, which force Garbage Collector to allocate much more memory than it needs and perform complex collection strategies. Many allocations also destroy memory locality and completely negate the effect of CPU cache. > Would it benefit from being compiled with GraalVM? Maybe, maybe not. But GraalVM, at least for now, is not the standard way of running Java programs. I think the point of the parent comment was that it's bad to choose Java for anything other than long-running server-side applications (where JIT compilation with Hotspot might actually prove valuable for squeezing out those last few percent of throughput). For anything else, Java is really a sub-optimal choice - the startup time is horrible, the speed is not really great, and the JVM maintenance is painful. For a build tool, which is invoked many times to do relatively small amounts of work (compared to long-running server-side applications), it just doesn't make sense.
    - oftenwrong 4y ago
      >For a build tool, which is invoked many times to do relatively small amounts of work (compared to long-running server-side applications), it just doesn't make sense. Bazel makes use of a client-server architecture. Java is used for the server component, for which startup time is not an issue. The CLI client is written in C++.

zquestz 4y ago

I second this. Bazel is more trouble than it's worth.

traceroute66 4y ago

> Bazel is slow. Like really fucking slow .... Probably because its written in Java. What sane person writes Java in the 2020s ? I mean, aside from having to dance the JVM maintenance dance, you're also faced with the fact that Java is a memory hog unless you spend half your life tweaking obscure parameters in XML files. The sooner Java dies the better, frankly. Java was great back in the day, even ahead of its time, but today it's just a relic. Use Go, use Rust ... hell, practically anything is better than Java.

mi_lk 4y ago
lulz, the audacity to naively claim Java should die in favor of other cool kids, couldn't be more HN than that
Cthulhu_ 4y ago
Java itself isn't necessarily slow, it's the application design. Would it benefit from being compiled with GraalVM?
- bheadmaster 4y ago
  > Java itself isn't necessarily slow, it's the application design. Java itself is a language, and cannot be slow or fast. However, the most popular (and thus well-supported) implementations of Java are slow. On those implementations, the idiomatic way of writing Java leads to massive amounts of memory allocations, which force Garbage Collector to allocate much more memory than it needs and perform complex collection strategies. Many allocations also destroy memory locality and completely negate the effect of CPU cache. > Would it benefit from being compiled with GraalVM? Maybe, maybe not. But GraalVM, at least for now, is not the standard way of running Java programs. I think the point of the parent comment was that it's bad to choose Java for anything other than long-running server-side applications (where JIT compilation with Hotspot might actually prove valuable for squeezing out those last few percent of throughput). For anything else, Java is really a sub-optimal choice - the startup time is horrible, the speed is not really great, and the JVM maintenance is painful. For a build tool, which is invoked many times to do relatively small amounts of work (compared to long-running server-side applications), it just doesn't make sense.
  - oftenwrong 4y ago
    >For a build tool, which is invoked many times to do relatively small amounts of work (compared to long-running server-side applications), it just doesn't make sense. Bazel makes use of a client-server architecture. Java is used for the server component, for which startup time is not an issue. The CLI client is written in C++.