Guys, need your opinion on that: Should non-const types be automatically (implicitly) converted to const types? This is without implicit non-const to const conversion: var mut2immut * const Object = const(&Object{}) var immut2mut const * Object = &const(Object{}) var immut2immut const * const Object = const(&const(Object{})) func NewConstSlice() const [] * const Object { return [] * const Object { &const(Object{}), &const(Object{}), } } This is with implicit non-const to const conversion: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } Do you think that implicit non-const to const conversion is safe? (bearbeitet)

Как все сложно.

Как все сложно.

что конкретно сложно?

Guys, need your opinion on that: Should non-const types be automatically (implicitly) converted to const types? This is without implicit non-const to const conversion: var mut2immut * const Object = const(&Object{}) var immut2mut const * Object = &const(Object{}) var immut2immut const * const Object = const(&const(Object{})) func NewConstSlice() const [] * const Object { return [] * const Object { &const(Object{}), &const(Object{}), } } This is with implicit non-const to const conversion: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } Do you think that implicit non-const to const conversion is safe? (bearbeitet)

Do you speak English?

Do you speak English?

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

что конкретно сложно?

Читать это месиво сложно и просто в нем запутаться.

Честно говоря, даж не хочется поднимать ещё раз тему констов. Но меньше боилер плейта — лучше.

Честно говоря, даж не хочется поднимать ещё раз тему констов. Но меньше боилер плейта — лучше.

это не константы) или ты про keyword?

это не константы) или ты про keyword?

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

Читать это месиво сложно и просто в нем запутаться.

либо так, либо опасные мутабельные указатели везде..

Честно говоря, даж не хочется поднимать ещё раз тему констов. Но меньше боилер плейта — лучше.

если ты про const как boilerplate, то сейчас boilerplate это копирование, копирование, копирование. Представленный вариант boilerplate'а служит чисто ради безопасности и я вляется меньшим злом по сравнению с копированием =)

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

избегайте context value по возможности, передавайте что-либо через ctx value только в случае если вам приходится передавать сиё через сторонние библиотеки, например: ваш network -> 3-rd party GraphQL library -> ваш resolver function (в этом случае без context value не обойтись, ибо соторняя библиотека посредник, которая вызывает ваши функции, не знает ничего о тех данных, которые вы хотите через неё передать)

А можно рассказать или ссылку на почитать про контексты и почему их не желательно использовать? Я вообще не прибегал к ним ни разу, если конструктор структуры явно не требовал, но постоянно слышу легкое негодование вокруг контекстов. Что же не так?

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

вы пишете большой enterprise проект (возможно даже open source) на ассамблере?

А можно рассказать или ссылку на почитать про контексты и почему их не желательно использовать? Я вообще не прибегал к ним ни разу, если конструктор структуры явно не требовал, но постоянно слышу легкое негодование вокруг контекстов. Что же не так?

https://github.com/arangodb/go-driver/issues/142

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

возможно проблема "неприязни" связана с тем, что большинство людей на Go ещё не пишут большие проекты с большими командами и огромной кодовой базой (> 50k LOC как минимум) написать 1 человеку небольшой CLI automation tool до 1к LOC можно и без иммутабельности совершенно спокойно, и я вам открою тайну: вам даже не придётся использовать const в таком случае нигде (!) но вот когда 100 человек, работают над 1кк LOC и малейшая ошибка может стоит огромных денег - mutable shared state это рай для багов, они плодятся там как саранча и они сожрут вам все нервы, деньги и время. поэтому если вы хотите чтоб Go был конкурентноспособным в enterprise сфере и в сфере больших open source проектов, тогда без immutability никак.

возможно проблема "неприязни" связана с тем, что большинство людей на Go ещё не пишут большие проекты с большими командами и огромной кодовой базой (> 50k LOC как минимум) написать 1 человеку небольшой CLI automation tool до 1к LOC можно и без иммутабельности совершенно спокойно, и я вам открою тайну: вам даже не придётся использовать const в таком случае нигде (!) но вот когда 100 человек, работают над 1кк LOC и малейшая ошибка может стоит огромных денег - mutable shared state это рай для багов, они плодятся там как саранча и они сожрут вам все нервы, деньги и время. поэтому если вы хотите чтоб Go был конкурентноспособным в enterprise сфере и в сфере больших open source проектов, тогда без immutability никак.

