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

и переделывать скорее всего всё равно придётся значительно

А почему нельзя подождать Go2? Это ведь не просто новые методы в существующем пакете, а изменение языка, причем достаточно серьезное. Why overload the const keyword instead of introducing a new keyword like immutable etc.?

А зачем ждать Go 2 (которого возможно ещё многие годы не будет) если можно уже сейчас действовать?

и переделывать скорее всего всё равно придётся значительно

Я просто к тому, что при всей крутости предложения его могут отклонить тупо по тому что это нерациональное расходование времени, которое можно направить на проектирование и реализацию Go2, пусть ещё и далекого.

А почему нельзя подождать Go2? Это ведь не просто новые методы в существующем пакете, а изменение языка, причем достаточно серьезное. Why overload the const keyword instead of introducing a new keyword like immutable etc.?

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

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

Да я вижу, что ничего не ломается

Я просто к тому, что при всей крутости предложения его могут отклонить тупо по тому что это нерациональное расходование времени, которое можно направить на проектирование и реализацию Go2, пусть ещё и далекого.

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

потому что Go2 будет через несколько лет, если будет, а Роман предлагает в т.ч. неломающую совместимость фичу для 1.*

я предлагаю как неломающий компромис для Go 1.x, так и более лучший подход к иммутабельности в Go 2.x

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

Вот поэтому интересно послушать тех, что маломальски знаком с кодом компилятора.

Я просто не знаком

я немного знаком

но совсем немного

а когда Go2 будет? а взлетит ли он вообще на фоне допиленного до конфетки раста или вообще языков следующего поколения? а фичи хочется уже сейчас

не сравнивайте Go с Rust. Это абсолютно разные инструменты для решения абсолютно разных проблем. https://www.quora.com/Will-Go-over-take-Rust-as-the-most-popular-language-compiled-to-WebAssembly/answers/97741098

но я к примеру знаю, что там два парсера, один для компилера, другой для go fmt и прочих утилит

зачем так сделали мне совершенно не ясно

если кто-то мне прояснит, то будет вообще круто

исторические причины, помоему

Алсо ИМХО иммутабельность по дефолту не нужна.

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

не сравнивайте Go с Rust. Это абсолютно разные инструменты для решения абсолютно разных проблем. https://www.quora.com/Will-Go-over-take-Rust-as-the-most-popular-language-compiled-to-WebAssembly/answers/97741098

не совсем, rust сейчас активно допиливают для врыва в веб, до конца года обещают завести async в stable и обсуждают аналог горутин на этом async’е

исторические причины, помоему

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

просто fmt был изначально, а парсер написали к 1.5

не совсем, rust сейчас активно допиливают для врыва в веб, до конца года обещают завести async в stable и обсуждают аналог горутин на этом async’е

Раст всё ещё нацелен на решение других задач. Его врыв в веб это конечно хорошо, но нишу Го он вряд ли отвоюет без боя.

Причём там написано в стиле Роба Пайка, то есть всё руками без особой кодогенерации через какой-нибудь bison/antlr/что угодно

Причём в обоих парсерах

Раст всё ещё нацелен на решение других задач. Его врыв в веб это конечно хорошо, но нишу Го он вряд ли отвоюет без боя.

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

хотя я с таким подходом не согласен совершенно

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

Ну удачи ребятам, чо, конкуренция ещё никому не мешала.

Растоманам может и нужна. Там я против неё ничего не имею, безопасность и всё такое. У Го немного другой прицел, ИМХО.

какой другой прицел? безответственность? я не предлагаю убирать GC и завозить ownership & borrowing взамен. я предлагаю уточнить систему типов, которая по описаниям в пропосале - чуток хромает из-за того что иммутабельных типов нет, которые же можно без проблем завезти. основная разница Rust'а и Go это разные подходы к МЕНЕДЖМЕНТУ ПАМЯТИ! - GC (Go) это просто - ownership & borrowing (Rust) это сложнее - RAII (C++) это очень сложно - alloc/delete (C) это адово сложно поэтому не надо сравнивать Rust и Go и гнать на compile-time security. Потому-что compile-time security это очень важно во времена большого, сложного, конкуррентного open source кода. А имутабельные типы НЕ вносят значительный overhead в процесс компиляции (в теории, числа зависят от конкретной имплементации)! Понижение скорости компиляции настолько незначительное что вы его не заметите.

не совсем, rust сейчас активно допиливают для врыва в веб, до конца года обещают завести async в stable и обсуждают аналог горутин на этом async’е

??

