41–50 of 204 posts
Because I have a twisted fascination with controversy and tribalism on HN, here's a little red meat: I'm going to stick with using make to glue together whatever tools I need for my build and test processes. Edit: -5 in under 10m. And yet I didn't even say anything remotely controversial or normative. Fantastic.
Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?
No, we don't have to invent an idiotic DSL where declarative approach and sane defaults will do.
Earlier quoted context omitted.
> there's virtually no reason you would be exposed to its language implementation choices Um, doesn't it still have a client that starts up a persistent server and you then have to wait for that server to start up (which, being Java, takes forever) and then deal with those server processes hanging around? That sounds like being exposed to its language implementation choices. As opposed to, say, having fast start-up t…
Bazel doesn't start a server for Java JIT reasons. It starts a server for (1) concurrency control (2) management of worker processes some languages use (3) caching the build graph (recall that Bazel works with very large code bases). These reasons are independent of implementation in C++, Go, Rust, Java AOT, etc. (And yes it doesn't have to use a persistent process to solve these problems. That is the solution it cho…
How much did the fact that Java is very slow starting up influence the decision to use a persistent process instead of some other solution?
Earlier quoted context omitted.
I wouldn’t call Bazel confusing or arcane, but it is powerful. I find it rather delightful to use.
As a relatively newcomer to bazel, I did find it arcane: - I couldn't find an easy way to list targets - in particular, a way to show me the path to the build artifacts (so that I could inspect it in my editor) - I couldn't find a way to do build configurations (especially intersections of build configurations) - it didn't seem great at handling non-file build steps (set up a cluster / server / whatever so I can run…
bazel query //some/package:*
bazel query //some/package/...
Earlier quoted context omitted.
Sure, but don't ignore the fact that new things are technical debt. Maybe they're worth it, but they're still debt.
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 migrat…
I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.
Earlier quoted context omitted.
Bazel doesn't start a server for Java JIT reasons. It starts a server for (1) concurrency control (2) management of worker processes some languages use (3) caching the build graph (recall that Bazel works with very large code bases). These reasons are independent of implementation in C++, Go, Rust, Java AOT, etc. (And yes it doesn't have to use a persistent process to solve these problems. That is the solution it cho…
> (And yes it doesn't have to use a persistent process to solve these problems. That is the solution it chooses.) How much did the fact that Java is very slow starting up influence the decision to use a persistent process instead of some other solution?
I do know that Go wasn't an option :)
(Because it didn't exist)