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

типа reference to const и const reference? это да. Но если так не делать то можно получить ограничения на которые потом будут плеваться

у нас тут или хейтеры go, или хейтеры иммутабельности :)

Кстати, я вот всегда замечал что последователи ФП яростно дрочатъ на иммутабильность, неизменность данных (из-за этого не юзают циклы, предпочитая рекурсию и пр.). Но почему в проде всякие Хаскели и Кложуры абсолютно не популярны?

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

Ну Kubernetes живет как-то. И Prometheus. Думаю можешь призвать людей оттуда и узнать их мнения.

Кстати, я вот всегда замечал что последователи ФП яростно дрочатъ на иммутабильность, неизменность данных (из-за этого не юзают циклы, предпочитая рекурсию и пр.). Но почему в проде всякие Хаскели и Кложуры абсолютно не популярны?

ключевое слово "как-то"))

ключевое слово "как-то"))

Собери статистику по багам — сколько багов в этих проектов было из тех, что твой пропозал фиксит.

ключевое слово "как-то"))

вручную их анализировать, что ли?!

Просто ты давишь за что-то абстрактное. Но у тебя есть большие открытые проекты и куча багов и PR. Покажи примеры.

Парни, а как вы организовываете свой код? Придерживаетесь ли вы правил дядюшки боба (про 4 layer), или же вы все разделяете? К примеру go way, это иметь в домене entity и интефейсы сервсиов, репозиториев. А дробить пакеты под enity, интерфейсами для репозиториев, сервисов и хэндлеров считается вроде как не кошерно.

Вы мне за это заплатите?)) Мне сейчас никто за этот пропосал не платит, я можно сказать дарю комьюнити своё время ради общего блага. Ты не поверишь сколько нервов и времени у меня уже ушло на данный документ а ещё предстоит сравнивать его с другими предложениями. Я вам просто скажу, что вид homo sapiens сделало доминирующим 2 способности: 1. способность абстрактного мышления 2. способность принимать гипотезы всерьёз если вы считаете, что описанные сценарии не могут быть опасными, тогда я вам ничем помочь не могу.

Топовый НЛП.

Вы мне за это заплатите?)) Мне сейчас никто за этот пропосал не платит, я можно сказать дарю комьюнити своё время ради общего блага. Ты не поверишь сколько нервов и времени у меня уже ушло на данный документ а ещё предстоит сравнивать его с другими предложениями. Я вам просто скажу, что вид homo sapiens сделало доминирующим 2 способности: 1. способность абстрактного мышления 2. способность принимать гипотезы всерьёз если вы считаете, что описанные сценарии не могут быть опасными, тогда я вам ничем помочь не могу.

@selslack Павел, вы не поняли сути моих слов. Суть проста: я человек. У меня 14 часов в день максимум. Я просто не успеваю. Детальный анализ проблем таких проектов обойдётся недёшево. Если же это был намёк мне помочь подкрепить документ аргументами из больших проектов на Go - с радостью! Очень буду рад!

кстати, если не секрет, скажите, как вы пришли к этому proposal: изучали решение этой проблемы в разных языках, или исходя из изучения исходников проектов >5 LOC ? или оба варианта? или другой вариант?

многолетний опыт подсказывает, как бы субъективно это не звучало. Вся аргументация с приближенными к реальности примерами описаны в документе и были расжованы мною в чате уже неоднократно. Если вам нужны конкретные примеры из конкретных проектов как доказательство гипотезы - я вам не могу помочь, у меня недостаточно времени анализировать проекты и их баги (Если я найду желание и время это сделать, то я постараюсь конечно, но я лишь человек).

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

@selslack Павел, вы не поняли сути моих слов. Суть проста: я человек. У меня 14 часов в день максимум. Я просто не успеваю. Детальный анализ проблем таких проектов обойдётся недёшево. Если же это был намёк мне помочь подкрепить документ аргументами из больших проектов на Go - с радостью! Очень буду рад!

Ну вот го это не про концепции это про реалии, если концепция верная но в реальности не встречается значит не нужно

Вот что они в Го 2 с легаси будут делать?!

Go это не про "банальную простоту синтаксиса". Go это про устранение легаси, иной подход к конкуррентности и устранение неправильных концепций таких как наследование имплементации и прочих, которые показали себя нехорошо в прошлом. mutable shared state встречается в реальности в абсолютно каждом вашем проекте! Будь то 1к LOC или 2kk LOC. Slice aliasing это mutable shared state, и вы с ним бессомненно часто встречаетесь, вы просто привыкли с ним жить и копировать слайсы (slow + boilerplate). Pointer aliasing это mutable shared state и встречается он не реже.

Ну так о том и речь, что если на практике проблемы уже нет, то вносить в язык чужеродную конструкцию никто не будет И го это про простоту и в го исходят не из "как-бы нам ещё чего добавить" а из "как бы так ничего больше не добавлять"

Ну вот пока никто не привёл примеров из реальной жизни, типа за последний месяц три бага словил которых не было бы если бы был const

пожалуйста: https://github.com/romshark/Go-2-Proposal---Immutability#39-doesnt-the-const-qualifier-add-boilerplate-and-make-code-harder-to-read

Там теореьизирование и всасывание из пальца

ну что-ж, тогда я желаю вам удачи в мире IT, коллега. С такой моделью мышления вам успех гарантирован 🙂 а я пожалуй пойду пить чай, устал таки

ну что-ж, тогда я желаю вам удачи в мире IT, коллега. С такой моделью мышления вам успех гарантирован 🙂 а я пожалуй пойду пить чай, устал таки

Роман, я без троллинга предлагаю вам пойти в го_тим в Гугл.

увы, у меня другие жизненные приоритеты на данный момент, хотя всё возможно.

пожалуйста: https://github.com/romshark/Go-2-Proposal---Immutability#39-doesnt-the-const-qualifier-add-boilerplate-and-make-code-harder-to-read

а что со стандартной библиотекой? это же половину всего переписывать чтобы было идиоматично иммутабельным структурам.

а что со стандартной библиотекой? это же половину всего переписывать чтобы было идиоматично иммутабельным структурам.

если же вы конкретно про "idiomatic completeness" тогда можно некоторые моменты переписать, но не обязательно.

да, я про то чтобы все было идиоматично. потому что пока у меня не будет в экосистеме иммутабельного http клиента и всего остального будет очень сложно

я не думаю что это супер сложно. Потому-что иммутабельность наоборот убирает многие ненужные строки кода и порой её можно вставить в стиле "plug'n'play". Это не генерики, где нужно серьёзно код перелопачивать

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

тут не любят предложений добавить "лишних" фич

давайте без утвержденией "лишнее")) я так не смогу спокойно чай пить))))

так или иначе это шаг в правильное направление. Хуже иммутабельности только её отсутствие