ведь иммутабельность должна быть в языке изначально заложена во время проектирования языка?

ведь иммутабельность должна быть в языке изначально заложена во время проектирования языка?

Это не про JS например, там страдания и боль. :)

У меня даже шрам остался.

mutable shared state напрямую ведь с проблемами concurrency связан

ведь иммутабельность должна быть в языке изначально заложена во время проектирования языка?

мы это уже обсуждали. 1. Immutability не была заложена в язык изначально 2. Тем не менее она нужна 3. Мы (и Google видимо тоже) не хотим ломать совместимость 4. Поэтому мы "накладываем" иммутабельность на существующий язык посредством перегрузки const keyword'а о чём собственно и proposal

Guys, need your opinion on that: Should non-const types be automatically (implicitly) converted to const types? This is without implicit non-const to const conversion: var mut2immut * const Object = const(&Object{}) var immut2mut const * Object = &const(Object{}) var immut2immut const * const Object = const(&const(Object{})) func NewConstSlice() const [] * const Object { return [] * const Object { &const(Object{}), &const(Object{}), } } This is with implicit non-const to const conversion: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } Do you think that implicit non-const to const conversion is safe? (bearbeitet)

что-то отдалённо напоминает то, что в C++: int const * const

но var и const в одной строке выглядят сомнительно

но var и const в одной строке выглядят сомнительно

var это декларация переменной, const в данном случае это часть декларации типа данной переменной иммутабельный int != int иммутабельный Object != Object etc.

а если создать изменяемые и неизменяеме структуры данных в библиотеке(вместо того, чтобы менять язык)?

а если создать изменяемые и неизменяеме структуры данных в библиотеке(вместо того, чтобы менять язык)?

и как вы их создадите?

и как вы их создадите?

это надо продумать, в kotlin либе делают Immutable Collections

это надо продумать, в kotlin либе делают Immutable Collections

всё уже продумали в proposal'е, но если таки есть непродуманные моменты то конечно уточните, нам это важно

всё уже продумали в proposal'е, но если таки есть непродуманные моменты то конечно уточните, нам это важно

вроде изменения хотите внести именно в сам язык, а не в либу языка, правильно понимаю?

вроде изменения хотите внести именно в сам язык, а не в либу языка, правильно понимаю?

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

?разве это нормально читается: var immut2mut const * Object = &const(Object{})

?разве это нормально читается: var immut2mut const * Object = &const(Object{})

это без implicit conversion, поэтому я таки предлaгаю implicit conversion на non-const -> const

?разве это нормально читается: var immut2mut const * Object = &const(Object{})

с implicit вот так: var immut2mut const * Object = &Object{}

с implicit вот так: var immut2mut const * Object = &Object{}

так это тоже вызывает сомнения

как думаете, если этот код показать junior-у: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } поймёт ли он быстро?

скорее в окно выйдет

так это тоже вызывает сомнения

как часто вы декларируете переменные через var? ничего страшного нет в func Func(s const[] string) {} или даже в экстремальных случаях как: func Func(m const map[const * const Object] const * const Object) {} можно сделать так: type ConstObjRef const * const Object type ConstMap const map[ConstObjRef] ConstObjRef func Func(m ConstMap) {} учитывая что вас никто не заставляет использовать иммутабельные типы

скорее в окно выйдет

уже вышел

как часто вы декларируете переменные через var? ничего страшного нет в func Func(s const[] string) {} или даже в экстремальных случаях как: func Func(m const map[const * const Object] const * const Object) {} можно сделать так: type ConstObjRef const * const Object type ConstMap const map[ConstObjRef] ConstObjRef func Func(m ConstMap) {} учитывая что вас никто не заставляет использовать иммутабельные типы

я к тому, что var и const в одной строке объявления переменной - это противоречие

