> even google themselves don't use it in many of their software Citation needed. Granted its a big company, so its certainly possible that some teams I'm unaw

> even google themselves don't use it in many of their software Citation needed. Granted its a big company, so its certainly possible that some teams I'm unaware of were using it. But I never ran into one. Besides, nanopb doesn't answer the critique of the article. Nanopb cuts down on heap traffic by statically allocating flat buffers large enough to hold maximums set by the application. It solves the two-pass problem by the simple expediency of actually running two passes, storing the size info on the ordinary call stack. In effect, it trades malloc/free traffic for higher peak memory utilization. At the largest scales, big G suffers from total memory pressure more than it suffers from lack of arithmetic. Nanopb isn't a good trade for them. It is a good trade for my current (hard realtime, embedded) application.