Hi Brandon,
Thank you for the thoughtful write-up. There certainly is complexity in asynchronous programming, and I for one appreciate proposals on how to simplify. That said, I don't think this is a strong enough case to warrant adding a new language, in this case Rust, to Chromium.
While Rust may be a great tool for this use case, and the folks working in this area may feel good about using Rust, the reality is that we have to think about the larger code base and all of the engineers who are contributing to Chromium. This is why the
code guidelines say to stick to the current set of supported languages. Just to repeat what it says:
While there is likely always a slightly better tool for any particular job, maintainability of the codebase is paramount. Reducing the number of languages eases toolchain and infrastructure requirements, and minimizes the learning hurdles for developers to be successful contributing across the codebase.
Just to put that into perspective, I think it is important that we avoid unintentional barriers to contributions and to developers working on, say, ChromeDriver. If developers have to master a new language in order to do so, then that is a non-trivial barrier. We have to ask ourselves if that is worth it for the benefits of using that new language in such an instance.
To me the bar is very high to introduce a new language to Chromium. It has to be worth the cost for everyone to learn and worth the cost of everyone having to master not just that new language but also the existing language. There's no story for eliminating C++ in favor of Rust, so adding Rust means we have to support both.
My recommendation is to lean into the fact that Chromium is largely a C++ based project and work on improvements on how we do asynchronous programming to address the core issues that motivate you to consider Rust. I'm sure there are incremental and meaningful improvements we could make.
Again, I appreciate your thoughtfulness on this topic.
Thanks!
-Darin