Hi, a heretical question (while im looking at the massive androidx gradle build) why do people go for bazel over gradle? From what I gather its very much not batteries included, complex etc. whats the thing that at scale cracks first in gradle?

The idea now I get is that config times are the threshold? (Since compiles are just delegating to compilees which is the same?). If so, wont isolated projects make this argument obsolete?

I didn't think that is correct. Even if compiles are given to compilers, in daily working it is still majorly significant, for example whether you give will classes of a source set to the compiler, or only the changed ones and the ones depending on the API of the changed ones and so on. But yeah, regarding configuration times configuration cache - except for an initial build - and isolated projects probably help very much.

Slack Android devxp team shared their experience with Bazel recently at Droidcon London -

I think what most lack is the Project view feature of bazel in intellij Isnt there some work on that front?

performance for very massive monorepos

It sounded to me like config changes but im not sure if i got that right

yup, config cache gets you only so far, if a cache miss means 10+ min config time then you start to look at the alternatives

okay and if I put config time to the side, is there anything else?

it's a slightly different tool with it's own quirks, some might value it's correctness and it might have a better polyglot story, depending on the languages you need

so 90% is gradle config time being unreasonable?

from my experience it's definitely an overkill in almost all cases so unless you're feeling the pain in specific areas which Bazel solves you're better of sticking with Gradle, especially if you have a pretty vanilla JVM build

yea I like gradle, just wondering what the issue at hand is, I only have 1M loc codebase and never had urge to switcj

maybe ¯\_(ツ)_/¯

re IP (Isolated Projects), Gradle has been promising that publicly for about 5 years. I say that with love in my heart; and I also think it's getting very close to production-ready if it's not already there. So, some very large monorepos (thousands of modules), which suffered from massive performance issues re config time and IDE sync performance, and which had the resources to investigate a switch and then make it—did so. This isn't something the average team can do in part because most teams are product teams and don't have dedicated build staff. On the performance side, you could literally run out of memory on the most expensive macbook pros available, and so staying with Gradle absolutely requires some custom tooling to pair down memory usage so that a build can actually complete. That can even happen in an Android builds with hundreds of modules, if it has several build types and product flavors. It can be practically impossible to

build

an app module in such a circumstance.

custom tooling in what sense, selectively

include

projects in

settings.gradle

? or composite builds?

here are some blog posts I've written on this topic: • https://developer.squareup.com/blog/herding-elephants/ • https://developer.squareup.com/blog/stampeding-elephants/ • https://engineering.block.xyz/blog/shrinking-elephants That last post in particular goes into great detail on what we did to improve IDE sync times. In particular, it talks about your question on selective includes. I also have a personal blog • https://autonomousapps.com/ (current) • https://dev.to/autonomousapps (deprecated)

oh youre autonomousapps? 😄 nice to meet you yes I read all those and was directly coming from shrinking elephants one question I had about that was, if I desync unrelated stuff, its still visible in the Project pane - and what's your opinion on hiding the desynced stuff - or do people learn to not care?

I have no idea if this works outside of the Cash JVM monorepo, but we wrote this intellij plugin specifically to hide unsynced stuff, at least from search. I don't think you want to hide all of it, because if you say are using the Spotlight plugin, then you can right-click on unsynced modules and add them to the synced set https://plugins.jetbrains.com/plugin/26748-gradle-monorepo In fact I wonder if the Spotlight IDEA plugin does than too 🤔

do you please know how many use it? or require it? vs just learn to ignore the unsynced stuff (i.e. it's not a big deal) (majority vs minority)

I personally ignore the unsynced stuff, but we had enough complaints about it (our team supported 500 product devs) that we went ahead and implemented a solution