Productionization new languages at Google is a lot of work. As a person who witnessed two attempts, this thread is what I learned. Google has an incubation policy for new languages. You start by being experimental, then become incubator and then graduate to a canonical language.
Being able to explain why you are introducing a new language and how you are going to do cost analysis is VERY CRITICAL at the proposal stage. You can't get around by underestimating this step.
Our SRE team has a lot of requirements from our languages. They enjoy identical contact surfaces with other languages, functional parity in terms of tools. But most importantly, SREs want to be able to understand and change the code base they support.
Focus on the operability aspects of the language runtime, and making the monitoring and debugging surface and tooling very similar to other languages. Extra credits if you can improve incident response with your new language.
It's a must to meet the operating system and architecture requirements from the runtimes and Google hardware-specific stuff's. Follow Borg's production-ready language requirements. You need all the essential debugging z-pages: /varz, /statz, /heapz, /profilez, ...
Readability is a must. You need a style guideline and a proper readability process. You need to figure out the early readability approvers. Then, where to put things in the monorepo? How to handle third-party packages, modules, etc? How do you vendor?
Then, it's an endless list of integrations with the developer tools we build in house. Build system support, developer tooling support, indexer support, testing and CI support, ... This list is endless and there is no easy way around.
Critical libraries! At Google, everything is in-house built and you need to provide client libraries for all the critical services. You also need a proto compiler. You can't push new services without gRPC support. If gRPC doesn't already have support for your language, good luck!
Essential runtime metrics should be exported and should have similar parity with other languages. You have to also have a plan for runtime version requirements, update policy and security patches policy. For example, we start using Go in production as soon as there is an RC.
Then we have other runtime policies and best practices. For example, graceful shutdown policies... A more granular example would be flushing logs on program exit. You have to document and provide convenience to these every day tasks.
engEDU and internal training comes next. You have to represent the language support internally all across the tech stack. You need high quality reference code for critical services and internal training programs to teach the internal flavors. You will need internal case studies.
Testimonials and success stories from other teams help the internal adoption! Especially large scale systems feel more confident once more examples of the new language exists in similar scales in production. It gives an idea about how mature the support and integrations are.
Working on languages at Google is hard work but it is a good opportunity to learn the entire stack end-to-end. It allows you to inherit a lot of knowledge and work with a large number of production users closely.
