[badoongi]

I've been working through a legacy starlark codebase recently. My take is that the language, and the bazel phased execution model, makes it very challenging to debug.

One example: as far as I can tell there is no way to get the Starlark call stack, this is a tool you really want for printf debugging (which is your main debugging tool with Starlark), I can't find it right now but I believe I saw them say that they don't want to give access to the call stack for performance reasons which I find odd - is the bottleneck in slow bazel builds close to be starlark execution time?

Also looking at a non trivial Starlark codebase that didn't mature well, I can't help but wonder if it wasn't better to not give engineers as much flexibility for their build configuration, yes, they'll have some copy pasted configuration snippets that could look tighter with a macro, but you are less likely 5 years later to look at a monster that is slow and hard to debug.

[larsrc]

I (Bazel SWE at Google) agree with the too much flexibility being a problem. It's difficult for tools to work on complex Starlark code, so we encourage more copy and paste especially in BUILD files. But I don't think Blaze could have scaled to Google's needs without some amount of programmability. It's not just that it "looks tighter with a macro", when you have a rule that gets used to create millions of targets, you can't just copy and paste. You need to be able to systematically change it.