mental cost увеличивается, когда вы не понимаете, почему у вас где-то мутирует слайс. а когда у вас есть гарантии и компилятор не позволит никому творить безобразие а в документации обещать что "я этого не делаю" - работать в Open Source комьюнити и команде, да даже одному над большим проектом - становится легче

чет тут не понятного? есть слайс - можно мутировать. Есть объект с доступом по индексу, внутри которог ослайс - нельзя мутировать. Нахер ещё что-то изобретать? чтобы запутать джунов и усложнить коде ревью?

чет тут не понятного? есть слайс - можно мутировать. Есть объект с доступом по индексу, внутри которог ослайс - нельзя мутировать. Нахер ещё что-то изобретать? чтобы запутать джунов и усложнить коде ревью?

лень тебе сделать из слайса нормальный объект - твои же проблемы, а не языка

чет тут не понятного? есть слайс - можно мутировать. Есть объект с доступом по индексу, внутри которог ослайс - нельзя мутировать. Нахер ещё что-то изобретать? чтобы запутать джунов и усложнить коде ревью?

знаете почему вы городите wrapper объекты, ради того чтоб слайс защищать? потому-что нет immutability ? вы можете добиться гарантии иммутабельности только враппером. Короче думайте сами, коллега, как вам удобнее, но я с вами не согласен, я скорее единомышленников ищу ?

знаете почему вы городите wrapper объекты, ради того чтоб слайс защищать? потому-что нет immutability ? вы можете добиться гарантии иммутабельности только враппером. Короче думайте сами, коллега, как вам удобнее, но я с вами не согласен, я скорее единомышленников ищу ?

враперы я горожу не то чтобы сильно часто, бойлеплейта на это минимум. какроче вообще не напрягает. Так я же объясняю вашим потенц. единомышленникам что вы не правы :)

чет тут не понятного? есть слайс - можно мутировать. Есть объект с доступом по индексу, внутри которог ослайс - нельзя мутировать. Нахер ещё что-то изобретать? чтобы запутать джунов и усложнить коде ревью?

враппер уменьшает mettal cost, ага... это реально стокгольмский синдром :(

враппер уменьшает mettal cost, ага... это реально стокгольмский синдром :(

и вот как им ещё объяснить?))

никак

никак

да вот и я о чём

Я чего-то не понял, или все считают, что добавления модификатор const при объявлении переменных или параметров функций как-то поломает совместимость?

Я чего-то не понял, или все считают, что добавления модификатор const при объявлении переменных или параметров функций как-то поломает совместимость?

каким это образом?

вот я и не понял. Чем плохо сказать лишний раз const, если надо?

Оно же для компилятора, по сути, чтобы он ругался, если что

Оно же для компилятора, по сути, чтобы он ругался, если что

совершенно верно, компилятор должен думать за нас как можно больше, а мы должны описывать API'шки как можно более точно это устраняет ошибки, экономит дебагинг неявных ошибок и по очень мало стоит с точки зрения написания кода (это-ж вам не врапперы городить!) плюс ещё и небольшой прирост производительности

не, я, наверное, невнимательно что-то не понял тогда

Я бы модификатор const хотел!

а я, повторюсь, хотел бы мотификатор mutable :)

потому, что это будет меня сразу настораживать

а я, повторюсь, хотел бы мотификатор mutable :)

но тогда-же ломается совместимость ?

А оно и так разве, не все изменяемое по умолчанию?

А оно и так разве, не все изменяемое по умолчанию?

всё кроме строк

я бы хотел других умолчаний

угу

но тогда-же ломается совместимость ?

а я на нее не дрочу...

я бы хотел других умолчаний

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

я бы хотел других умолчаний

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

Нельзя вот так взять и сделать все окружающее immutable

а я, повторюсь, хотел бы мотификатор mutable :)

Эт чё, типо всё - конст, хочешь менять: пиши mutable? O_o

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

предполагаю что, если начинать с начала, тогда "Go 2.0" лучше переименовать в "Stay 1.0" ?

видишь, иммутабельность по умолчанию может быть полезна 1. оптимизатору 2. параллелизатору (пока нет такого, но можно бы и сделать) 3. сборщику мусора (эту мысль я до конца не додумал)

Эт чё, типо всё - конст, хочешь менять: пиши mutable? O_o

да, это гораздо безопаснее с точки зрения оформления API

Эт чё, типо всё - конст, хочешь менять: пиши mutable? O_o

да. шаг к чистым функциям

видишь, иммутабельность по умолчанию может быть полезна 1. оптимизатору 2. параллелизатору (пока нет такого, но можно бы и сделать) 3. сборщику мусора (эту мысль я до конца не додумал)

совсем не спорю, на 105% согласен но таки боюсь я разделения экосистемы на Go 1.x и Go 2.x, ну вот прям боюсь..

видишь, иммутабельность по умолчанию может быть полезна 1. оптимизатору 2. параллелизатору (пока нет такого, но можно бы и сделать) 3. сборщику мусора (эту мысль я до конца не додумал)

хотя... может, ты и прав, но звучит это как-то угрожающе

хотя... может, ты и прав, но звучит это как-то угрожающе

так всегда с чем-то "новым"

совсем не спорю, на 105% согласен но таки боюсь я разделения экосистемы на Go 1.x и Go 2.x, ну вот прям боюсь..

Привет питон 2 и питон 3

помню как я в начале аллергично реагировал на "Capital letter for public fields and functions"

