On: Don't Use Protobuf for Telemetry

[kentonv]

Thanks!

Though in retrospect, I don't know if proto2 was a net win, given all the migration pain it caused. If I were doing it again I would take a more incremental improvement approach on proto1. It would have taken a lot longer but with less pain, I think. That said... who knows if that would have resulted in a better or worse outcome. Open sourcing would have taken a lot longer.

Had I realized at the time that I was taking on a project with no good solutions... heh.

[haberman → kentonv]

Yes, protobufs are a very interesting and fulfilling technology to work on, but also frustrating because there is so much API exposure that changing any existing API is like trying to run through molasses. A clean break a la proto1->proto2 opens up lots of possibilities on a much shorter time scale, but also creates a heavy migration burden.

There are lot of improvements we can make without touching API, but whenever the API itself is a barrier to further improvements, there are just few good options for managing that.

Your point about incremental changes reminds me of the Linus rant about "bundling", where he argues that incremental changes lead to a better result than a big bang rewrite: https://yarchive.net/comp/linux/bundling.html I very much agree with that approach when possible, but Linux has the benefit of a much narrower API offered to its users. The protobuf API is not only the API of the core library, but of every generated class. The massive surface area just makes any kind of change to generated APIs an enormous challenge (for example, returning string_view from accessors instead of std::string).