какой другой прицел? безответственность? я не предлагаю убирать GC и завозить ownership & borrowing взамен. я предлагаю уточнить систему типов, которая по описаниям в пропосале - чуток хромает из-за того что иммутабельных типов нет, которые же можно без проблем завезти. основная разница Rust'а и Go это разные подходы к МЕНЕДЖМЕНТУ ПАМЯТИ! - GC (Go) это просто - ownership & borrowing (Rust) это сложнее - RAII (C++) это очень сложно - alloc/delete (C) это адово сложно поэтому не надо сравнивать Rust и Go и гнать на compile-time security. Потому-что compile-time security это очень важно во времена большого, сложного, конкуррентного open source кода. А имутабельные типы НЕ вносят значительный overhead в процесс компиляции (в теории, числа зависят от конкретной имплементации)! Понижение скорости компиляции настолько незначительное что вы его не заметите.

и после последнего предложения я ожидал увидеть пруфы/бенчи, которых нет =(

да тут и не надо особо пруфов

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

какой другой прицел? безответственность? я не предлагаю убирать GC и завозить ownership & borrowing взамен. я предлагаю уточнить систему типов, которая по описаниям в пропосале - чуток хромает из-за того что иммутабельных типов нет, которые же можно без проблем завезти. основная разница Rust'а и Go это разные подходы к МЕНЕДЖМЕНТУ ПАМЯТИ! - GC (Go) это просто - ownership & borrowing (Rust) это сложнее - RAII (C++) это очень сложно - alloc/delete (C) это адово сложно поэтому не надо сравнивать Rust и Go и гнать на compile-time security. Потому-что compile-time security это очень важно во времена большого, сложного, конкуррентного open source кода. А имутабельные типы НЕ вносят значительный overhead в процесс компиляции (в теории, числа зависят от конкретной имплементации)! Понижение скорости компиляции настолько незначительное что вы его не заметите.

Здесь есть люди пилящие го компайлер? Их много?

Здесь есть люди пилящие го компайлер? Их много?

где-то был один точно

Здесь есть люди пилящие го компайлер? Их много?

я в нём ковыряюсь, но не особо глубоко

да и скорее всего если я даже сделаю pull request, то его наверняка не примут

и после последнего предложения я ожидал увидеть пруфы/бенчи, которых нет =(

?? исправил: (в теории, числа зависят от конкретной имплементации) дело в том, что всё что компилятор должен сделать это пройтись по иммутабельным типам и проверить assignment'ы полей и вызовы методов с мутабельным питом receiver'а, это вам NP проблема...

так что мои изменения (если их удастся внести) скорее всего так и останутся моими :(

Здесь есть люди пилящие го компайлер? Их много?

я не в курсе

?? исправил: (в теории, числа зависят от конкретной имплементации) дело в том, что всё что компилятор должен сделать это пройтись по иммутабельным типам и проверить assignment'ы полей и вызовы методов с мутабельным питом receiver'а, это вам NP проблема...

кстати, а че там про анонимные функции?

кстати, а че там про анонимные функции?

а что с ними?

а что с ними?

var a const func() что значит

var a const func() что значит

это типичная иммутабельная переменная, это означает что в a нельзя присвоить никакую другую функцию: var a const func() { fmt.Print("A") } /*...*/ a = const func() { fmt.Print("B") } // Compile-time error .example.go:3:3: cannot assign to immutable variable a

это типичная иммутабельная переменная, это означает что в a нельзя присвоить никакую другую функцию: var a const func() { fmt.Print("A") } /*...*/ a = const func() { fmt.Print("B") } // Compile-time error .example.go:3:3: cannot assign to immutable variable a

А каков в итоге план? Тут в чатике с экспертами классно, конечно обсуждать, но мне интересено послушать доводы go core-developers

А каков в итоге план? Тут в чатике с экспертами классно, конечно обсуждать, но мне интересено послушать доводы go core-developers

как только я допишу этот proposal я буду пушать его в массы и в том числе опубликую в официальном issue section. в идеале нужно написать PoC линтер, который позволил бы представить идею в работе без поддержки const квалификатора компилятором, но это уже более затратно по времени, посмотрим

Вообще сама идея мне нравится

а вот насчёт реализации я не уверен

это я про иммутабельность если что

Зе сейм. Но я не знаю что ещё можно предложить, не поломав совместимость с Go1.

я подумываю переименовать документ в Go 1/2 - Immutable Types

Зе сейм. Но я не знаю что ещё можно предложить, не поломав совместимость с Go1.

ничего там не ломается, читай

ничего там не ломается, читай

Я и говорю, что предложенное тобой, единственное, что ничего не ломает.

Но можно сделать синтакс лучше, поломав :)

Подскажите best practice по написанию тестов на Go? Или киньте ссылкой, пожалуйста

@Romshark ImmutableField const *Object, а если вот так объявить, то что будет? Я туповат под вечер

Ты в примере пишешь: type Object struct { ImmutableField const * const Object // Immutable MutableField *Object // Mutable }

Но можно сделать синтакс лучше, поломав :)

не только синтаксис, но и safety

Подскажите best practice по написанию тестов на Go? Или киньте ссылкой, пожалуйста

а что конкретно тебя интересует то? best practice описаны в официальных доках

@Romshark ImmutableField const *Object, а если вот так объявить, то что будет? Я туповат под вечер

не понял вопрос

не понял вопрос

type Object struct { ImmutableField const * const Object // Immutable MutableField *Object // Mutable }

Я вот про этот пример.

Ты в примере пишешь: type Object struct { ImmutableField const * const Object // Immutable MutableField *Object // Mutable }

const * Object это иммутабельный указатель на мутабельный объект: https://github.com/romshark/Go-2-Proposal---Immutability#2911-immutable-pointer-to-mutable-object

const * Object это иммутабельный указатель на мутабельный объект: https://github.com/romshark/Go-2-Proposal---Immutability#2911-immutable-pointer-to-mutable-object

То есть я не смогу изменить указатель, но смогу поменять к примеру поля в теле объекта?

То есть я не смогу изменить указатель, но смогу поменять к примеру поля в теле объекта?

совершенно верно, и зачем это надо описано вот здесь: https://github.com/romshark/Go-2-Proposal---Immutability#49-why-do-we-need-the-distinction-between-immutable-and-mutable-reference-types

Ага, понял

вот это как раз выглядит как-то не очень

То есть я не смогу изменить указатель, но смогу поменять к примеру поля в теле объекта?

вернее, ты сможешь изменить сам указатель, указывать на другой объект. Но сам объект на который этот указатель указывает - изменить не сможешь

ERROR: S client not available

вот это как раз выглядит как-то не очень

иначе никак. я в большинстве случаев привожу worst case'ы, best case'ы в пропосале мало кого интересуют

вернее, ты сможешь изменить сам указатель, указывать на другой объект. Но сам объект на который этот указатель указывает - изменить не сможешь

Разве это не * const Object?

вот это как раз выглядит как-то не очень

а вообще для этого имеются Type Aliases: type ObjectRef const * const Object

Разве это не * const Object?

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

а вообще для этого имеются Type Aliases: type ObjectRef const * const Object

это кстати тоже не особо круто в плане читаемости, потому что у Go так type устроен очень кратко

слишком кратко я бы сказал

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

справа от него как раз Object, ты пишешь "но сам объект на который этот указатель указывает - изменить не сможешь"

это кстати тоже не особо круто в плане читаемости, потому что у Go так type устроен очень кратко

с синтактической подсветкой всё норм, мы не в 1970 году

Вот и получается что не наоборот, разве нет?

с синтактической подсветкой всё норм, мы не в 1970 году

Роб Пайк не любит синтаксическую подсветку

Роб Пайк не любит синтаксическую подсветку

а mutable shared state он любит?)) он сам сказал что не любит: https://youtu.be/BBbv1ej0fFo

а mutable shared state он любит?)) он сам сказал что не любит: https://youtu.be/BBbv1ej0fFo

