прикол в том что к данным в таком формате упакованным мы получаем доступ сразу же к любому полю объекта, на любом почти языке, без аллокации памяти, без парсинга в рантайме

и ничего не надо перепаковывать - все работают с одним и тем же блоком данных

Да но это убцовое взаимодействие в терминах си++

А смысл протобуфов как раз в упаковке и сжатии

смысл протобуфов в том чтобы индусы могли меньше наговнокодить

ценой приемлемых во многих случаях издержек

и дальше - grpc

там ресурсы уже дело десятое

а flatbuffers - ресурсы в приоритете(у меня например на микроконтроллерах используется и во фронтендах), я могу например с одним и тем же объектом в памяти работать как из плюсового кода на микроконтроллере, так и из JS кода, который исполняется интерпретатором, запущенным на этом же микроконтроллере, при этом ресурсов мало - нет возможности даже просто скопировать и передать этот объект в JS интерпретатор - слишком долго и слишком много памяти для жесткого реалтайма, при этом объекты формируются вообще на веб сервисе из конструктора в браузере

ценой того что - да, риск выстрелить в ногу большой

но меньше чем используя raw структуры и собственные обертки

Теперь понятно что ты так их форсишь, но это точно не универсальное решение, оно работает только до тех пор пока твоя производительность сильно меньше производительности сети

Типа для передачи по сети ты так или иначе должен сжимать, может быть ты отдал это гзипалке nginxа какого -нибудь но до него нужно тоже доставить еще

понятно что мне удовольствия не доставляет большого паровозики из стрелочек эти строить

и я при возможности просто grpc подниму и все

если речь про сервачок какой нить на C++/JS/Python и тд

у которого гигабайты оперативки и десятки милисекунд задержки это приемлимо

Вот как раз миллисекунды зажержки сжатие и уменьшает

Ценой загрузки цпу

тут вопрос от конечных потребителей данных должен ставиться