Comments 21
Что-то не нашел для Gob библиотеки для js
Cap'n proto не рассматривали? Вроде бы от одного из авторов Protobuf. Как работа над ошибками. Позиционируется как самый быстрый сериализатор.
Быстрее flatbuffers от того же гугла?
Внутри команды рассматривали flatbuffers. Он действительно самый быстрый, как пишет ErgoZru, но и достаточно сыроват/нестабилен для комбинации flatbuffers + gRPC. Поэтому пока следим за развитием.
Очень странное сравнение... Сравнивать protobuf, который является IDL, то есть просто описанием структур и методов, и конкретные сериализаторы... Эта статья выглядит по сути как сравнение инструкции (protobuf) по которой собирают машину и гаечных ключей, которыми собирают ту же машину. Короче теплое с мягким. Ну и никто не мешает написать ген-плагин к протобафу для перегонки прото файлов в те же MsgPack методы и структуры. Да можно даже готовые взять, тот же генератор документации и подсунуть нужный шаблон, или gotemplate генератор, и подсунуть полноценный шаблон и генерировать вообще что хочешь. Да и gob прикрутить при желании можно. Ч не говорю о совместимости с протобафом в котором есть своя реализация, но дополнить ее никто не мешает.
Всё верно, сравнение не совсем "нормально" с математической точки зрения. Но мы живём не в идеальном мире: любые решения будут иметь свои наборы свойств и особенностей, которые нельзя будет привести к общему знаменателю.
Статья разбирает решения не только с технической точки зрения, но и со стороны эксплуатации/разработки ("административная" стороны медали).
Можно и реализовать своё решение со схемами, дебагом и сусликами, которое будет соответствовать всем требованиям. Но такое решение будет технико-экономически неконкурентоспособно, так как на него нужно ещё до начала эксплуатации затратит много человекочасов и не факт, что результат будет лучше.
Это скорее сравнение разных подходов, с одной стороны Protobuf с подходом к кросплатформенности и кодогенерацией со стороны документации к коду. И messagepack c gob, как вариант для ситуаций когда мы движемся от кода к документации. Так же хорошо прослеживается что автор намекает на то что все 3 варианта могли бы быть популярны при наличии заинтересованной компании в виде пиара и разработчиков.
Еще один аргумент в пользу protobuf - его знает большинство разработчиков и не будет тратиться время на обучение вновь пришедших в команду.
Жду вторую часть с конкретными цифрами, ибо при выборе решения важно опираться на такие показатели, как размер сообщения, нагрузка на проц при кодировке/раскодировке и потребление памяти при этом.
Это второе решение после JSON, которое не требует отдельного изучения для вновь пришедших в команду. Это серьёзное преимущество для коммерческой разработки.
Вторая часть уже почти готова. Не стал делать long-long-story. Тем более теперь появились новые мысли, что нужно бы добавить/доправить, чтобы цифры были интереснее.
Вы тут пишите в комментариях про технико-экономическое обоснование (про конкурентность решений). Экономическое - вижу, хотя и без ваших человекочасов. А где технические цифры? Можно же сравнить их по производительности, компактности, сколько ресурсов жрут, что там аллокациями. Было бы вообще неплохо сравнить с JSON (мне кажется, его куда чаще используют).
Занудство мод on: пакет json от goccy все ещё работает быстрее существующих реализаций msgpack и gob на кодировании и декодировании, с protobuf не сравнивал. Так что если сетевые издержки не являются узким местом - звучит будто их использование - пустая трата времени в текущих реалиях.
Всё верно, до момента, когда размер передаваемых данных увеличивается критично (постараюсь в сл части показать этот момент, если получится реализовать это в программном стенде). Если обмениваться маленькими JSON структурами, то статью можно не читать. Если структуры увеличиваются, то скорость JSON сериализации/десериализации падает ощутимо.
Весьма кстати статья. Как раз искал готовое решение для UNIX RPC сокетов, для обмена между двумя процессами и Gob пока подходит.
Жаль что статью заминусовали.
Если нужно нативное решение, то можно использовать https://pkg.go.dev/encoding/gob https://pkg.go.dev/net/rpc Для своих pet проектов отлично работает.
у меня есть небольшой покет, которая может пригодиться для p2p коммуникации TCP+Gob https://github.com/leprosus/golang-p2p (imho лучше, чем нативный RPC)
Зоопарк в Golang MSA. Protobuf, MessagePack, Gob – что выбрать?