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

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

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

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

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

ты меня неправильно понял, я бы тоже хотел иммутабельность по умолчанию и какой-нить 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. Пусть разработчик определяет, что это менять не стоит, если действительно не надо

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

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

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

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

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

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

Лучше, наверное, все же модификатор 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 же

смотри

у нас все передается по значению

и у всего есть тип

не все по значению