А зачем вам тогда нужен протобуф? Хотя конечно и на нем можно, но в принципе как и описали.

Мне нужно строгое описание протокола, но в то же время нужна возможность отправлять разные типы пакетов (структур)

Ну и указываете в заголовке или отделанным параметром тип сообщения и размер. Тот же gob примерно так работает.

так чтобы этот отдельный параметр прочитать - нужно сначала анмаршалить, а во что - заранее неизвестно

похоже, мне надо курить тип Any

О, шедевр — Влияет ли на управление сложностью то, что в программировании сейчас довольно много людей со слабой технической базой? Конечно. Для таких людей даже специальный язык программирования придумали. Называется Go. Я не шучу. Действительно, целью создания языка Go была попытка вовлечения в написание кода студентов и стажеров Google, которые не могут освоить C++. Python им не подходил по производительности, нужно было что-то иное, и в Google придумали Go. Как оказалось, очень много людей готовы на нем писать, потому что он очень простой. Но какой ценой достигнута эта простота? Нам дают не нормальный язык программирования, а его очень урезанную версию — в нем нет практически никаких сложных концептов by design. Нет дженериков, нет такого понятия, как исключения и т.д. И поклонников такого подхода много. Отсюда https://habr.com/company/oleg-bunin/blog/424393/

Товарищи, а есть ли какие-нибудь общепринятые практики для того, чтобы при использовании protobuf делать примерно так (пример из ip-протоколов): - получил пакет - прочитал из него хидер (заранее известные N байт) - по хидеру определил тип пакета - спарсил пакет в структуру в зависимости от типа ? На данный момент всё, что я нашел, из well-known применений — тупо proto.Unmarshall в определенный тип структуры. Это может быть и удобно для чего-то rest-подобного, когда ты точно знаешь, какой ответ должен быть при обращении на некий URL. Сто урлов - сто типов ответов. Но мне нужно использовать что-то вроде, например, nats-streaming или NSQ: а создавать по каналу для каждого из возможных типов пакетов - как-то бредово

Товарищи, а есть ли какие-нибудь общепринятые практики для того, чтобы при использовании protobuf делать примерно так (пример из ip-протоколов): - получил пакет - прочитал из него хидер (заранее известные N байт) - по хидеру определил тип пакета - спарсил пакет в структуру в зависимости от типа ? На данный момент всё, что я нашел, из well-known применений — тупо proto.Unmarshall в определенный тип структуры. Это может быть и удобно для чего-то rest-подобного, когда ты точно знаешь, какой ответ должен быть при обращении на некий URL. Сто урлов - сто типов ответов. Но мне нужно использовать что-то вроде, например, nats-streaming или NSQ: а создавать по каналу для каждого из возможных типов пакетов - как-то бредово

Так и есть, и я не понимаю почему это воспринимается как троллинг. Большая часть плюсов Go связана с его тщательно продуманной простотой

Во первых я не выбирал. Во вторых, когда я начинал писать на го, всяких рустов с хаскелями я ещё не знал.

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

Удивляет нытье людей утверждающих, что вокруг все просто неучи и при этом сами они даже не выбирают стек технологий, какой то инфантилизм

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

Да, на го можно говнокодить, но простота заключается в том, что весьма сложные концепции спрятаны за простыми в использовании подходами

Во-первых, посмотри в сторону grpc https://grpc.io/docs/tutorials/basic/go.html

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

Не совсем то: мне нужно стримить всякие изменения, т.е. не p2p, а p2mp

Возьми тогда какую нибудь очередь с топиком

Уже взял Но я не хочу на каждый тип пакета плодить топик, в этом и суть)

Уже взял Но я не хочу на каждый тип пакета плодить топик, в этом и суть)

А почему нет?

Thrift можешь взять и пихать все в один

Пошел гуглить)

Ну в общем-то отчасти как раз из-за того, что Go простой и позволяет писать более менее надёжный код даже говнокодерам, он так прёт в популярности. Ну, помимо всяких плюшек рантайма, простоты поддержки и пиара от гугла. И в этом нет ничего плохого — раньше говнокодеры шлёпали CRUD на ноде и пыхе, сейчас начинают шлёпать более надёжные на Go. А тесты как они не писали, так и не пишут. А те программисты, которые Программисты, почти всегда найдут себе интересную и оплачиваемую работу хоть на Go, хоть на Rust, хоть на Scala, хоть на Java

Да, только говнокодеры могут говнокодить на го потому что тимлиды оценили преимущества го, но не наоборот И да, простота, пиар и прочее это несомненно сыграло роль Только го не задумывался как язык для тех кто не может освоить с++ а как язык на котором могут начать писать вчерашние студенты не тратя годы на освоение сложного инструмента

Пошел гуглить)

Но я не уверен что там так можно, можно на протобафе сделать говно структуру конечно

Пока что мне пришло в голову - делать "родительскую" структуру-обертку, объявлять в ней тип пакета, и поле с типом Any - в которое уже писать "основной" пакет 1) читать тип 2) после считывания типа - приводить Any к нужному типу

Пока что мне пришло в голову - делать "родительскую" структуру-обертку, объявлять в ней тип пакета, и поле с типом Any - в которое уже писать "основной" пакет 1) читать тип 2) после считывания типа - приводить Any к нужному типу

> а как язык на котором могут начать писать вчерашние студенты не тратя годы на освоение сложного инструмента так и есть. Как и пых, 1C и прочие узконишевые языки. Я не понимаю с чего тут бомбить

Вообще можно и в протобафе эт сделать, просто нужно определить тип ивента и массив байтов после, и потом по типу делать десериализацию

Какой смысл повторять запрос с синтаксической ошибкой например?

Транзакция к конекшену привязана

Господь мой. На js

у них какой-то неправильный solid

у них какой-то неправильный solid

Solid's basic protocol is REST сразу такая грусть разбирает :( чёртовы маркетологи)