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

Можно пример?

Глобальные обычно всякие константы

Константы не изменяемы. Речь о переменных, которые могут быть изменены

название статьи - GlobalVariablesAreBad

Что-то мне подсказывает, что это не для Go.

Это для любого языка. Это вообще не относится к языку

Типа вы хотите сказать, что http.DefaultClient - это неправильно?

Это ж, как я понимаю, глобальная переменная

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

Типа вы хотите сказать, что http.DefaultClient - это неправильно?

Вообще говоря - нет

Вобщем, коротко говоря - наличие глобальных переменных, которые могут меняться из разных частей программы - зло. Я полагаю что это и было изначальным поинтом этого разговора

readonly спасёт мир

ФП спасёт мир)))

fix: (ФП (спасет (мир)))

а подключение к базе, логгеры, конфиг? Передавать в функции параметром? Или в каждой функции поднимать свое?

readonly спасёт мир

Пишем проги на одних константах 😳

хм... я про шарповый ридонли

readonly инициализируется в init, а далее ведёт себя как константа

а подключение к базе, логгеры, конфиг? Передавать в функции параметром? Или в каждой функции поднимать свое?

Как я понял, под "глобальные переменные" коллеги предполагают просты типы (int, string и т.п.).

а, тогда статью надо переименовать в SimpleTypeGlobalVariablesAreBad

fix(Variables(Are(Bad)))

fix(Variables(Are(Bad)))

fix(Variables(Are(Bad(Only(Braces(Rock))))))

а подключение к базе, логгеры, конфиг? Передавать в функции параметром? Или в каждой функции поднимать свое?

Я передаю аргументом к функции, конструирующей нужный объект. И логгеры и коннекты к базе, даже конфигурацию

fix(Variables(Are(Bad(Only(Braces(Rock))))))

https://www.cis.upenn.edu/~matuszek/General/JavaSyntax/parentheses.html

https://www.cis.upenn.edu/~matuszek/General/JavaSyntax/parentheses.html

Соре, меня просто json покусал, там чёртовы braces ((

Я передаю аргументом к функции, конструирующей нужный объект. И логгеры и коннекты к базе, даже конфигурацию

а если логгер нужен вообще везде?

а если логгер нужен вообще везде?

Значит передам его в каждое место где он нужен, явно

во все функции проекта?

В других языках это решается через IoC контейнер

в Go сколько не гуглил, адекватного контейнера не нашёл

во все функции проекта?

Во все конструкторы. Я отношусь к логгеру как к данным

Вопрос по math/rand Как сделать, что бы он генерировал случайные числа? package main import ( "fmt" "math/rand" ) func main() { fmt.Println(rand.Intn(100)) } всегда выводит число 81...

точнее, при каждом запуске программы, одно и тоже число

https://golang.org/pkg/math/rand/#Rand.Seed

точнее, при каждом запуске программы, одно и тоже число

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

ага, спасибо

Пишем проги на одних константах 😳

добро пожаловать в мир эрланга/кложура/лиспа/хаскеля/...?

просто immutable ?

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

надеюсь го в эту сторону придёт так или иначе

> неизменяемые переменные константы?

На самом деле непонятно, что мешает просто не менять.

> неизменяемые переменные константы?

Константы формируются на этапе компиляции. Переменные в рантайме при инициализации.

На самом деле непонятно, что мешает просто не менять.

любители отстрелить себе ногу

Пишите везде := и присваивайте по одной - компилятор сам начнет ругаться, что вы ее пытаетесь переопределить —- тут должен идти тролль-фейс ))

Пишите везде := и присваивайте по одной - компилятор сам начнет ругаться, что вы ее пытаетесь переопределить —- тут должен идти тролль-фейс ))

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

На самом деле непонятно, что мешает просто не менять.

То же, что мешает людям писать код без багов

То же, что мешает людям писать код без багов

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

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

Есть разные люди. Некоторые скажут "мне надо таск закрыть, хер с ним, вставлю костыль вот тут", через пару лет от таких умников проект идёт на выброс. И тут можно сколько угодно обкладывать кодовую базу различными процессами, но правда одна - компилятор не должен позволять делать то, что явно является не правильным

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

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

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

