враппер уменьшает mettal cost, ага... это реально стокгольмский синдром :(

так и const не уменьшает. Враперы - пассивный мазохизм, поскольку они по дефлту, const - активный, поиск дополнительных костылей. Разница не велика

да. шаг к чистым функциям

которых в голанге никогда не будет

mental cost увеличивается, когда вы не понимаете, почему у вас где-то мутирует слайс. а когда у вас есть гарантии и компилятор не позволит никому творить безобразие а в документации обещать что "я этого не делаю" - работать в Open Source комьюнити и команде, да даже одному над большим проектом - становится легче

Go - это к сожалению не про гарантии компилятора, абстракции и большие проекты. Go - это про написание небольших программ без особо глубоких абстракций силами не очень смышлённых программистов.

Go - это к сожалению не про гарантии компилятора, абстракции и большие проекты. Go - это про написание небольших программ без особо глубоких абстракций силами не очень смышлённых программистов.

с чего такие выводы?

с чего такие выводы?

Со всего того что есть и чего нет в Go.

Конкретно что не устраивает?

Да хоть те же слайсы.

А что с ними не так?

Только вот без дженериков срачи

Астарожна

Ну Go это как бы принципиально concurrency язык. И в нём есть примитив, который позволяет любому желающему без зазрений совести мутировать нижележащий массив, который может лежать ещё под парочкой слайсов.

Что же тут может пойти не так? Да вообще всё.

Поэтому надо следить за собой и за коллегами, чтобы не мутировать то что не стоит мутировать.

Самому следить. Ведь возложить такую слежку на компилятор не представляется возможным.

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

Ну изменять напрямую массив под слайсом никто не может

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

Ну изменять напрямую массив под слайсом никто не может

Ну вообще то вроде можно, когда я в последний раз проверял

И через сам массив, и через другие слайсы

да почитай его уже :)

таких пропозалов уже до хера было, ничего нового

ну массив может меняться только в случае нехватки места, все

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

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

ну массив может меняться только в случае нехватки места, все

Нет

Нет

А когда еще?

Ну вообще то вроде можно, когда я в последний раз проверял

И тут не может быть "в последний раз проверял"

Спеку читайте хоть перед срачами

ну массив может меняться только в случае нехватки места, все

Слайсы не обязаны быть созданы динамически.

Странно конечно, что это приходится объяснять гоферам в го чатике.

А когда еще?

Перевыделение да, может произойти при grow. А мутировать данные внутри может любой дурак, пока syscall соответствующий не дернешь

Странно конечно, что это приходится объяснять гоферам в го чатике.

Вот да

Хотя сентябрь, час дня, школоло набегают на чатики

Перевыделение да, может произойти при grow. А мутировать данные внутри может любой дурак, пока syscall соответствующий не дернешь

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

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

Естественно

Как?

Да, бл*дь, три секунды подумав

&s[0]

Да даже не напрямую, а через другой слайс

И это только один из тонны вариантов

с const два варианта есть реальных = сделать его неглубоким - и в этом случае он практически бесполезен. 2 - сделать всё неизменяемым по умолчанию как предлагал Даниель. И это будут ещё хуже чем питон 2/3, сломает простоту системы типов и превратит Голанг в говнораст - и тоже мало что даст, поскольку изначально язык мутабельный

Просто на самом деле все эти иммутабельные данные, чистые функции и прочая функциональная петушня не от хорошей жизни взялись.

И особенную роль они как раз начинают играть при появлении многопоточности

параллелизма в широком смысле

именно

&s[0]

ну и как вы собираетесь менять массив ?

Просто на самом деле все эти иммутабельные данные, чистые функции и прочая функциональная петушня не от хорошей жизни взялись.

Роб превентивно сделал персистентные структуры данных, выложил на гитхаб и сказал, что использование вот такого функционального гейства discouraged.

ну и как вы собираетесь менять массив ?

вот имеено заменять

Роб превентивно сделал персистентные структуры данных, выложил на гитхаб и сказал, что использование вот такого функционального гейства discouraged.

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

или менять его елементы которые не входят в диапазон слайса

ну и как вы собираетесь менять массив ?

Ну блеадь, Никита. Ты сам придумал задачу "заменять". Хочешь заменить - gramework/runtimer в помощь.

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

давай лучше будум верить местным сетлым головам, инфа 100%

или менять его елементы которые не входят в диапазон слайса

Что ты несёшь?

