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

господа, вы не поняли о чом там спич. А он о том, что не надо объявлять не используемые интерфейсы. И вовсе не о том, что вы сказали) Если можно вернуть из функции конкретный тип, который удовлетворяет интерфейсу. Это равнозначно тому, чтобы вернуть интерфейс, но код при этом более чистый.

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

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

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

в случае error так и есть - он на обеих сторонах есть: вызывающей и вызываемой

в статье речь о том, что не надо делать что-то типа такого : type MyError interface { Error() string }

ибо не фиг

а надо : type MyError struct { ... } func (x MyError) Error() string { ... }

хм, насколько я понял, в статье как раз говорится возвращаёте конкретные типы, насколько я понимаю, с error вышла путаница, тк это builtin interface, и, поскольку нет консруктора для дефолтной ошибки, они сделали конструктор

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

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

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

?? что ??

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

в каждом пакете можно экспортировать свой объект, тип которого удовлетворяет error. это - best paractices

?? что ??

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

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

конструктор - это не только про ООП, функции-констукторы тоже есть

:)

всё, что сейчас используется для обёртки ошибки, fmt.Errorf, который внутри делает errors.New

https://golang.org/src/fmt/print.go?s=5540:5590#L194

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

и чем же функция конструктор по вашему отличается от обычной функцииии? fmt.Sprintf - это конструктор?

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

есть ещё errors.New, но я ни фига не пойму шо вы хотите доказать

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

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

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

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

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

абсолютно. я так и не понял в чём вы там видите противоречие с рекомендациями по обработке ошибок и использованию error

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

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

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

мьютекc?

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

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

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

можно и так сказать

мьютекc?

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

и ещё три ` в конце

атдуши

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

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

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

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

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

нет разницы, но где захватываешь, там и откладывай освобождение

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

да, для этого он и сделан

Да или нет? :D

Да или нет? :D

https://blog.golang.org/defer-panic-and-recover

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

Есть Если у тебя запаникует функция, то defer выстрелит всё равно

Во, спасибо

Всё таки defer одна из самых крутых штук в go

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

Как так?

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

где-то еще этот лок вызывается

а, точно.

вообще в веб лучше использовать канал, чтобы можно было select с default case, чтобы при повторном вызове говорить, что занято, а не вешать приложение

кстати да, я как раз повесил

а как правильно написать?

делаешь канал с бфуером 1, делаешь селект, с записью в канал и дефолтным кейсом 409 каким-нибудь, 1ый воркер запишет в канал, в конце работы читает из канала, что-нибудь такое

и?

делаешь канал с бфуером 1, делаешь селект, с записью в канал и дефолтным кейсом 409 каким-нибудь, 1ый воркер запишет в канал, в конце работы читает из канала, что-нибудь такое

а зачем каналы если он уже использует лок

это 2 механизма для одного и того же

ну каналы конечно шире гораздо ))

https://github.com/golang/go/wiki/MutexOrChannel

а зачем каналы если он уже использует лок

ну, сейчас у него при обработке http запроса 1ый будет выполнять долгий запрос, остальные будут висеть, потом второй будет выполнять запрос, и т.д., я не думаю, что это нормальное поведение для api

не, как раз именно на этом хэндлере надо сделать именно так.

юзер забирает 1000 записей на обработку. Потом я их помечаю как разданные.

не согласен с автором в этом моменте: Есть соблазн сделать код универсальным func SomeFunc(s []interface{}) { ss := s.([]string) ... } слайс, это по сути структура, тогда и надо пытаться преобразовывать к interface{} вместо s []interface{} тогда надо использовать s interface

Но до того, как я их пометил status='in progress', следующий запрос забирает те же 1000 записей

Но до того, как я их пометил status='in progress', следующий запрос забирает те же 1000 записей

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

не согласен с автором в этом моменте: Есть соблазн сделать код универсальным func SomeFunc(s []interface{}) { ss := s.([]string) ... } слайс, это по сути структура, тогда и надо пытаться преобразовывать к interface{} вместо s []interface{} тогда надо использовать s interface

error processing boilerplate туда же достаточно посмотреть сорсы нджинкса. https://github.com/nginx/nginx/blob/master/src/event/ngx_event_acceptex.c#L119 и увидеть что C спокойно с этим живёт.

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

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

нет разницы, но где захватываешь, там и откладывай освобождение

Зависит от кол-ва loc в теле функции. Не нужно злоупотреблять defer. Это всего лишь шугар.

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

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

он заберет его при следующем запросе

для таких кейсов стоит добавить context запроса

НУ вы видели?

Build desktop applications in Go and HTML #dev #osx https://github.com/alexflint/gallium

...

Т.е. это просто веббраузер ?

Т.е. это просто веббраузер ?

нет, это хромимум. на нём vs code написана

нет, это хромимум. на нём vs code написана

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

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

да, изврат. но работает если долго пороться

или не работает)

даже atom работает) говно то ещё, но некоторые не гнушаются

А кто-то пользуется Atom или VSC для написания го-кода?

я VSC

я пользуюсь vscode для typescript

тут надо спросить, а что еще может быть (не говенный гогленд)

тут надо спросить, а что еще может быть (не говенный гогленд)

gogkand говёный?! лол

gogkand говёный?! лол

давай не будем о религии, ты меня все равно не переубедишь

коллеги

ide-срач забаню сразу

хорошо быть модератором, можно банить все что тебе не нравится

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

хорошо быть модератором, можно банить все что тебе не нравится

и это тоже. но ide-срач совсем бессмысленный в 100% случаев

во время ide-cрачей рождается истина

нет, только килотонны навоза

Позволить человеку назвать гогланг дерьмом? (хотя я согласен, пока он сыроват)

я бы советовал позволить всем все

Позволить человеку назвать гогланг дерьмом? (хотя я согласен, пока он сыроват)

что значит "позволить"?

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

есть готовое расширение с sublime шорткатами

есть готовое расширение с sublime шорткатами

у меня свои, я их из far принес

что значит "позволить"?

это значит пропустить мимо ушей, опасаясь бана)