Ребят, поделитесь кто плейлистом (кто работает слушая музыку) на работе в последнее время очень много отвлекающих факторов, приходится в наушниках работать

жанр?

Вообще я в основном Рок и метал слушаю, но для работы нужно что-бы было и приятно для ушей и что-бы сильно не отвлекало

Вообще я в основном Рок и метал слушаю, но для работы нужно что-бы было и приятно для ушей и что-бы сильно не отвлекало

Вообще я в основном Рок и метал слушаю, но для работы нужно что-бы было и приятно для ушей и что-бы сильно не отвлекало

да хер его знает, если честно. возможно, ржали, как кони и передавали косяк по кругу... обработка ошибок в go сделана "на отстань", мягко говоря. возможно, они собирались когда-нибудь потом это все переделать, но не успели до взрывной популярности знаете, да, что по началу у интерфейса error метод назывался String()? и что угодно, что его реализовывало, можно было вернуть в как ошибку?

не уверен, что можно вот так посоветовать что-то с потолка. попробуй на http://di.fm станцию liquid trap, например. или http://listentothe.cloud. еще мне нравятся подборки noonpacific на 8tracks https://8tracks.com/noonpacific. еще можно слушать тематические радио на google music.

+ http://www.radiox.co.uk, годное радио британское, заодно можно подтянуть английский немного. только придется вписать валидный индекс, чтобы обойти блокировку.

Ну не совсем. Тут больше Capital, BBC Radio и KISS.

А можно ли это правило переформулировать так: если реализация интерфейса имеет package область видимости, то возвращается интерфейс, а если это публичная структура, то структуру?

Create a GraphQL Server with Go and Google App Engine https://outcrawl.com/graphql-server-go-google-app-engine/

https://www.slideshare.net/DanielPodolsky/golang-highload

Вчера, разбирая в книге по Go пример со стеком на слайсах, задался вопросом: ведь в продакшене в сервисах 24/7 использование такого "стека" на слайсах никогда не отдаст память системе, если его рассматривать как часть состояния сервиса: var m []string; ... /// push m = append(m, some_string) ... /// pop m = m[:len(m)-1]

а чем руководствовались авторы Go в методе создания ошибки`func New(text string) error`, возвращая интерфейс error?

Маленький оффтоп - как в atom вызвать окно терминала?

вы не пытались прочитать об этом или не поняли?

Я прочитал о том, что не рекомендуется возвращать интерфейсы, но натолкнулся на errors, который этой рекомендации противоречит.

в каком смысле? error - интерфейс

в Go не рекомендуется возвращать интерфейсы, а предпочтение необходимо отдавать конкретным типам

вроде оно https://github.com/golang/go/wiki/CodeReviewComments#interfaces

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

"нет консруктора для дефолтной ошибки," - есть. только не конструктор, а функция

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

?? что ??

в го нет конструкторов

без этого шортката, каждый пакет обязан был создавтаь свой тип для ошибки

без этого шортката, каждый пакет обязан был создавтаь свой тип для ошибки

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

мы точно об одной статье говорим? https://github.com/golang/go/wiki/CodeReviewComments#interfaces

Есть кусок кода, В нём select limit 1000; update selected; как изолировать эту функцию, чтобы нельзя было вызвать её несколькими горутинами одновременно? #вопрос

и наоборот, возвращать конкретный тип вместо общего интерфейса - не правильно. Вон сегодня чел в коментариях на хабре жалуется дивану на fat pointer с nil data pointer и валидным vtable pointer https://habrahabr.ru/post/339192/ это потому, что у него не error, а какие-то его собственные типы возвращаются из функции

у человека проблемы с типизрованным nil, вроде как

мьютекc?

var mu = sync.Mutex{} func GetPendingBankTransfers(resp http.ResponseWriter, req *http.Request) { mu.Lock() UPDATE mu.Unlock() } Так верно?

mu.Lock() defer mu.Unlock() UPDATE

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

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

Да или нет? :D

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

fatal error: sync: unlock of unlocked mutex fatal error: sync: inconsistent mutex state