, 13 tweets, 2 min read
My Authors
Read all threads
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.
Missing some Tweet in this thread? You can try to force a refresh.

Keep Current with Jaana Dogan

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!