_>>Ну так тогда это просто перестанет быть сопрограммой, банально из определения этого термина. ))) Это будет обычное асинхронное программирование, которое собственно изначально так и возникло. А только потом возникла идея "выпрямления" лапши из коллбэков с помощью сопрограмм в нечто похожее на классическое многопоточное программирование. Т.е. сами по себе сопрограммы — это просто синтаксический сахар для внешней красоты (где образцом являются те самые медленные системные потоки). S>А то.
// Т.е. сами по себе сопрограммы — это просто синтаксический сахар для внешней красоты
при правильном использовании сопрограмм таки есть ненулевая вероятность реализовать на базе corutins lock free ? есть ли вероятность, что реализовывалось частично для этого?
да еще есть вероятность, что co_yeld и yeld вещи то разные. yeld — это просто "системный" вызов функции так и называется yeld, планировщик если увидит свободный поток передаст ему управление, но может и не передавать, но касается вроде как системного потока, а не передачи управления в случае с co_. Но вот со случаем co_ это именно (ну я предполагаю, мне кажется именно так — логично) передача управление другой корутине, но если с локфри, вообще все интереснее.
Здравствуйте, kaa.python, Вы писали:
KP>И пока они там занимаются сексом с корутинами (о них ещё в 2016(2017?) на CppCon от Гора слышал как о прорыве) и никак не изродят ничего годного для промышленного использования
2015 (CppCon 2015: Gor Nishanov “C++ Coroutines — a negative overhead abstraction"). Как сейчас помню, Гор кричал "Negative overhead!" А потом оказалось, что на каждую корутину надо память выделять. Negative overhead my ass.
Здравствуйте, D. Mon, Вы писали:
_>>А в D наоборот, после выхода в релиз развитие замерло. Не были добавлены ни новейшие идеи из C++ (типа семантики перемещения), ни трендовые идеи индустрии (типа сопрограмм). Видимо авторы языка решили что он уже совершенен (как когда-то решили авторы IE6) и надо только его дошлифовывать и развивать инфраструктуру. DM>Файберы были, про move-семантику тоже что-то было. DM>https://dlang.org/library/std/algorithm/mutation/move.html DM>Просто в языке с GC несколько другие акценты и приоритеты.
Угу, язык с GC, в котором всё можно сделать без GC.
DM>Развитие не замерло, оно стало хаотичным. Кучу времени и сил потратили на @nogc, чтобы угодить вечно ворчащим плюсовикам. DM>Потом еще был betterC, где GC даже не линкуется, но бесплатные в рантайме штуки вроде статической интроспекции и шаблонов еще доступны. DM>Потом была эпопея с @live, попытка поиграть в Раст и добавить контроль лайфтаймов. Недоделанная, как обычно. DM>Теперь недавно Уолтер включил чуть ли не целый компилятор Си, чтобы еще легче было импортировать сишные штуки. Опять недоделанное решение, конечно же, без препроцессора. DM>Между ними еще что-то развивали, во все стороны. GC улучшили, например. DM>Какого-то единого видения и направления развития не было и нет, потому "лебедь, рак и щука" — девиз развития Ди.
Согласен. Но всё же думаю что если бы C++ не проснулся (в 2011-ом), то вся эта орда инфраструктурных программистов всё же начала сбегать на D, прогнув его при этом в сторону однозначно системного языка. Ну а так, он в итоге сохранил своё непонятное лицо, при этом потеряв шанс на взлёт...
DM>По мне так если бы язык просто был таким, что был описан в книжке Александреску, ну может с более удобной и регулярной статической интроспекцией и нормальной имплементацией компилятора, он был бы вполне прекрасен. Постоянно его растить и делать монстра типа С++ не надо.
C++ монстр не потому что развивается, а потому что так вышло. ))) Если же развиваться по нормальному, впитывая современные тенденции индустрии, то всё будет нормально. Вот добавление синтаксиса бесстековых сопрограмм никак не ухудшило ни Rust, ни Python. И в D тоже было бы вполне уместно. Это просто как популярный пример естественно, а не как что-то принципиально важное. )))
Здравствуйте, Sinclair, Вы писали:
_>>Обсуждаемая статья — это отголосок известной попытки MS продавить свою реализацию сопрограмм в комитете C++. ))) И автор этой статьи был так сказать главным идеологом всего этого. Кстати, в итоге решение было довольно забавным. Решили принять в стандарт бесстековые сопрограммы (с логичной аргументаций что стекфул хорошо себя чувствуют и без стандарта, в виде библиотек), но не в реализации MS. ))) S>Это интересно. А чем реализация MS так отличалась от того, что попало в 20й стандарт?
Оно кстати ещё в 17-ом было, в виде TS, так что в некоторых компиляторах уже работало (с нужной опцией).
Про реализацию детали уже не помню конечно же. Но в целом изначальная версия от MS была такая совсем простенькая, в стиле .net (ну и кстати помнится там приставки co_ не было, хотя это конечно же не важно). А в итоге в стандарте имеем классического обобщённого монстрика, кастомизируемого в куче точек под все возможные ситуации. )))
_>>Разве что ты там вызовешь внутри какую-то внешнюю функцию, при этом не являющуюся сопрограммой и при этом требующую мегабайт стека. Но это опять же высосанный из пальца сценарий: на практике (а единственное место где вообще актуальна эта тема — это нагруженные сервисы) мы вполне себе представляем как выглядит обычный код таких сопрограмм. S>Почему внешнюю? Нужно тащить весь стек. Смотрите: авторы Go были вынуждены отказаться от сегментированного стека из-за просада производительности. При этом дефолтный размер стека горутины у них был 8 килобайт. S>Это всё ещё примерно в сто раз больше, чем размер замыкания для типичной сопрограммы.
Я про проблемы Go не в курсе. ) Хотя могу предположить, что там специфика заключается в том, что там это основной способ реализации параллелизма. Т.е. оно должно нормально работать во всех случаях. В то время как в том же C++ — это один из многих способов, используемый в специфическом случае (обычно высоконагруженный сервис и т.п.). С весьма характерным профилем кода.
_>>Эм, основная проблема системных потоков как раз не в потребление памяти, а в том что при переключение между ними происходит прыжок в нулевое кольцо. В итоге на переключение может уходить времени больше чем на сами "вычисления". S>Ну а с зёлёными потоками у нас возникает проблема неравномерной загрузки, т.к. не всегда можно заранее предсказать объём работы в процедуре. Перемещать зелёные потоки между потоками ОС не осилил никто, несмотря на многолетние усилия.
Чтобы было сразу понятно. Лично я для задач типа высоконагруженных сервисов использую как раз бесстековые сопрограммы (в реализации Rust'а) с рантаймом tokio. Т.е. я тут не занимаюсь защитой зелёных потоков и т.п. (хотя для стековых сопрограмм на мой взгляд опять же есть своё место под солнцем, про которое я тоже писал). Мои комментарии относились в основном к сомнительной аргументации (расход памяти на самом деле там не будет решать ничего) подобного выбора и сомнительных списков плюсов и минусов (пропущены важнейшие различия, а всякая мелочь подчёркивалась как главное).
Здравствуйте, alex_public, Вы писали:
_>Тебе реально надо объяснять в чём разница когда мы пишем код руками или когда его пишет за нас компилятор?
_>Особенно забавен этот твой вопрос на фоне восторженного упоминания Protobuf, который делает такую же (правда только в один убогий формат) автоматизацию, но сторонними средствами и с помощью отдельного "языка программирования".
Не менее забавно то, что ты пропустил мой вопрос про версионирование. Как эта фича которой ты так восхищаешься решает вопрос с версионированием? Из того что я вижу — никак, а это очень сильно усложняет развёртывание крупной системы.
И да, отдельный язык описания структур идея хорошая, т.к. он тебя отвязывает от какого-то реального языка. То что у вас сейчас всё на Расте вообще ни разу не аргумент, если ты только что-то короткоживущее не пишешь, причем маленькой командой.
_>Protobuf у нас на проде точно никогда не окажется в силу его крайне низкой эффективности (см. например табличку здесь https://blog.logrocket.com/rust-serialization-whats-ready-for-production-today/). Благо сейчас нет никаких проблем писать код со всех сторон (и на сервере и на клиенте, в том числе в браузере) на Rust.
Какого размера у вас R&D? Хотя бы сотня человек есть? Подход который тебя радует не масштабируется
Здравствуйте, uncommon, Вы писали:
U>Здравствуйте, kaa.python, Вы писали:
KP>>И пока они там занимаются сексом с корутинами (о них ещё в 2016(2017?) на CppCon от Гора слышал как о прорыве) и никак не изродят ничего годного для промышленного использования
U>2015 (CppCon 2015: Gor Nishanov “C++ Coroutines — a negative overhead abstraction"). Как сейчас помню, Гор кричал "Negative overhead!" А потом оказалось, что на каждую корутину надо память выделять. Negative overhead my ass.
патамуша так вот думают, первый-же намек глядя на структуру идеи — реализовать неблокирующий малтисрединг в языке.
DM>>Развитие не замерло, оно стало хаотичным. Кучу времени и сил потратили на @nogc, чтобы угодить вечно ворчащим плюсовикам.
тут можно было и не угождать.
_>Согласен. Но всё же думаю что если бы C++ не проснулся (в 2011-ом), то вся эта орда инфраструктурных программистов всё же начала сбегать на D, прогнув его при этом в сторону однозначно системного языка. Ну а так, он в итоге сохранил своё непонятное лицо, при этом потеряв шанс на взлёт...
DM>>По мне так если бы язык просто был таким, что был описан в книжке Александреску, ну может с более удобной и регулярной статической интроспекцией и нормальной имплементацией компилятора, он был бы вполне прекрасен. Постоянно его растить и делать монстра типа С++ не надо.
да хватит этого вот честно утомляет нытье. вы простите, но это вы наехали на моего любимого монстра, будем драться?? Он не монстр, это джаз чувствовать надо ..
_>C++ монстр не потому что развивается, а потому что так вышло. ))) Если же развиваться по нормальному, впитывая современные тенденции индустрии, то всё будет нормально. Вот добавление синтаксиса бесстековых сопрограмм никак не ухудшило ни Rust, ни Python. И в D тоже было бы вполне уместно. Это просто как популярный пример естественно, а не как что-то принципиально важное. )))
так ессно импровизация всегда — "так вышло", а еще на джаз квартирниках есть один принцип — чем-то похож на дедукцию. еще ниразу не пробовали, но вот я их упрошу, и запишем типа клипа.
KP>И да, отдельный язык описания структур идея хорошая, т.к. он тебя отвязывает от какого-то реального языка. То что у вас сейчас всё на Расте вообще ни разу не аргумент, если ты только что-то короткоживущее не пишешь, причем маленькой командой.
не уверен, protobuf в плюсах выглядел ужасно. причем, надо понимать, что постоянно в таких решениях присутствует — генерация кода. в нашем случае С++. и все это как правило обязательно где-то упадет, скривит и еще добавит кучу гемороя, только для того чтобы перебрать поля ?? Вообще все это связано именно с отсутствием рефлекшина, конечно же compile time хотя бы, чтобы как у ди, но вообще ту версию, что я скидывал на базе llvm — там куда интереснее уже — ct reflection.
_>>Protobuf у нас на проде точно никогда не окажется в силу его крайне низкой эффективности (см. например табличку здесь https://blog.logrocket.com/rust-serialization-whats-ready-for-production-today/). Благо сейчас нет никаких проблем писать код со всех сторон (и на сервере и на клиенте, в том числе в браузере) на Rust.
KP>Какого размера у вас R&D? Хотя бы сотня человек есть? Подход который тебя радует не масштабируется
И как 9 мам в один месяц укладываются ?
_>// Т.е. сами по себе сопрограммы — это просто синтаксический сахар для внешней красоты _> при правильном использовании сопрограмм таки есть ненулевая вероятность реализовать на базе corutins lock free ? есть ли вероятность, что реализовывалось частично для этого?
lock free ортогонален сопрограммам. Можно делать lock-free безо всяких сопрограмм, а можно делать сопрограммы, которым нужна блокировка.
Реализовывались они в первую очередь для того, чтобы записывать сложные вещи простым образом.
_>да еще есть вероятность, что co_yeld и yeld вещи то разные. yeld — это просто "системный" вызов функции так и называется yeld, планировщик если увидит свободный поток передаст ему управление, но может и не передавать, но касается вроде как системного потока, а не передачи управления в случае с co_. Но вот со случаем co_ это именно (ну я предполагаю, мне кажется именно так — логично) передача управление другой корутине, но если с локфри, вообще все интереснее.
Смотря где и что. В с++ co_yield — это аналог yield return в C# — возврат значения из генератора. Для асинхронного программирования co_yield и yield return не применяются, вместо них работают await/co_await. Тот же yield(), который из зелёных потоков, семантически отличается от обоих вариантов. Можно с натяжкой считать его аналогом await, который ждёт void-вызов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Про реализацию детали уже не помню конечно же. Но в целом изначальная версия от MS была такая совсем простенькая, в стиле .net (ну и кстати помнится там приставки co_ не было, хотя это конечно же не важно). А в итоге в стандарте имеем классического обобщённого монстрика, кастомизируемого в куче точек под все возможные ситуации. )))
Просто при беглом сравнении того, что попало в стандарт, с .Net, вырисовывается практически 1-в-1 соответствие архитектуры.
Так что непонятно, почему вы считаете, что предложение от МС "отклонили".
_>Я про проблемы Go не в курсе. ) Хотя могу предположить, что там специфика заключается в том, что там это основной способ реализации параллелизма. Т.е. оно должно нормально работать во всех случаях. В то время как в том же C++ — это один из многих способов, используемый в специфическом случае (обычно высоконагруженный сервис и т.п.). С весьма характерным профилем кода.
_>Чтобы было сразу понятно. Лично я для задач типа высоконагруженных сервисов использую как раз бесстековые сопрограммы (в реализации Rust'а) с рантаймом tokio. Т.е. я тут не занимаюсь защитой зелёных потоков и т.п. (хотя для стековых сопрограмм на мой взгляд опять же есть своё место под солнцем, про которое я тоже писал). Мои комментарии относились в основном к сомнительной аргументации (расход памяти на самом деле там не будет решать ничего) подобного выбора и сомнительных списков плюсов и минусов (пропущены важнейшие различия, а всякая мелочь подчёркивалась как главное).
Ну, ок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, serj.e, Вы писали:
SE>Александреску перепутать со Степановым хоть и сложнее, но нет в этом мире ничего невозможного
В два ночи сонному и не такое можно перепутать. Выдыхай, бобёр.
SE>Сам Александреску хвост-те когда уже отошёл от "синдрома имени себя"
Это к счастью излечимо, да.
SE>А вот многие укушенные так и не оклемались, продолжая клепать всё более и более монструозных франкенштейнов, наподобие mpl и hana. Где уже не просто "всё всем параметризуется", а происходит программирование времени компиляции на шаблонах.
Увы.
И?
Здравствуйте, kaa.python, Вы писали:
_>>Тебе реально надо объяснять в чём разница когда мы пишем код руками или когда его пишет за нас компилятор? _>>Особенно забавен этот твой вопрос на фоне восторженного упоминания Protobuf, который делает такую же (правда только в один убогий формат) автоматизацию, но сторонними средствами и с помощью отдельного "языка программирования". KP>Не менее забавно то, что ты пропустил мой вопрос про версионирование. Как эта фича которой ты так восхищаешься решает вопрос с версионированием? Из того что я вижу — никак, а это очень сильно усложняет развёртывание крупной системы.
Естественно никак, потому что версионирование ортогонально вопросу автоматической генерации кода. Потому что оно очевидно не должно зависеть от формата данных (скажем мы ещё те же данные будем в виде json передавать — и где там версионированние будет?).
KP>И да, отдельный язык описания структур идея хорошая, т.к. он тебя отвязывает от какого-то реального языка. То что у вас сейчас всё на Расте вообще ни разу не аргумент, если ты только что-то короткоживущее не пишешь, причем маленькой командой.
Отдельный язык или нет — это на самом деле не очень принципиально. Т.е. конечно же удобнее как в Rust с одним языком только иметь дело, но и с Proto в принципе не сложно. При условии что он позволял бы генерировать код сериализации во все нужные форматы (JSON, MessagePack, XML, и любые другие, подключаемые как отдельные библиотеки). А так, с одним сомнительным форматом — только вредная потеря времени.
Да, и по поводу "привязки к реальному языку". Например если взять в качестве формата MessagePack (https://msgpack.org/ — намного эффективнее Protobuf), то можно легко увидеть, что там есть поддержка более 50 языков программирования. Но если в C++ тебе придётся описывать формат руками в коде (https://github.com/msgpack/msgpack-c/tree/cpp_master), то соответствующая библиотека для Rust умеет работать с Serde и соответственно просто сама берёт все нужные данные из структуры Rust. Теперь надеюсь понимаешь о чём здесь шла речь?
_>>Protobuf у нас на проде точно никогда не окажется в силу его крайне низкой эффективности (см. например табличку здесь https://blog.logrocket.com/rust-serialization-whats-ready-for-production-today/). Благо сейчас нет никаких проблем писать код со всех сторон (и на сервере и на клиенте, в том числе в браузере) на Rust. KP>Какого размера у вас R&D? Хотя бы сотня человек есть? Подход который тебя радует не масштабируется
Т.е. это ты сейчас пытаешься обосновать увеличение трафика сервера в 2-4 раза на пустом месте (от использование Protobuf вместо нормальных форматов) с помощью рассуждений о размере команды? )))
Здравствуйте, alex_public, Вы писали:
_>Естественно никак, потому что версионирование ортогонально вопросу автоматической генерации кода. Потому что оно очевидно не должно зависеть от формата данных (скажем мы ещё те же данные будем в виде json передавать — и где там версионированние будет?).
Вот ничего не понимая в бинарных протоколах, могу сказать за json.
Этот формат позволяет работать как минимум в двух режимах версионирования:
1. Неявная обратная совместимость.
Например, мы обязываем клиента игнорировать все неизвестные атрибуты. Это разрешает серверу добавлять новые атрибуты в респонс до тех пор, пока это не нарушает семантику.
При этом клиент версии 1.1 гарантированно сможет успешно прочитать данные, отправленные сервером версии 1.2.
Аналогичным образом, если мы запрещаем серверу добавлять новые обязательные атрибуты в обрабатываемые им реквесты, то запрос от клиента версии 1.1 гарантированно будет совместим с сервером версии 1.2.
Никогда не будет такого, что кто-то из них прочитает из потока, скажем, номер счёта вместо суммы.
2. Явное версионирование
Мы можем заложить в протокол наличие атрибута { "version" = "..."}, что даёт нам ещё больше гибкости — например, мы можем менять семантику существующих атрибутов. Любой из участников коммуникации может прочесть версию и принять решение о том, как разбирать остальные части сообщения. Например, в версиях 1.х у нас идентификатором пользователя был емейл, а в версиях 2.х по соображениям privacy применяем GUID.
В любом протоколе возникают вопросы:
1. Можем ли мы прочитать "заголовок" сообщения и изменить способ разбора в зависимости от переданной там версии?
2. Можем ли мы добавлять атрибуты в сообщения обратно-совместимым образом, чтобы не знающий о новых атрибутах партнёр мог хотя бы корректно прочитать известные ему старые?
Ну, и, факультативно — можем ли мы менять область значений атрибута обратно-совместимым образом?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Про реализацию детали уже не помню конечно же. Но в целом изначальная версия от MS была такая совсем простенькая, в стиле .net (ну и кстати помнится там приставки co_ не было, хотя это конечно же не важно). А в итоге в стандарте имеем классического обобщённого монстрика, кастомизируемого в куче точек под все возможные ситуации. ))) S>Просто при беглом сравнении того, что попало в стандарт, с .Net, вырисовывается практически 1-в-1 соответствие архитектуры. S>Так что непонятно, почему вы считаете, что предложение от МС "отклонили".
Ты как-то странно прочитал моё сообщение, хотя я вроде ясно всё написал. У MS было по сути уже готовое работающее решение (оно вроде даже в их компиляторе уже было, если я ничего не путаю). В теории его можно было просто взять (в MS были очень "за") и обозвать стандартом, как делали скажем со многими кусками из Boost. Но в комитете решили тут по другому и написали новое решение, "с нуля". При этом среди авторов был опять же Гор, но уже как один из многих...
Что же касается разницы, то она весьма существенная, если залезть во внутренности (и это я совсем не про компилятор). Грубо говоря потому что там всё основано на "шаблонной магии". ))) И да, если во все точки кастомизации поставить дефолтные заглушки, то внешне получится работа весьма похожая на вариант из .net. Только нюанс в том, что в .net это собственно и есть единственный вариант, а тут это всего лишь работа при дефолтной реализации (кстати ещё одно отличие в том, что грубо говоря каждый разработчик обязан создавать "свою реализация" в каждом проекте, хотя понятно что на практике большинство будет копипастить дефолтную).
Начальные детали можешь глянуть здесь https://habr.com/ru/company/yandex/blog/420861/ например. Обрати внимание, сколько "сервисного" кода необходимо добавить в проект, чтобы просто появилась возможность использовать сопрограмму.
Здравствуйте, Sinclair, Вы писали:
_>>Естественно никак, потому что версионирование ортогонально вопросу автоматической генерации кода. Потому что оно очевидно не должно зависеть от формата данных (скажем мы ещё те же данные будем в виде json передавать — и где там версионированние будет?). S>Вот ничего не понимая в бинарных протоколах, могу сказать за json. S>Этот формат позволяет работать как минимум в двух режимах версионирования: S>1. Неявная обратная совместимость. S>... S>2. Явное версионирование S>...
В случае необходимости в версионирование на уровне формата данных (обычно это происходит, когда протокол общения написан не нами) второй вариант кажется заметно лучше, т.к. является не зависимым от самого формата данных (одно и тоже поле version может быть и в JSON и в MessagePac и в XML и где угодно).
Но помимо этого возможно версионирование на уровне протокола (когда при происходит договорённость о версии в момент соединения). Это позволяет получить все плюсы явного версионирования, избежав при этом оверхеда на передачу и проверку версии в каждом сообщение.
Здравствуйте, alex_public, Вы писали:
_>Ты как-то странно прочитал моё сообщение, хотя я вроде ясно всё написал. У MS было по сути уже готовое работающее решение (оно вроде даже в их компиляторе уже было, если я ничего не путаю). В теории его можно было просто взять (в MS были очень "за") и обозвать стандартом, как делали скажем со многими кусками из Boost. Но в комитете решили тут по другому и написали новое решение, "с нуля". При этом среди авторов был опять же Гор, но уже как один из многих...
При этом, что характерно, в обсуждаемом документе про это решение — ни слова.
_>Что же касается разницы, то она весьма существенная, если залезть во внутренности (и это я совсем не про компилятор). Грубо говоря потому что там всё основано на "шаблонной магии". ))) И да, если во все точки кастомизации поставить дефолтные заглушки, то внешне получится работа весьма похожая на вариант из .net. Только нюанс в том, что в .net это собственно и есть единственный вариант, а тут это всего лишь работа при дефолтной реализации (кстати ещё одно отличие в том, что грубо говоря каждый разработчик обязан создавать "свою реализация" в каждом проекте, хотя понятно что на практике большинство будет копипастить дефолтную).
Вы как-то неверно понимаете устройство "варианта из .net".
Там нет никакой "единственности". Когда компилятор встречает метод, помеченный async, он смотрит на атрибут AsyncMethodBuilderAttribute, которым помечен возвращаемый методом тип.
Значение свойства BuilderType определяет, кто будет строить стейт-машину для этого метода.
А при использовании await компилятор, грубо говоря, делает на результате вызванного метода .ContinueWith() со ссылкой на строящийся метод.
То есть опять же — конкретные детали зависят от того, какой код написан автором в ContinueWith().
Просто из коробки в дотнете обработаны пять возвращаемых типов, отсюда кажется, что "есть единственный вариант".
В реальности — гибкости ровно столько же, сколько в С++.
_>Начальные детали можешь глянуть здесь https://habr.com/ru/company/yandex/blog/420861/ например. Обрати внимание, сколько "сервисного" кода необходимо добавить в проект, чтобы просто появилась возможность использовать сопрограмму.
Ну да — те же точки расширения, плюс-минус особенности неуправляемой платформы, вот только реализаций awaitable object в коробку не положили. Бывает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали: _>В случае необходимости в версионирование на уровне формата данных (обычно это происходит, когда протокол общения написан не нами) второй вариант кажется заметно лучше, т.к. является не зависимым от самого формата данных (одно и тоже поле version может быть и в JSON и в MessagePac и в XML и где угодно).
Ну так проблема в некотром роде в том, как определяется порядок полей. Например, XML схема — штука жёсткая, в ней порядок потомков узла строго фиксирован.
Поэтому если мы написали, что тег <version> первым идёт в теге <message>, то так оно и будет — и мы можем на это рассчитывать. И любой способ чтения XML — хоть через DOM, хоть sax, хоть XPath — корректно вынут версию из документа, в который сложили дополнительный контент.
А в расте как-то гарантируется порядок обхода полей структуры?
Не получится случайно так, что в версии 2 на том месте, где были байты поля "версия", оказались байты поля "длина текста", а версия уехала в хвост?
Ведь тогда читатель, полагающийся на фиксированное расположение байтов, прочтёт мусор.
_>Но помимо этого возможно версионирование на уровне протокола (когда при происходит договорённость о версии в момент соединения). Это позволяет получить все плюсы явного версионирования, избежав при этом оверхеда на передачу и проверку версии в каждом сообщение.
Для этого должно быть версионирование на уровне протокола.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