Что ты несёшь?

Окей, может мы говорим о разных вещах

давай определимся сначала

давай лучше будум верить местным сетлым головам, инфа 100%

Опять неверно. Нужно не слепо верить, а своей головой думать.

Опять неверно. Нужно не слепо верить, а своей головой думать.

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

Человек выше говорил что мы можем менять массив под слайсом, верно? Я это понял так, что он говорит о том, что мы можем напрямую менять елементы всего массива

Человек выше говорил что мы можем менять массив под слайсом, верно? Я это понял так, что он говорит о том, что мы можем напрямую менять елементы всего массива

Не менять, а мутировать

Мутировать, пусть будет так

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

Кому я говорил верить?

Не заменять подлежащий массив (хотя это тоже можем через unsafe)

Кому я говорил верить?

"слепо ему следовать"

хотя я такого не предлагал ведь

"слепо ему следовать"

Это был сарказм

Перевыделение да, может произойти при grow. А мутировать данные внутри может любой дурак, пока syscall соответствующий не дернешь

все, значит я неправильно понял что тут было сказано

Человек выше говорил что мы можем менять массив под слайсом, верно? Я это понял так, что он говорит о том, что мы можем напрямую менять елементы всего массива

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

ERROR: S client not available

ничего страшного, race детектор же выдали

ничего страшного, race детектор же выдали

#действительно

в смысле, небо не рухнет на землю.

Да действительно, жаль не существует таких структур данных, для которых вообще не требуется синхронизация.

Видел, как чел запускал -race с gomaxprocs=1

"потому что если больше, то оно ругается много"

Да действительно, жаль не существует таких структур данных, для которых вообще не требуется синхронизация.

существуют. Иммутабельные персистентны DS. Даже в голанге можно

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

ну в принципе очевидно, что в этом случае нужна синхронизация

существуют. Иммутабельные персистентны DS. Даже в голанге можно

Но они же не нужны. Ведь Роб Пайк сказал что discouraged. Как и [запрещённое слово в этом чатике].

Но они же не нужны. Ведь Роб Пайк сказал что discouraged. Как и [запрещённое слово в этом чатике].

конечно же не нужны. они только в хаскиле работают. А учитывая, что хаскиль ни кому не нужен - не работают ни где

конечно же не нужны. они только в хаскиле работают. А учитывая, что хаскиль ни кому не нужен - не работают ни где

А ну да. Ведь нигде, ни в одном языке кроме хаскеля нельзя сделать такие штуки.

А ну да. Ведь нигде, ни в одном языке кроме хаскеля нельзя сделать такие штуки.

можно всё что угодно, но есть понятие целесообразности

можно всё что угодно, но есть понятие целесообразности

А я понял, да. Действительно, зачем накладывать ответственность за целостность и непротиворечивость данных на компилятор, типы, структуры данных, когда это можно делать руками?

ты ничего не понял и слышишь только себя

конечно

А я понял, да. Действительно, зачем накладывать ответственность за целостность и непротиворечивость данных на компилятор, типы, структуры данных, когда это можно делать руками?

Но кстати го в этом отношении пошёл даже ещё дальше. То есть программисту даже выбора такого не предоставили: вот тебе исключительно мутабельные структуры данных, а про функциональную петушню вообще забудь, ведь тебе даже инструментов для создания такой петушни не выдали.

Что те не выдали? Тебе надо - ты и делай, Как сделаешь - позови. А до тех пор это у тебя не более чем пустое нытьё

Что те не выдали? Тебе надо - ты и делай, Как сделаешь - позови. А до тех пор это у тебя не более чем пустое нытьё

Ну скоро (относительно) выдадут, когда go2 появится.

Причём из аргументов против я услышал лишь "хаскиль никто не юзает" (чего я не отрицаю) и "Робу Пайку не зашло"

всякие map, filter итд над слайсами и мапами было бы удобно иметь

? еретики!

всякие map, filter итд над слайсами и мапами было бы удобно иметь

всё, ща забанят тебя за такое

ну почему

сначала мап с фильтром, а потом что ? монады тебе подавай ?

вот именно

их реально не хватает. for range каждый раз писать это ебала какая-то. даже вон в жс есть

Чёт я прям поднял оппозиционные настроения в чатике

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

Я вообще считаю, что программист должен решать когда и что юзать.

Где-то иммутабельность прям отлично зайдёт, где-то будет очень сильно мешать