In general, I think it's good to limit how much stuff you depend on. Not in an extreme minimalist "write everything from scratch" sort of way, but in a "don't just needlessly add billions of lines of dependency code for the hell of it" sort of way. If you've decided to write a program in Java or another JVM language, you already have some JVM as a dependency, so you might as well use a build system written in it, but when nothing else depends on anything Java-related, I'm gonna need an incredibly good reason to add JVM as a dependency just to be able to use one build system instead of another. And IMO, Meson[1] is good enough, there's nothing I'm sorely missing from it and the build configuration doesn't end up as an unmaintainable mess, so switching it out doesn't seem to cross that threshold.
Then there are some reasons specific to Java itself. For one, the JVM is just incredibly slow to start up, and I hate having to deal with Java-based tooling. Gradle is infuriating to work with for that reason (and others). I'm also incredibly uneasy regarding anything made by Oracle, I definitely don't want to add a critical dependency on an Oracle product just to be able to use a build system which may or may not arguably be slightly better in some areas. I know OpenJDK is a community project, but it's one that's completely dependent on Oracle. With Oracle's recent-ish hostile moves regarding LTS builds of OpenJDK, I'm even more wary than normal.
[1] You may point out that Meson is written in Python, which means using Meson adds a dependency on Python. And yeah, I think that's totally fair, and I would respect someone's decision to use CMake instead of Meson to avoid adding all of Python as a dependency. But Python falls in a different category for me personally, because: 1) a lot of my projects end up with a build-time dependency on Python regardless of build systems, since Python is what I use for things like custom preprocessors and random scripts; 2) the sorts of systems I care about (Linux, macOS) tend to come with Python anyway; and 3) I trust the Python foundation way more than I trust Oracle.
For anything that doesn’t run in “humanly instant” timeframe the startup speed won’t matter - and build tools are definitely in this category.
The fear for Oracle is also completely irrational, Java is probably the safest bet ever — it is not tied to processor architecture, has a specification both on the language and the JVM level (both are uncommon in other platforms), has multiple completely independent implementation and the majority of fortune 500 companies definitely have business critical infrastructure running on top of it, so even if Oracle would do something those can single handedly support the platform indefinitely.
Especially that Oracle has been a surprisingly good steward of the language, and they were the ones that finished open sourcing everything.
> For anything that doesn’t run in “humanly instant” timeframe the startup speed won’t matter - and build tools are definitely in this category.
100% disagree. Waiting multiple seconds as the tool starts up just to get to the point where it actually invokes a compiler is infuriating to me. If you don't have a problem with that, good for you I guess.
> The fear for Oracle is also completely irrational
Again, I 100% disagree. Have you seen how they're treating ZFS? And the lawsuit against Google shows that they consider copying their APIs to be copyright infringement, so I wouldn't bank on non-Oracle-sanctioned community re-implementations.
If you want to tie your C++ code to Oracle, I won't stop you, but I won't be doing that. I'm happy that you found a build tool you like. I will stick with one that's not based on Java.
> 100% disagree. Waiting multiple seconds as the tool starts up just to get to the point where it actually invokes a compiler is infuriating to me
I think Java’s startup time is often overblown, a hello world literally finishes in less than 0.1s, and that won’t significantly grow at the size of a build tool. Plus daemons are a thing. Also, there is not much point in starting the compiler when you don’t even know whether it is necessary.
As for ZFS, what do you mean? Not familiar with the situation, it is open-source and several open source OSs use it without any trouble. It’s just Linus’s overprotective stance against mixing two open-source licenses that makes it unmergable into the kernel, but I do use ZFS on linux every day, so where is the evilness of Oracle?
> I think Java’s startup time is often overblown, a hello world literally finishes in less than 0.1s
The problem isn't hello world, it's the start-up time of big jars. My experience tells me that JVM start-up time on actual large software projects is a real issue in practice. But I haven't used Bazel in particular; I'd be more interested in numbers for that than numbers for hello world.
> As for ZFS, what do you mean? [...] It’s just Linus’s overprotective stance against mixing two open-source licenses that makes it unmergable into the kernel
Haha, that's not right. The problem is that ZFS's license, the CDDL, is (intentionally) incompatible with the GPL, so you can't link CDDL code against GPL code. It's not just an issue with making it part of the main Linux tree either, it's probably not even legal for distros to even ship a ZFS kernel module, since that has to link against Linux's GPL code (according to common interpretations of the licenses; Canonical notably disagrees).
And let me repeat that this mess was intentional on the part of Sun when they made the CDDL (see https://en.wikipedia.org/wiki/Common_Development_and_Distrib...), and it remains intentional on the part of Oracle as they choose to keep ZFS under the CDDL.
The mechanism which prevents Linus from merging ZFS into the kernel, and the mechanism which prevents distros from shipping ZFS out of the box, is the exact same mechanism which prevents Linus from merging any other GPL-incompatible code or distros from shipping any other GPL-incompatible kernel modules.
Nothing is stopping any individual from grabbing the OpenZFS source code and linking it against their Linux kernel; that's legal. Oracle is just doing its best to prevent people from combining OpenZFS and Linux into one package and distributing the result.
From your description I literally only see that “Oracle did nothing at all”, which might be a conscious decision, but it’s not like ZFS would be some secret money grab scheme or something like that.
I'm not saying ZFS is a secret money grab scheme. I'm saying I don't trust Oracle and the way they're hamstringing ZFS is one of many reasons why.
But I think I'll leave the discussion here, it's not about build systems anymore. As I have already said, if your take on Oracle is that they're a trustworthy company and a good steward of crucial parts of your stack, go ahead and use Bazel, I'm not stopping you.
I think the problem is that there is no good cross-platform build tool and as a project grows it almost always depends on some other runtime/language.
I don't want to manage Cargo.toml or requirements.txt or pyproject.toml or package.json or whatever. It's all the same stuff - just a dag of dependencies, each has it's own type and output and build pipeline and defaults and env vars etc.
Bazem, from what I've heard, is the best. Maybe that is the reason for the lack of adoption - it's very good but not good enough?
Bazel is good on many fronts, but it is quite specific to a google-like huge mono-repo structure, where your dependencies are also checked out into the same repo. I believe it can be circumvented, but the base model is that.
