type bResponse struct { Data struct { Event [1]event json:"events" } json:"data" } type event struct { Id string json:"id" } var bResp bResponse

То есть сохранил и сразу же изменения на сервере

Go: вы должны знать это, прежде чем использовать Defer https://dev-gang.ru/article/go-vy-dolzhny-znat-eto-prezhde-czem-ispolzovat-defer-5vfvem6a0o/ @Golang_google

А в каких случаях используется эта функция? Объясните новичку, пожалуйста)

А в каких случаях используется эта функция? Объясните новичку, пожалуйста)

Например func() { f := file.Open() defer f.Close() f.Read() f.xxx f.yyy return }

Например func() { f := file.Open() defer f.Close() f.Read() f.xxx f.yyy return }

А каким образом определяется после чего выполняется функция f.Close?

А каким образом определяется после чего выполняется функция f.Close?

Просто в языках без defer может появиться необходимость писать f.Close несколько раз, например func() { f.Open() try { f.Work() }catch(){ f.Close() return } f.Work2() f.Close() return } Хотя можно было бы сэкономить func() { f.Open() defer f.close() try { f.Work() }catch(){ return } f.Work2() return }

Спасибо, посмотрю где мне может это пригодится

Ты ещё посмотри про goto тоже полезная штука

Я его использовал в этом случае loop: .... goto loop

В вузе на плюсах нам говорили, что goto это моветон и подобное только в ассемблере без цикличных структур можно юзать. Всегда удивлялся, что в го его используют Не помню правда, на сколько функционал пересекается

В вузе на плюсах нам говорили, что goto это моветон и подобное только в ассемблере без цикличных структур можно юзать. Всегда удивлялся, что в го его используют Не помню правда, на сколько функционал пересекается

Например func() { f := file.Open() defer f.Close() f.Read() f.xxx f.yyy return }

Всем привет, подскажите пожалуйста литературу для начинающих) та с которой можно начать изучение Go

здесь кстати цикл for и операторы break/continue

Для циклов старайтесь использовать подходящие конструкции(for break continue) Не зря ведь их придумали? Операторы goto и их метки, можешь применять когда будешь писать на ассембллере.

Go: вы должны знать это, прежде чем использовать Defer https://dev-gang.ru/article/go-vy-dolzhny-znat-eto-prezhde-czem-ispolzovat-defer-5vfvem6a0o/ @Golang_google

Если код жирный, то мелкий defer вряд ли сильно сыграет. А в мелком коде где .lock/.unlock какой-нибудь компилятор может всё это заинлайнить. Если внутри кода не создаются defer динамически, то все это свободно может лежать на стеке или вообще быть заинлайненым. Тем более что проц тоже может оптимизировать джампы предзагрузкой. У меня с defer другой прикол был. type foo struct { i int } func (f *foo) inc() int { f.i++ return f.i } func main() { f := foo{} defer fmt.Println(f.inc()) f.i = 100 } Ожидал увидеть 101, увидел 1

Если код жирный, то мелкий defer вряд ли сильно сыграет. А в мелком коде где .lock/.unlock какой-нибудь компилятор может всё это заинлайнить. Если внутри кода не создаются defer динамически, то все это свободно может лежать на стеке или вообще быть заинлайненым. Тем более что проц тоже может оптимизировать джампы предзагрузкой. У меня с defer другой прикол был. type foo struct { i int } func (f *foo) inc() int { f.i++ return f.i } func main() { f := foo{} defer fmt.Println(f.inc()) f.i = 100 } Ожидал увидеть 101, увидел 1

ну потому что у тебя дефер создает свою переменную, хочешь увидеть 101, напиши так defer func() { fmt.Println(f.inc()) }()

Не понял насчет переменной. Если про f, то scope она не покидает. Если про f.inc, то согласен. А так я полез в спеку и прочитал что defer вычисляет функцию и её аргументы на этапе самого defer statement, то есть в defer регистрируется вызов Println(1)

Не понял насчет переменной. Если про f, то scope она не покидает. Если про f.inc, то согласен. А так я полез в спеку и прочитал что defer вычисляет функцию и её аргументы на этапе самого defer statement, то есть в defer регистрируется вызов Println(1)

хотя я внимательнее прочитал твое сообщение выше..ты и сам разобрался)

А насколько тогда правильная практика писать defer { f() }() вместо defer f()? Я часто вижу код где даже простейшие функции defer-ят по первому способу, хотя второй меньше когнитивных усилий требует. Мне казалось что по первому способу только джуны делают, а может я чего-то не понимаю и на самом деле это подход сениоров? Получается первый подход безопаснее, тем более компилятору по барабану и он может первый способ переписать во второй, не создавая анонимную функцию/литерал. У меня-то в defer однострочник, поэтому проглядел, а линтер-правила на это дело нету: всё же x := f.inc() defer fmt.Println(x) более прозрачно чем defer fmt.Println(f.inc())

А тебя не смущает что даже IDE твой go mod красным просвечивает?)

кто может подсказать как это решить?) Начал знакомиться с докером и сразу ошибочка

это значит, что он не добавлен в Git

в GOPATH не должно быть модулей.

Да, спасибо, нашел хорошую статью

Ребят, я правильно понимаю, что в x и y значение канала запишется после того, как обе горутины завершат свою работу? или вторая горутина будет ждать, пока завершится первая (но тогда, как я понимаю, отпадает их смысл) func main() { s := []int{7, 2, 8, -9, 4, 0} c := make(chan int) go sum(s[:len(s)/2], c) go sum(s[len(s)/2:], c) x := <-c y := <-c fmt.Println(x, y, x+y) }