I think the internal web tooling was pretty good compared to anyone but AWS circa 2016 but by 2020 when I left it felt a bit antiquated. Similarly they didn't have linters rolled out until it was industry standard iirc.
But BCL is still the worst language I've ever used.
> I'm an SRE and I think it's quite likely the best infra language I've ever seen.
I only worked with 4-5 SREs and they all grudgingly tolerated it. What did you like about it, compared to other infra languages you've used professionally?
Every SRE I've worked with has said different things, though at the time the controversy was around Piccolo. It flip-flopped between shiny new thing vs deprecated. Then the SREs I worked with got laid off, and I started cargo-culting the Piccolo we had lying around.
See my reply here: https://news.ycombinator.com/item?id=49216714. The hatred of BCL was due to people not understanding the benefits of a restricted language with carefully chosen semantics, and stubbornly insisting in "a real programming language".
I still don't understand why all that dynamic config stuff isn't just Python. Sure, static configs should be protos, but GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python. Have heard some language purity rants involving determinism, but I don't buy it. And they keep inventing new stuff like Starlark. They need to stop.
> GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python.
The GCL designers made several mistakes in its design, but the worse was the lack of a versioning that would make language evolution easier, as well as interoperability between different versions. GCL2 solved some issues, mainly cleaning up the interpreter. Still, BCL is IMNSHO by far the best infra language there is.
> But it's almost a general-purpose language, so why not just use one?
The usefulness of not being a general-purpose language it that it makes static analysis very good; that's what made the BCL-based tooling so useful: being able to easily diff two versions of the same module (a tool called UBdiff), compute the transitive closure of a module's dependencies, trace the execution of BCL code and correlate it with the AST, to point out where an error comes from.
All these features were either unavailable or took years to develop for Piccolo, because Piccolo was based on Python.
> I'm still not seeing why a DSL was necessary or helpful.
BCL has distinct evaluation rules and a notation that encodes many patterns that SREs used for defining services, and that made BCL code much more compact and easy to ready than all the alternatives.
BCL was designed to be unidirectional: a module was evaluated locally, and the result sent to the Borgmaster. Compare that to Terraform, whose execution model consists of an execution tree where some nodes come from RPCs, meaning that it's not generally possible to statically analyse a TF module, because some errors can come from from feeding RPC results into new RPCs, and execution often fails after tens of minutes. All very janky.
Thanks for the detailed explanation. I get the appeal of this then, I just don't think it's worth. Whatever you do will produce some static proto in the end that can be diffed at least. General lang benefits from everyone understanding it and all the standard debug/test methods applying, which I'd much rather have than easier static analysis of the dynamic part. And yeah I was uninformed on Google's config langs, but so was my entire team for 7 years, all cargo-culting.
You're saying the general lang approach led to Piccolo, but that was still a DSL. It looked sorta like Python but it's not, you don't even call functions the normal way, and tons of magic stuff is happening, so just GCL/BCL except worse for the reasons you said. But they must've had a reason to try it. Seeing them continue changing around and making new languages says it's not just me, nothing is working well enough to stick. SREs weren't just arguing about which is better, they were asserting X is deprecated in favor of Y.
TF has seemingly stuck outside. I'm still not a fan of that being a DSL, but at least it's one tons of people use and now Claude can easily handle.
> General lang benefits from everyone understanding it and all the standard debug/test methods applying, which I'd much rather have than easier static analysis of the dynamic part.
Perhaps. I consider that a very narrow view that's detrimental on the long term.
> But they must've had a reason to try it.
They were obsessed with using a general-purpose language, and Python was the thing they knew.
> SREs weren't just arguing about which is better, they were asserting X is deprecated in favor of Y.
This is a kind of dishonesty I saw a lot at Google.
> TF has seemingly stuck outside. I'm still not a fan of that being a DSL, but at least it's one tons of people use and now Claude can easily handle.
Unfortunately Terraform still has significant flaws that prevent it from being used in a reliable fashion.
But BCL is still the worst language I've ever used.