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

не сравнивайте 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’е

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

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

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

не совсем, 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 в процесс компиляции (в теории, числа зависят от конкретной имплементации)! Понижение скорости компиляции настолько незначительное что вы его не заметите.

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

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

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

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

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

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

а что с ними?

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

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

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

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

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

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

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

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

Ты в примере пишешь: 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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