как думаете, если этот код показать junior-у: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } поймёт ли он быстро?

Да ты на es6 посмотри с иммутабельностью и радуйся

Насколько помню, было высоко оцененное предложение (можно поискать) использовать слово “readonly” как модификатор параметра функции. Без const и без изменений в объявлении переменных

Насколько помню, было высоко оцененное предложение (можно поискать) использовать слово “readonly” как модификатор параметра функции. Без const и без изменений в объявлении переменных

новое ключевое слово добавить?

Типа того. Но только для объявления функции

mutable shared state - это проблема concurrency, но по идее, решается с помощью мьютексов

но, например, есть https://golang.org/pkg/sync/#Map

он же concurrent-safe, правильно?

как думаете, если этот код показать junior-у: var mut2immut * const Object = &Object{} var immut2mut const * Object = &Object{} var immut2immut const * const Object = &Object{} func NewConstSlice() const [] * const Object { return [] * const Object { &Object{}, &Object{}, } } поймёт ли он быстро?

1. хуже будет если ваш джун по незнанию мутирует какой-то слайс, который ему мутировать нельзя, потому-что вы этого без тщательного code-review можете не заметить и создать баг. 2. С иммутабельностью ему просто компилятор этого сделать не позволит и он за пару дней поймёт что такое immutable variables / arguments / return values / methods / receivers 3. как-раз джуны делают ошибки с mutable shared state чаще всего, потому-что недостаточно понимают такие вещи как pointer aliasing (https://en.wikipedia.org/wiki/Pointer_aliasing) 4. вы считаете что копирование красивее и с ним меньше boilerplate'а? func (rec *T) ReadOnly(s []*Object) [] *Object { s_copy := make([] *Object, len(s)) for i, item := range s { // Clone must create an exact copy of *Object to avoid aliasing s_copy[i] = item.Clone() } // Pass copy to third-party function thirdparty.Dependency(s_copy) // now return an internal slice, but copy it to prevent mutations internal_copy := make([] *Object, len(rec.internal)) for i, item := range rec.internal { // Clone to avoid aliasing internal_copy[i] = item.Clone() } return internal_copy } вы сильно ошибаетесь: func (rec * const T) ReadOnly(s [] * const Object) [] * const Object { thirdparty.Dependency(s) return rec.internal } или же вот так: type ConstSlice [] * const Object func (rec * const T) ReadOnly(s ConstSlice) ConstSlice { thirdparty.Dependency(s) return rec.internal }

я правильно понимаю, что вы предлагаете решение проблемы, когда в более 2-х потоках одновременно записывается значение одной переменной?

нет

это совсем другая проблема

я правильно понимаю, что вы предлагаете решение проблемы, когда в более 2-х потоках одновременно записывается значение одной переменной?

нет, человек хочет чтобы другой человек не мог изменить его переменную

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

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

верно

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

а я думал, что mutable shared state связан с тем, что из множества потоков одновременно записываются значения в одну переменную

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

то есть вот это: concurrent access to shared mutable state

а я думал, что mutable shared state связан с тем, что из множества потоков одновременно записываются значения в одну переменную

shared state = состояние, которое делится между несколькими акторами. акторы могут быть как функции, так пакеты, так и потоки. Помогает ли иммутабельность при написании потенциально конкурентного кода? Да, потому-что у нас есть гарантия того, что то, что помечено иммутабельным, менять нельзя, а значит нельзя будет пообещать n потокам что ты не будешь писать в X и всё-равно это сделать Иммутабельность это только про конкурентность? Нет, это скорее про ещё более точно определённые типизированные интерфейсы. Если каким либо стейтом делятся несколько функций разных вендоров (не конкурентно) то мутабельность может порадить страшные баги потому-что кто-то, где-то накосячил

shared state = состояние, которое делится между несколькими акторами. акторы могут быть как функции, так пакеты, так и потоки. Помогает ли иммутабельность при написании потенциально конкурентного кода? Да, потому-что у нас есть гарантия того, что то, что помечено иммутабельным, менять нельзя, а значит нельзя будет пообещать n потокам что ты не будешь писать в X и всё-равно это сделать Иммутабельность это только про конкурентность? Нет, это скорее про ещё более точно определённые типизированные интерфейсы. Если каким либо стейтом делятся несколько функций разных вендоров (не конкурентно) то мутабельность может порадить страшные баги потому-что кто-то, где-то накосячил

понятно

вопрос о правильности подхода: встретил комментарий на редите "Also, Go is a "Get Shit Done" language: you don't design Go programs as you would design a Java project. You write the code, prove it works, then generalize and clean up the mess. What you're left with is clean, idiomatic Go." т.е. автор, как я понял за то, чтобы написать по каким-то эскизам код, потом посотреть на него, почистить всякое дерьмо, потом снова посмотреть на код и т.д.

вы придерживаетесь такого принципа?

https://github.com/romshark/Go-2-Proposal---Immutability#39-doesnt-the-const-qualifier-add-boilerplate-and-make-code-harder-to-read

вопрос о правильности подхода: встретил комментарий на редите "Also, Go is a "Get Shit Done" language: you don't design Go programs as you would design a Java project. You write the code, prove it works, then generalize and clean up the mess. What you're left with is clean, idiomatic Go." т.е. автор, как я понял за то, чтобы написать по каким-то эскизам код, потом посотреть на него, почистить всякое дерьмо, потом снова посмотреть на код и т.д.

да, вот только копирование не уберёшь никак))) ибо в месте с ним уберёшь безопасность... а "get shit done" это не синоним "тяк хуяк и так сойдёт"

