я тут скажу свое фи, мне кажется если вы хотите "защитить обьект" ну сделайте сеттеры и геттеры

жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности. Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код) func TakeSlice(slc []string) сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?... а завтра, одним комитом позже, он уже вдруг мутируется 😋 а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли? Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? 🙂

@ruelephant

Блин... Я это все прочитал. Целый день некогда было залезть в чат, а тут 500> сообщений. Роман совершенно прав, dangling pointers, pointer aliasing — это беда языка, если её не решить хоть каким способом. Скала, раст решили эту детскую проблему. Проблема очевидна только тем, кто её понимает. Начать понимать её можно только на больших командах (точнее разными командами на одном проекте), с очень разношерстной публикой от новичков до опытных. На проекте, где как обычно некогда разбираться, что делает чужой код/либа, но вдруг!! оказывается что она меняет твои данные (состояние), которые ты не ожидал для изменения! И не ты их сам сознательно поменял, а произошёл "side effect" и цепочка выполнения, которая к этому привела, оказалась "очень вычурной и витеиватой". Кто с этим сам не сталкивался, писал только "домашние" проекты, тот к сожалению мало понимает суть проблемы, увы.... Эта проблема отсутствует в скала, потому что заложена в языке, тк сделать мутацию как сайд-эффект можно только сознательно и тогда коллеги это внимательно изучат, насколько это оправдано. Раст решил это на уровне компилятора. Это же решение ОЧЕНЬ НЕОБХОДИМО в компиляторе Go. Но есть сомнения, как вообще создатели го относятся к этой идее? Какие были или нет контакты, комменты от них, Роман? Может имеет смысл бомбить их на почту, в гугл группе, в слак каналах? Какие кто знает "наиболее прямые точки доступа" к создателям языка и компилятора? Поставить star + watch в гитхабе — это почти ни о чем... Нужно больше усилий и я понимаю Романа и его постоянные попытки форсить и рекламировать свой proposal на канале. Но нужны другие, более "прямые и точные каналы", чтобы обращаться к "главным го разработчикам". Роман, думаю ещё стоило бы сделать более наглядные (то ли простые, то ли наоборот quiz, не очевидные примеры) с примером такого поведения, которое disaster. Да, иногда вы можете увидеть и дать кому то" по рукам" в своей команде, но лучше, чтобы за вас это делал компилятор!

Блин... Я это все прочитал. Целый день некогда было залезть в чат, а тут 500> сообщений. Роман совершенно прав, dangling pointers, pointer aliasing — это беда языка, если её не решить хоть каким способом. Скала, раст решили эту детскую проблему. Проблема очевидна только тем, кто её понимает. Начать понимать её можно только на больших командах (точнее разными командами на одном проекте), с очень разношерстной публикой от новичков до опытных. На проекте, где как обычно некогда разбираться, что делает чужой код/либа, но вдруг!! оказывается что она меняет твои данные (состояние), которые ты не ожидал для изменения! И не ты их сам сознательно поменял, а произошёл "side effect" и цепочка выполнения, которая к этому привела, оказалась "очень вычурной и витеиватой". Кто с этим сам не сталкивался, писал только "домашние" проекты, тот к сожалению мало понимает суть проблемы, увы.... Эта проблема отсутствует в скала, потому что заложена в языке, тк сделать мутацию как сайд-эффект можно только сознательно и тогда коллеги это внимательно изучат, насколько это оправдано. Раст решил это на уровне компилятора. Это же решение ОЧЕНЬ НЕОБХОДИМО в компиляторе Go. Но есть сомнения, как вообще создатели го относятся к этой идее? Какие были или нет контакты, комменты от них, Роман? Может имеет смысл бомбить их на почту, в гугл группе, в слак каналах? Какие кто знает "наиболее прямые точки доступа" к создателям языка и компилятора? Поставить star + watch в гитхабе — это почти ни о чем... Нужно больше усилий и я понимаю Романа и его постоянные попытки форсить и рекламировать свой proposal на канале. Но нужны другие, более "прямые и точные каналы", чтобы обращаться к "главным го разработчикам". Роман, думаю ещё стоило бы сделать более наглядные (то ли простые, то ли наоборот quiz, не очевидные примеры) с примером такого поведения, которое disaster. Да, иногда вы можете увидеть и дать кому то" по рукам" в своей команде, но лучше, чтобы за вас это делал компилятор!

привет.кто работал с https://github.com/Dimonchik0036/vk-api ,как в update.Message получить название беседы?

По моему создатели го сделали го типизированным лишь затем, чтобы он работал быстрее. Что уж говорить о каких-то нетривиальных компайл-тайм проверках.

Скажите, что для вас важнее? — Быстрее работа компилятора и кода на cpu — быстрее работа программера и "меньшее создание" неочевидных и трудно находимых ошибок? Какая из этих работ оценивается дешевле /дороже?

Скажите, что для вас важнее? — Быстрее работа компилятора и кода на cpu — быстрее работа программера и "меньшее создание" неочевидных и трудно находимых ошибок? Какая из этих работ оценивается дешевле /дороже?

Не факт, что скорость работы программера будет выше на расте/скале чем на го, если взять рандомного прогера и потратить одинаковое время на изучение языка

Для меня как для программера важно не копаться в нетипизированной ООП лапше без какого либо контроля эффектов.

Скала — строго типизированный язык, и при этом имеет это "из коробки".

Под "скоростью" я подразумевал немного другое, извините, не совсем точно выразился. Речь не про скорость кодинга или проектирования. Цена ошибки и цена её исправления, которая займёт время и нервы (а произойдёт она как правило на продакшн, и как бывает после свежего деплоя). Цену этого сложно вычислить "легко и точно". Но лучше и правильнее это сделать в языке и компилятором, даже за счёт "сложных проверок" или "увеличения времени компиляции", чем потраченными человеко-часами. Кто этого не понимает, увы, его убедить, что это важно сложно. Это только с опытом приходит, что лучше этого гемороя НЕ иметь и столкнуться "иногда", чем иметь заложеннвй в языке, для "супер скоростной компиляции".

Ошибки создаёт не язык, а программист.

Под "скоростью" я подразумевал немного другое, извините, не совсем точно выразился. Речь не про скорость кодинга или проектирования. Цена ошибки и цена её исправления, которая займёт время и нервы (а произойдёт она как правило на продакшн, и как бывает после свежего деплоя). Цену этого сложно вычислить "легко и точно". Но лучше и правильнее это сделать в языке и компилятором, даже за счёт "сложных проверок" или "увеличения времени компиляции", чем потраченными человеко-часами. Кто этого не понимает, увы, его убедить, что это важно сложно. Это только с опытом приходит, что лучше этого гемороя НЕ иметь и столкнуться "иногда", чем иметь заложеннвй в языке, для "супер скоростной компиляции".

Ошибки создаёт не язык, а программист.

Ошибки создаёт не язык, а программист.

Ошибки создаёт не язык, а программист.

нет, не просто, там речь шла о распределённой файловой системе. Думаю этим всё сказано без лишних деталей. Там основная часть логики в сервере а не в бд. Бд там в идеале должна быть kv, потому-что её легко распределять по узлам. Дело в том что архитектура планируется таким образом чтоб это было удобно для пользователя. Поставил второй комп, поставил на него контейнер, связал компы в кластер в UI'ке облака - вуаля.

Вот поэтому независимо от языка есть две лучшие практики: тесты и код ревью

если бы у нас так мосты строили, то их срок годности считался бы месяцами