Надо же как-то оправдать инвестированное на задротство время, когда результаты на широком рынке не востребованы. А вообще думаю была бы крутой связка именно go + rust. Первый для написания приложений без страданий. Второй уже для всяких серьезных библиотекек и критичным к производительности и стабильности приложений. А может и нет. Рыночек порешает. Главное, чтобы не пришлось на кириллическом языке в чебурнете работать

Объяснение куда проще. Большинству "хаскелистов" приходится работать не с хаскелем. И при этом испытывать болезненные ощущения от того, что он мог бы эту задачу решить легко и просто, но придется городить костыли, потому что у нас тут язык НЕ АКАДЕМИЧЕСКИЙ, А СУГУБО ПРАКТИЧНЫЙ, ага.

взять тот же С и "корректную" работу с сетью, со всеми обработками

А, вот у вас какой критерий. Ну тогда, по этому критерию хаскель совсем не академичный. По крайней мере в Российских реалиях. Ибо тут ФП если и преподают, то совсем чуть-чуть и на последнем курсе.

Перл, кстати, брал фичи функциональщины. Отчасти поэтому можно писать очень компактно

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

задрали рустеры и хаскелисты. особенно задрали тем что путают слова "сложный" и "не нужный"

А годы идут... БМВ не покупается...

БМВ как швейцарские часы - или работают или убитый таз

Или никому не нужно)

Надо же как-то оправдать инвестированное на задротство время, когда результаты на широком рынке не востребованы. А вообще думаю была бы крутой связка именно go + rust. Первый для написания приложений без страданий. Второй уже для всяких серьезных библиотекек и критичным к производительности и стабильности приложений. А может и нет. Рыночек порешает. Главное, чтобы не пришлось на кириллическом языке в чебурнете работать

задрали рустеры и хаскелисты. особенно задрали тем что путают слова "сложный" и "не нужный"

задрали гоферы. особенно тем, что считают всё, что сложнее школьной программы за 9-й класс ненужным.

лол, чувак я вообще джявист. но не хожу в ваши смешные чатики и не пропогандирую, что на ваших ненужных языках даже простого AbstractProxySingletonBeanPostProcessor'а не напишешь. и даже ни одного bpm-движка не написано

так займитесь делом и напишите нормальный proposal, чего вам не хватает, как тут уже сделали

Пыху не хватает строгой типизации

конечно если обьявите вначале функции .. а внутри цикла он будет постоянно алоцировать и деалоцировать

в то что го однажды станет более менее юзабельным языком я не верю

А зачем вы тогда его выбрали? Писали бы на чем-нибудь другом, языков много.

А зачем вы тогда его выбрали? Писали бы на чем-нибудь другом, языков много.

Пока не попробуешь — не сформируешь своё мнение, полагаю.

Ну отгрузили можно сформировать вполне полноценное мнение через неделю пользования.

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

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

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

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

Ну и указываете в заголовке или отделанным параметром тип сообщения и размер. Тот же 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