3 ms·

Why do you think this author (a long-time senior Blaze maintainer) believes this? Do you think the Blaze team just not have the necessary expertise?

jeffbee 2y ago
I have no idea but dismissing Java as not "a real systems language" just isn't a convincing critique.
- lostdog 2y ago
  For one, Java programs always take too long to start, and that's not something you want in a program that's supposed to be interactive.
  - jeffbee 2y ago
    See, that's exactly the type of uncritical statement that will force me to discount the rest of your statements on a whole range of topics. bazelisk help 0.01s user 0.00s system 26% cpu 0.053 total
    - lostdog 2y ago
      Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?
      - jeffbee 2y ago
        Literally everyone who uses bazel uses it client-server as a persistent daemon.
        lostdog 2y ago
        And part of why it's a persistent daemon is because Java is slow to start up. I'll note that bazelisk is written in Go.
        jeffbee 2y ago
        Exactly. And a Go program that forks a Java program that makes an RPC is still faster than `cargo help`
        sunshowers 2y ago
        Demonization introduces a range of potential cache invalidation issues. The issues are solvable, but whose KPIs depend on getting to the bottom of them?
        joshuamorton 2y ago
        Do you have specific examples in the context of blaze/bazel here? I think "the set of cache invalidation issues" you're describing are basically "the set of cache invalidation issues blaze/bazel intends to solve", so the answer to "whose KPIs" is "the blaze team".
        sunshowers 2y ago
        I haven't used Bazel but I have used buck1 extensively, and the daemonized mode was quite buggy and often required the process to be killed. Quite frequently the process was just wedged, and even when it wasn't, memory leaks were quite common. Standard black box debuggers like strace and DTrace also become harder to use (e.g. you need to attribute a particular set of syscalls to a client, and a mindless "strace buck build ..." doesn't do what you want). Daemonization is sometimes necessary, but it introduces lifecycle management problems that get in the way of robustness. Daemonization simply because your choice of programming language has bad startup times doesn't seem like a great idea to me. I think on-disk cache invalidation and in-memory cache invalidation are distinctly different in practice.
        jeffbee 2y ago
        > I haven't used Bazel That was the perfect place to end the comment.
        sunshowers 2y ago
        Are you saying that daemonization doesn't make black box debugging harder?
        joshuamorton 2y ago
  - aseipp 2y ago
    I don't disagree in general but in Bazel's case this path has been heavily optimized. Maybe there are limits to it but "java startup slow" is a 101-level complaint. In fact, I don't even think the client program for Bazel is written in Java, but C++, and the Java daemon it talks to is started when you first attach to a Bazel workspace and it persists, so subsequent interactions are very fast. Just running `bazel` randomly is not truly indicative of what using it feels like, because that's not what people actually use it for. People use it inside a build workspace, that is the case that matters. Beyond that, other build systems like Buck2 (Rust) also use the client-daemon architecture for a number of other reasons, including the fact that actually-really-large build graphs are far too large to rebuild on every invocation, so the daemon is necessary to keep the build graph and interactively analyze and incrementally invalidate it on demand. Doesn't matter if it's Rust or Java, these things are architectural. That's also one of the points of the article, of course, and why they're theorizing about server-side analysis caches and graphs, etc. This all indicates to me that the people designing these systems actually do care about interactivity of their tool. It is not a matter of "java startup slow" to use a client-server design, though it certainly is known to help.
- jmmv 2y ago
  As I said in the article, the lack of green threads, lack of value types, and lack of primitive boxing are all things that have gotten in the way of optimizing Bazel to the levels shown by the prototype Go reimplementation. These are all things that you'd expect a systems language to have, and Java did not have them. These are finally materializing now, but it's a little too late. Then you also have the slow startup time of the JVM plus Bazel's initialization, which leads to a possibly-unnecessary client/server process design. This is more wishy-washy though, as this might be optimizable to levels where the startup time is unnoticeable -- but the fact that it hasn't happened in years means that it might not be an easy thing to do.
  - aseipp 2y ago
    FWIW, the client server design is also used in Buck2, but it has other advantages than just startup time, like keeping track of the filesystem with inotify or watchman so that it already has fresh information about the state of the build graph by the time you run `build`.
- sunshowers 2y ago
  For example, Java's signal handling is not up to par with systems languages. CLI tools that orchestrate operations need to have high-quality signal handling in order to be robust.

jeffbee 2y ago

I have no idea but dismissing Java as not "a real systems language" just isn't a convincing critique.

lostdog 2y ago
For one, Java programs always take too long to start, and that's not something you want in a program that's supposed to be interactive.
- jeffbee 2y ago
  See, that's exactly the type of uncritical statement that will force me to discount the rest of your statements on a whole range of topics. bazelisk help 0.01s user 0.00s system 26% cpu 0.053 total
  - lostdog 2y ago
    Takes 1.97s on my machine, which is a lot of time for just showing a help message. Maybe you have the setup where Bazel is staying alive in the background or something?
    - jeffbee 2y ago
      Literally everyone who uses bazel uses it client-server as a persistent daemon.
      - lostdog 2y ago
        And part of why it's a persistent daemon is because Java is slow to start up. I'll note that bazelisk is written in Go.
        jeffbee 2y ago
        Exactly. And a Go program that forks a Java program that makes an RPC is still faster than `cargo help`
      - sunshowers 2y ago
        Demonization introduces a range of potential cache invalidation issues. The issues are solvable, but whose KPIs depend on getting to the bottom of them?
        joshuamorton 2y ago
        Do you have specific examples in the context of blaze/bazel here? I think "the set of cache invalidation issues" you're describing are basically "the set of cache invalidation issues blaze/bazel intends to solve", so the answer to "whose KPIs" is "the blaze team".
        sunshowers 2y ago
        I haven't used Bazel but I have used buck1 extensively, and the daemonized mode was quite buggy and often required the process to be killed. Quite frequently the process was just wedged, and even when it wasn't, memory leaks were quite common. Standard black box debuggers like strace and DTrace also become harder to use (e.g. you need to attribute a particular set of syscalls to a client, and a mindless "strace buck build ..." doesn't do what you want). Daemonization is sometimes necessary, but it introduces lifecycle management problems that get in the way of robustness. Daemonization simply because your choice of programming language has bad startup times doesn't seem like a great idea to me. I think on-disk cache invalidation and in-memory cache invalidation are distinctly different in practice.
        jeffbee 2y ago
        > I haven't used Bazel That was the perfect place to end the comment.
        sunshowers 2y ago
        Are you saying that daemonization doesn't make black box debugging harder?
        joshuamorton 2y ago
- aseipp 2y ago
  I don't disagree in general but in Bazel's case this path has been heavily optimized. Maybe there are limits to it but "java startup slow" is a 101-level complaint. In fact, I don't even think the client program for Bazel is written in Java, but C++, and the Java daemon it talks to is started when you first attach to a Bazel workspace and it persists, so subsequent interactions are very fast. Just running `bazel` randomly is not truly indicative of what using it feels like, because that's not what people actually use it for. People use it inside a build workspace, that is the case that matters. Beyond that, other build systems like Buck2 (Rust) also use the client-daemon architecture for a number of other reasons, including the fact that actually-really-large build graphs are far too large to rebuild on every invocation, so the daemon is necessary to keep the build graph and interactively analyze and incrementally invalidate it on demand. Doesn't matter if it's Rust or Java, these things are architectural. That's also one of the points of the article, of course, and why they're theorizing about server-side analysis caches and graphs, etc. This all indicates to me that the people designing these systems actually do care about interactivity of their tool. It is not a matter of "java startup slow" to use a client-server design, though it certainly is known to help.
jmmv 2y ago
As I said in the article, the lack of green threads, lack of value types, and lack of primitive boxing are all things that have gotten in the way of optimizing Bazel to the levels shown by the prototype Go reimplementation. These are all things that you'd expect a systems language to have, and Java did not have them. These are finally materializing now, but it's a little too late. Then you also have the slow startup time of the JVM plus Bazel's initialization, which leads to a possibly-unnecessary client/server process design. This is more wishy-washy though, as this might be optimizable to levels where the startup time is unnoticeable -- but the fact that it hasn't happened in years means that it might not be an easy thing to do.
- aseipp 2y ago
  FWIW, the client server design is also used in Buck2, but it has other advantages than just startup time, like keeping track of the filesystem with inotify or watchman so that it already has fresh information about the state of the build graph by the time you run `build`.
sunshowers 2y ago
For example, Java's signal handling is not up to par with systems languages. CLI tools that orchestrate operations need to have high-quality signal handling in order to be robust.