Ну, разделение - это вобще катастрофа! Уже столько хороших вещей (библиотек) на Go 1 написано... И что тогда делать?

Привет питон 2 и питон 3

и я о чём

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

у нас не так же

Ну, разделение - это вобще катастрофа! Уже столько хороших вещей (библиотек) на Go 1 написано... И что тогда делать?

вот и я о чём

Ну, разделение - это вобще катастрофа! Уже столько хороших вещей (библиотек) на Go 1 написано... И что тогда делать?

вводить расширение go2, и компилять одно одним, другое другим

вводить расширение go2, и компилять одно одним, другое другим

Не надо вот этого вот

да почему же

Это уже новый язык получается

так да

Легче так и сделать

ну, и одним работать на Go1, а другим - на 2. И вместе им не сойтись (c)

смотрите

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

и уж точно можно сделать go2 так, чтобы go в него конвертился автоматически

видишь, иммутабельность по умолчанию может быть полезна 1. оптимизатору 2. параллелизатору (пока нет такого, но можно бы и сделать) 3. сборщику мусора (эту мысль я до конца не додумал)

думаешь стоит добавить раздел "Alternative Immutability Concepts"? пусть народ и разрабы решают?

:)

вообще - да

и уж точно можно сделать go2 так, чтобы go в него конвертился автоматически

но еще недостаточно, чтобы аккуратно конвертировать mutable в его противоположность

это да

вызовам с go придется mutable прописывать

или конвертить, пробовать компилять, репортить проблему

видишь, иммутабельность по умолчанию может быть полезна 1. оптимизатору 2. параллелизатору (пока нет такого, но можно бы и сделать) 3. сборщику мусора (эту мысль я до конца не додумал)

поможешь написать более технические аспекты относительно опцимизации засчёт имут. по умолч. ? Я думаю не сильно шарю в этом буду очень благодарен

завтра попробую

завтра попробую

??

если опять прокрастинация нападет :)

Лучше, наверное, все же модификатор const. Пусть разработчик определяет, что это менять не стоит, если действительно не надо

если опять прокрастинация нападет :)

ничего, я буду пинговать))

ничего, я буду пинговать))

Не надо его пинговать. Возьми бота, который он же и писал, и им и пингуй :)

если опять прокрастинация нападет :)

Если я ничего не путаю, это ведь у тебя был доклад об насчет пинга коллег?

ERROR: S client not available

Лучше, наверное, все же модификатор const. Пусть разработчик определяет, что это менять не стоит, если действительно не надо

@onokonem А вообще можно даже реализовать пока-что const для иммут в Go => 1.12, а потом уже в Go 2 сделать её по умолчанию я думаю так даже лучше будет! считай старый код не сломаем, но иммутабельность добавим. а в го 2 сделаем ещё лучше - да и конвертировать код Go => 1.12 в таком случае будет гораздо легче ибо и там и там иммут. имеется

А! То есть все, что было до 1.12 - до свидания?

Эээ ребят это походит на восстание и революцию

Почему нельзя просто const добавить и нормас? Я тоже с плюсов, там вроде конста хватало

И вся эта игра с большими и маленькими буквами... Нет.. что-то не так с глобальным immutable, чую я

Кажется, фильме Матрица один паацан так поступил. Эльфы в костюмах просто даже застыли на месте и не знают что делать...

Почему нельзя просто const добавить и нормас? Я тоже с плюсов, там вроде конста хватало

+1

А! То есть все, что было до 1.12 - до свидания?

всмсл?

Почему нельзя просто const добавить и нормас? Я тоже с плюсов, там вроде конста хватало

можно. но примерно 99% вызовов должны будут иметь этот const приписаным к каждому из параметров.

Даниэль, а если просто посчитать, какое солов чаще придется писать const, или mutable?

А чем вам вариант с модификатором блока кода mut/const не нравится?

да. 99%, и люди с этим живут уже хрен знает сколько

у нас нет манеры возвращать значения модификацией входных параметров. исключая анмаршалеры - так никто не делает на постоянной основе. а, еще ридеры. так что const придется писать существенно чаще

Все что внутри блока имеет mut или const префикс

А чем вам вариант с модификатором блока кода mut/const не нравится?

код неизменяем в Go. Речь о переменных

код неизменяем в Go. Речь о переменных

Нет, вы не поняли

а, понял

А чем вам вариант с модификатором блока кода mut/const не нравится?

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

Идея в маркере, который тупо префиксует все внутри блока как mut или const

Только на момент передачи параметров - вряд ли получится

Если не сказано явно иное перед переменной

только, может быть, и не надо

Это компромисс между "хочу все immut" и текущим вариантом

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

Чтобы программист мог выбирать стратегию в рамках пакета, файла или блока кода

другое дело, что const делается одним флажком в составе struct, slice, map а mutable надо будет тащить и проверять на каждом вызове

так что, наверное, все же const

и линтер, который предупреждает, что вы const не проставили :)

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

так что насчёт внедрить immutability уже в Go 1.x с const а в Go 2.x внедрить mut по умолчанию на всё? плюс написать транспилятор который писать будет легче если в Go 1.x уже есть поддержка имутабельности?

вот так, наверное, это имеет хоть какие-то шансы

и линтер, который предупреждает, что вы const не проставили :)

и с флажком -no-warn-constantly

другое дело, что const делается одним флажком в составе struct, slice, map а mutable надо будет тащить и проверять на каждом вызове

А где там флаг? И все это compile time же