Я исхожу из своего опыта - ты из своего, на большой базе кода все предположения об интеллекте людей не верны

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

я тут во всём согласен с Дейвом https://dave.cheney.net/2017/06/15/simplicity-debt

Тот же, по-моему, Дейв писал о том, что нужно отказаться от глобальных переменных.

И сразу уходит глобальное состояние, которое можно менять.

ТО что все годами гонятт на глобальные переменные не новость

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

Ну это дело привычки. Нужно принять что придётся не менять что-то во вселенной, а создавать новую вселенную, где уже есть нужное изменение :D

ТО что все годами гонятт на глобальные переменные не новость

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

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

И тут иммутабельность ничем не поможет.

Угу

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

Скорее дело в убогости Go как языка (да, я так считаю и да, я люблю Go)

Скорее дело в убогости Go как языка (да, я так считаю и да, я люблю Go)

аналогично

это все диктуется чрезмерной лаконичностью и низкоуровневостью языка.

Как вот люди решают проблему большого конфига, у меня есть масштабный кофиг (на самом деле много, уровня приложения, уровня конкретного инстанса, уровня задачи) и читаю я в main и потом начинаю части его прокидывать в функции, но это уйма убогой писанины. И я постоянно думаю что сорвусь и дам пакетам своим или читать конфиг, или будут переменные глобальные

😂😂😂

Context

и в нём, что надо прокидывать

не?

Как вот люди решают проблему большого конфига, у меня есть масштабный кофиг (на самом деле много, уровня приложения, уровня конкретного инстанса, уровня задачи) и читаю я в main и потом начинаю части его прокидывать в функции, но это уйма убогой писанины. И я постоянно думаю что сорвусь и дам пакетам своим или читать конфиг, или будут переменные глобальные

по разному, но в общих чертах создай провайдер с неким интерфейсом типа GetValue(name string) и его прокидывай в функции. в го есть контекст, но это ок именно в каком-то связанном контексте, а не как замена глобальному конфиг провайдеру

Ну да, типа того. Но вот толи всю эту уйму конфигов пизхать в один контекст, толи делать дробить их

Как вот люди решают проблему большого конфига, у меня есть масштабный кофиг (на самом деле много, уровня приложения, уровня конкретного инстанса, уровня задачи) и читаю я в main и потом начинаю части его прокидывать в функции, но это уйма убогой писанины. И я постоянно думаю что сорвусь и дам пакетам своим или читать конфиг, или будут переменные глобальные

Пакет viper

Как вот люди решают проблему большого конфига, у меня есть масштабный кофиг (на самом деле много, уровня приложения, уровня конкретного инстанса, уровня задачи) и читаю я в main и потом начинаю части его прокидывать в функции, но это уйма убогой писанины. И я постоянно думаю что сорвусь и дам пакетам своим или читать конфиг, или будут переменные глобальные

а чеб не сделать пакет config и экспортировать оттуда что надо?

заодно внутри пакета можешь норм организовать конфиг по файлам

Пакет config есть, их как бы много. На уровне app , естьт конфиг где номер инстанса например и база, на уровне задачи например дургой конфиг , там какую таблицу процессить и тд

Пакет viper

Спасибо гляну

Т.е. в двух словах, или контексты или некий синглетон с методами getBlabla

Как вот люди решают проблему большого конфига, у меня есть масштабный кофиг (на самом деле много, уровня приложения, уровня конкретного инстанса, уровня задачи) и читаю я в main и потом начинаю части его прокидывать в функции, но это уйма убогой писанины. И я постоянно думаю что сорвусь и дам пакетам своим или читать конфиг, или будут переменные глобальные

Выстрой конфиг в дерево. Создай корень в виде некоторой структуры Config, которая внутрь себя встраивает более конкретные разделы конфига. Ветвление может идти вглубь на несколько уровней

А потом, сделать синглотоном? или чего с ним

А потом использовать там где он нужен, например так: Пакет с конфигом может выглядеть так https://github.com/corpix/market-fetcher/blob/master/config/config.go#L162 Использование так https://github.com/corpix/market-fetcher/blob/master/cli/root.go#L39

Спасибо!