бедный D, у него будущего нет, да и прошлого тоже

да и Go не про системное программирование

справа от него как раз Object, ты пишешь "но сам объект на который этот указатель указывает - изменить не сможешь"

const * const Object иммут. указатель на иммут. структуру const * Object иммут. указатель на мут. структуру * const Object мут. указатель на иммут. структуру * Object мут. указатель на мут. структуру https://github.com/romshark/Go-2-Proposal---Immutability#291-pointer-examples

да и Go не про системное программирование

Алсо я теперь всегда должен буду пробел ставить?)

Можно же написать *Object по классике?)

Алсо я теперь всегда должен буду пробел ставить?)

это зависит от gofmt, как они решат

Можно же написать *Object по классике?)

const*const Object согласись как-то не очень?

const*const Object согласись как-то не очень?

ну постоянные const в стиле крестов тоже так себе

Потенциальное mut * mut Object меня тоже не сильно радует

Потенциальное mut * mut Object меня тоже не сильно радует

такого не будет

такого не будет

Так вон: https://github.com/romshark/Go-2-Proposal---Immutability#3-immutability-by-default-go--2x

аа

ну постоянные const в стиле крестов тоже так себе

поэтому immut по умолчанию предлагаю для Go 2, ибо по статистике мутабельности должно быть меньше чем немутабельности

Потенциальное mut * mut Object меня тоже не сильно радует

тем не менее кратче и безопаснее

а, я думал и mut и const вместе

уф

Почему, кстати, там так: Immutable_immutMap_of_immutObj map[Object] Object // immutable key Mutable_mutMap_of_immutObj mut [Object] Object // immutable key Mutable_mutMap_of_mutObj mut [mut Object] mut Object // mutable key А не вот так: Immutable_immutMap_of_immutObj map[Object] Object // immutable key Mutable_mutMap_of_immutObj mut map[Object] Object // immutable key Mutable_mutMap_of_mutObj mut map[mut Object] mut Object // mutable key

mutable key для мапы я бы вообще запретил

совсем

это вообще не имеет никакого смысла

а, я думал и mut и const вместе

нэээ, ты чёё