вы придерживаетесь такого принципа?

вообще-то да. java провоцирует over-engineering, и это давно известный печальный факт go местами провоцирует under-engineering, но это настолько очевидно, что тимлид легко даст вам по рукам

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

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

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

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

Причём тут компилятор? Я про людей)

Причём тут компилятор? Я про людей)

и в чём вы видите сложность?

const * const это сложно

И уродливо

> Если хочется правильных и нужных концепций пишите на раст вот откуда эта уверенность? нам что, уже дали большой проект на расте? мы что, уже убедились, что в нем правильные абстракции и нужные концепции? все, что я слышал про попытки применения раста в проде (я слышал мало), заканчивалось словами "оно падало, стектрейс был неинформативен". в 1/3 случаев за этим следовало "и мы переписали все на go"

const * const это сложно

а []string по вашему это легко получается?

Но спорить я не хочу я высказал мнение, а уж прав или нет покажет время

Но спорить я не хочу я высказал мнение, а уж прав или нет покажет время

коллега, вы не правы, потому-что pointer aliasing и shared mutable state это сложно! не надо выдавать эти концепции за "просто" потому-что синтаксис легче... что такое синтаксис, если вам потом 10 часов дебажить непонятный баг?

> Если хочется правильных и нужных концепций пишите на раст вот откуда эта уверенность? нам что, уже дали большой проект на расте? мы что, уже убедились, что в нем правильные абстракции и нужные концепции? все, что я слышал про попытки применения раста в проде (я слышал мало), заканчивалось словами "оно падало, стектрейс был неинформативен". в 1/3 случаев за этим следовало "и мы переписали все на go"

А я спорю о его применимости в проде? Но если вам нужны концепции то вам в раст, не в го

коллега, вы не правы, потому-что pointer aliasing и shared mutable state это сложно! не надо выдавать эти концепции за "просто" потому-что синтаксис легче... что такое синтаксис, если вам потом 10 часов дебажить непонятный баг?

Прав я или нет вы узнаете когда предложите свой пропозал и узнаете его судьбу

ну вот мы тут думаем, как завезти compile-time контроль иммутабельности в go. коллега Роман целый пропозал написал. а я свой не написал пока, но напишу обязательно

ну вот мы тут думаем, как завезти compile-time контроль иммутабельности в go. коллега Роман целый пропозал написал. а я свой не написал пока, но напишу обязательно

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

Я даже думаю что дженерики и обработку ошибок им пропихивают откуда то сверху

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

ну вот именно пропозал Романа оставляет ощущение чуждости, да

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

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