21–30 of 204 posts
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.
Why do you care if a JVM is on your dev machine?
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.
For me the obstacle for using make is, it is not available for windows and even if I install via msys2 or cygwin, it is hard it make Makefiles independent of OS. I am not sure Bazel is the answer. BUILD files feel verbose and need more effort to maintain than platform specific files(go.mod, Cargo.toml, pom.xml).
Is it worth giving up language-specific build tools (CMake, Maven, Gradle and others) for one build tool to rule them all?
My experience with using the Google-internal version of Bazel is that yes, you want to give up all other tools to use this. Having a proper dependency graph makes it possible to cache maximally and accurately, and that results in fast builds. You don't need it if you only have like one go program that you're building, but you will start to see the disadvantages when you have a handful of things you build. Did you bui…
I've never experienced any of this. Maybe because I use OpenJDK?
Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.
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.
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.
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.
Parts of Bazel are written in C/C++. The command line client as well as some low level file utilities. But Bazel is distributed as a standalone package in several packaging systems; no need to install Java yourself. Though I doubt many people know this; there's virtually no reason you would be exposed to its language implementation choices. EDIT: Actually I believe Bazel is changing its .deb package to not be standal…
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 times and not using a server design like basically every other build too.
But my information might be out of date. That's what always soured me on it previously, though.
Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.
Did you ever use it, or at least see what a bazel build rule looks like [1] before calling it arcane?
[1] https://docs.bazel.build/versions/1.0.0/tutorial/cpp.html#un...
Earlier quoted context omitted.
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.
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 w…
* Asana * Databricks * Dropbox * Google * Huawei * Lyft * Pinterest * Stripe * TwoSigma * Uber ...
This is not a new project that needs pushing.
Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.
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.
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.
Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.
I wouldn’t call Bazel confusing or arcane, but it is powerful. I find it rather delightful to use.
- 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 my tests)
- the documentation was slow to load and hard to find things in (you basically had to use search, instead of browsing a good table of contents)
As I said, though, I'm a newcomer; it's quite possible there are good ways to do those things, I just hadn't managed to find it in the documenting yet. That and the issues are by no means unique to bazel.
I also do like some aspects of it (like enforced out-of-tree builds), but that's off-topic ;)