I'm generally happy with Blaze/Bazel, so I'm not necessarily in the target market for Moonrepo, I guess.
EDIT: This isn't really competing with Blaze/Bazel either when I look at the execution model. It goes back to imperatively defined tasks instead of declaratively defined dependencies, which feels more spirtually aligned with Make than Blaze/Bazel.
Have you actually talked to Blaze/Bazel users to understand what frustrations (if any) they have with their current build system? Have these users asked for a Bazel-lite? If so, and you still want to position yourself as Bazel-lite, then you should include some of their direct feedback and write your messaging accordingly.
As a daily Blaze/Bazel user, I don't have a desire for a Bazel-lite. I've worked at a midsize company that used Bazel, and I'm working at the company that created Blaze/Bazel.
Disclaimer: Opinions expressed are my own; not representative of my employer.
Bazel doesn't work well for every language, but for those languages that it does, it definitely makes sense to use Bazel. For those languages that work better with something more lightweight, that's where moon comes in. I'm assuming you work at Google, so you're experience around Bazel is probably much better than those that don't work at Google.
I appreciate all the feedback and comments though, very much appreciated.
Better “monorepo-ish” (whatever that means in the frontend world) tools are still valuable, but as OP said, it's pretty crowded here.
I don't know if you have talked with people working on C++ or Java projects (I see that these are not among your supported languages), but if you do, you get to see why people are talking about Bazel.
- Distributed cache of built artifacts. Work with my company's network topology and security requirements. Make this easy to setup, operate, and seamless for developers to opt into
- Seamless monorepo support (multiple languages)
That could be considered Bazel-lite. And yes, I'd take it over Bazel currently.
If you don't work at Google, convincing your engineering organization into learning Bazel is almost always a non-starter. Who uses Bazel in the wild? Xooglers primarily.
Their value proposition is sound.
[1]: https://www.youtube.com/watch?v=t_3bckhV_YI
[2]: https://www.youtube.com/watch?v=H67uuwVO1tc
[3]: https://www.databricks.com/blog/2019/02/27/speedy-scala-buil...
Large companies, with established platform / ops teams, who can support Bazel and push for its adoption within an engineering organization definitely exist. There's probably a few Xooglers working there who'd like to see it happen too.
My response shows these hypotheses to be false. You’re correct, no one’s arguing whether Bazel is useful or worthwhile, not even I.
> Large companies […] who can support Basel within an engineering organization definitely exist.
Ok great, we agree. You’ve revised your point from earlier.
> There’s probably a few Xooglers […]
A baseless hypothesis that’s confirmed false by all the references shared with you. Feel free to plug all the lead engineers’ names into LinkedIn to verify that the majority are not ex-Google.
> Bazel-lite may be enough.
Sure, it may be. That’s why I’m offering the constructive feedback to go talk to the thousands of active Bazel users to see whether and what they want from a Bazel-lite, if that’s the positioning Moonrepo wants to choose.
Usually, there’s a strong rationale and need behind an organization’s adoption of Bazel. Some of that rationale is captured in the references shared earlier. These organizations need Bazel; they’re generally happier with Bazel than their previous systems. These baseline needs represent table stakes for any build system that wants to compete with Bazel.
If Moonrepo wants to compete where Bazel is weak, then I’m suggesting that they need to sharpen their communication such that an engineer well-versed in Bazel has an “aha!” moment within 2 minutes. The proverbial elevator pitch.
Once again, I’m not dissuading Moonrepo from pursuing their vision. I’m offering constructive feedback on their messaging/positioning — the type of feedback I’d like to hear as a founder.
Even in my original reply:
> If you don't work at Google, convincing your engineering organization into learning Bazel is almost always a non-starter. Who uses Bazel in the wild? Xooglers primarily.
Emphasis on almost since you've missed it three replies now.
What are you even getting at here? I freely admit that some companies adopt Bazel. Many do not. You doing a Bing search to find the ones that do doesn't change that fact.
> Ok great, we agree. You’ve revised your point from earlier.
I haven't revised anything. You misread, but feel free to be needlessly hostile defending a product your current employer makes against a newly launched competitor. I use the word competitor loosely. It's not a good look either way.
> That’s why I’m offering the constructive feedback to go talk to the thousands of active Bazel users to see whether and what they want from a Bazel-lite, if that’s the positioning Moonrepo wants to choose.
Why would they need to talk to people who are actively using Bazel to see if they want Bazel-lite? It's a small population that's already, presumably, well served.
There's a whole other, much, much larger segment of customers who'd love to use Bazel-lite that aren't using Bazel, for many reasons, including the high cost of adopting and supporting it. I'm one of those customers. Unsure why this point escapes you.
Your advice, by the way comes off as attacking their idea and trying to tear it down regardless of how many times you preamble it's constructive criticism.
Clearly, you've never used Gradle.
The second reason is we wanted something language agnostic and not proprietary. It also helps that many other tools, like GitHub actions, are written in YAML.
And lastly, we wanted a format that developers are familiar with, and won't need to spend time learning. Requiring developers to understand a special syntax simply to define a task to run is something we want to avoid.
It's really 'do you make config an artifact, or do you make it code' sort of argument.
I can see the benefits of "generating code" within the BUILD file, but honestly, we haven't required it yet, and have been able to do most things with explicit configuration. Our token syntax helps with some dynamic aspects of this.
Maybe in the future we'll revisit this.
However, I think for describing actual build toolchains this way of implementing things might end up being significantly more complicated (and require even more arcane end-user cognitive load) than the Starlark/Python-based build rule / toolchain / constraint approach for actually assembling libraries, binaries, and other compiled artifacts. There are a combinatorial number of backends, conditional options settings, etc. which will be hard to capture with a purely declarative system. For instance, a C++ binary might needs platform-specific compiler flags, or some #ifdef nonsense. YAML doesn't have a clean way of implementing conditionals based on some constraint. So for heterogenous ecosystems (C/C++, Python, container assembly, GPU development, microcontrollers, etc.) this pushes a ton of complexity into the build rules themselves which may be opaque to end users (and thus introduce a ton of cognitive load, steep learning curves, hard-to-debug errors, etc.).
Once we starts supporting more languages, especially compile based ones (probably Rust first), our decision around YAML will probably change. Off the top of my head, a non-YAML format would probably be used as a secondary format, kind of like how a Dockerfile works.
You will end up developing your own yaml-based DSL that is incompatible with everything else, has weird limitations and poorly documented constraints... just like any other YAML-based system.
And by the time you'll have written a 1000-line YAML (where half of the file is nothing more than awkwardly quoted and escaped bash scripts) and realise that YAML cannot be split into reusable files, it will already be too late.
Oh. I just saw that you already use a custom non-standard extension of YAML with `extends` so there you are
As I understand it, the primary reason these build systems leverage these Python-variants is so that the build rules, toolchains, constraints, and build definitions can all be written in the same language (since build rules often require some programmatic behavior). Perhaps with a future vision of them being totally interoperable across build systems.