Дело не в валидирующем механизме а в большой горе ограничений схем. Схемлес базы тоже не просто так родились. Но гораздо более серьезная проблема что протокольные типы становятся доступны внутри сервисов и становятся частью не только транспорта но и бизнес логики. Это такие гвозди которые прибивают все на мертво

ага, это понимаю и знаю о чем ты

Зачем заставлять человека делать работу компьютера и выность метаинформацию из системы?

сорян, что влезаю. может что и не в тему, тк не все прочел. по поводу протоколов, мне уже в двух книжках попалось упоминание протокола Apache Avro, как протокола, который позволяет жить с частичным обновлением системы. если какие-то структуры меняются, то у них идет добавление полей в конце, таким образом, что старая часть со старой структурой сможет прочитать поля, которые были в старой версии. вроде бы и в protobuff при определенных условиях произойдет что-то около того.

Это скорее ты про техническое обеспечение паттерна, который должен быть в голове у проектировщика: как обспечить обратную совместимость

ну, со схемой или без - у каждого варианта свои плюсы/минусы

Строгая последовательность полей неважна да и вредна при наличии схемы. Это детали реализации. Или ты про схему?

в capnproto тоже к полям в явном виде добавляются метки порядка, которые нужны для обеспечения обратной совместимости

В авро есть принципиальный момент, там отдельно есть схема писателя и читателя.

От куда такое?

Еще вопрос - в догонку прл бинари

Разве в разных версиях эрланга не резные бимы получаются?

Как тогда можно скомпилировать заранее что-то?

Да, бимы разные.

Ну может будут перегонять не в BEAM, а в какой-нить GraalVM/LLVM-based байткод. :)

Байткод меняется относительно редко емнип

Компилишь под окружение. Оно так с любыми бинарями

там не версия эрланга важна а версия libc если мне память не изменяет

Можно погуглить на эту тему, вроде в рамках мажорного релиза гарантирована совместимость

Но точно я уже не помню