GCL, an internal configuration language used at Google, was created in 2003, and after a few years of improvements it got to a point where it was impossible to change it. Its usage had grown too fast and users were depending on nearly all of its documented and undocumented behaviors so any change would break someone’s workflow.

The breaking point for inaction was when some user programs became so large, and required so much memory, that they couldn’t be run in user workstations.

Many attempts over the years to replace the language were unsuccessful. No replacement was good enough to warrant the migration costs. Infrastructure teams weren’t able to migrate users automatically, and their users didn’t have enough incentive to migrate on their own. After a while these efforts were deemed infeasible.

This talk tells the story of how we gradually evolved GCL, while staying mostly backward compatible, in what has been a huge scale migration effort.

Based on these constraints and our past successes, we’re pursuing the approach of evolving the language in place, one semantic change or feature at a time. We will be simplifying the semantics, replacing constructs that are error-prone with simpler ones and adding features to make it easier for users to understand their programs.

We’ve developed tools to validate the effect of a change to the interpreter on our whole codebase, mechanisms for gradual rollout, which combined with the techniques for rolling our large-scale changes across the mono-repo allow our small team to centrally manage the rollout of a semantic change to our whole codebase.