There are some legit criticisms here (remember, protobuf is a more than 20 years old format with extremely high expectation of backward compatibility so there are lots of unfixable issues), but in general this article reveals a fundamental misunderstanding of protobuf's goal. It is not a tool for elegant description of schema/data, but evolving distributed systems composed of thousands of services and storage. We're not talking about just code, but about petabytes of data potentially communicated through incomprehensible level of complex topology.
Yeah, I stopped reading at "by far, the biggest problem with protobuffers is their terrible type-system" for similar reasons. What did the author want, ASN.1? Cause that gives you a full type system, except that's not what I want.
Edit: kentonv's rebuttal says this too. "This article appears to be written by a programming language design theorist who, unfortunately, does not understand (or, perhaps, does not value) practical software engineering." And when my angry hat is on, this is also how I would generalize programming language design theorists.
Funny you should mention ASN.1. Protobuffers is Really just a toy ASN.1 written by some guys who just solved the problem at hand instead of looking further afar.
It's great for what it is. Many of us have written something similar.
It's not a pro level system designed by a serious telecom team.
I worked on LTE stuff during a research/engineering position. It was just 1 year and not my life's work, but I had to deeply understand ASN.1 for it, and I'd never heard of Google's Protobuf. I didn't like ASN.1 even for its intended use case. That big type system was far more complex than necessary for the protocols I was dealing with (surrounding the EPC mainly).
ASN.1 is more optimized in other ways that make sense, sacrificing some flexibility in favor of performance because the ends are expected to be more coordinated, but that's separate.
