malloc() вызывает brk()

DESCRIPTION brk() and sbrk() change the location of the program break, which defines the end of the process's data segment (i.e., the program break is the first location after the end of the uninitialized data segment). Increasing the program break has the effect of allocating memory to the process; decreas‐ ing the break deallocates memory.

если выключить cgo - вообще ничего

helloworld - ничего, во всяком случае в 1.7. но какая-то часть рантайма подтягивает libc

или не рантайма, а пекедж какой-то

И тут этот спамер((

Подскажите роадмап для начинающего голангера)

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

Подскажите роадмап для начинающего голангера)

https://golang.org/doc/ вот тут хороший роадмап

Ну ок, а есть список простых задачек на синтаксис так сказать?

И есть ли какая нить хайповая либа для веба?

У меня - нет, я сам придумываю себе задачи. Можно посмотреть go by example, например. И всякие ресурсы с челленджами, которые поддерживают go. А хайповые либы все на github, зачем об этом тут спрашивать?

У меня - нет, я сам придумываю себе задачи. Можно посмотреть go by example, например. И всякие ресурсы с челленджами, которые поддерживают go. А хайповые либы все на github, зачем об этом тут спрашивать?

Ну вдруг что-то посоветуте исходя из своего опыта

Ну вдруг что-то посоветуте исходя из своего опыта

Всё слижком быстро меняется. Ну а насчет советов... можно посмотреть стандартную библиотеку go, но осторожно потому что там хватает не очень хороших практик в большинстве модулей. Например: - возврат ошибок через error.New() чуть ли не во всей std либе - куча неэкспортированных вещей, которые как бы говорят разработчику "скопипасти меня чтобы кастомизировать или построить сверху что-то своё" - отвратительное именование полей в структурах однобуквенными идентификаторами - использование interface{} там, где этого можно было бы избежать Список можно продолжить не совсем удачными архитектурными решениями. Смотреть можно любой код, но делать вывод о его качестве каждый должен сам для себя

А какая хорошая практика по ошибкам?

malloc() вызывает brk()

Обычно он все-таки вызывает mmap

А какая хорошая практика по ошибкам?

Например такая: var ErrFoo = errors.New("...") func StaticError() error { return ErrFoo } // type ErrKey struct { name string } func (e ErrKey) Error() string { return fmt.Sprintf("Failed on key '%s'", e.name) } func NewErrKey(key string) error { return ErrKey{key} } func DynamicError() error { return NewErrKey("key name") } Преимущество в том что всегда можно проверить, что за ошибка была возвращена, либо сравнением с значением(StaticError), либо сравнением по типу(DynamicError). А подход с return errors.New("ololo") плох тем что оставляет разработчику лишь один способ узнать "что произошло" - сравнить сообщение об ошибке. За такое нужно отрывать руки.

Когда бомбануло :)

Та не, всё впорядке. Только расстройств психики прибавляется потихоньку :)

Обычно разработчику всё равно, что призошло, если понятно, что действие не выполнилось. Файл, например, не переименовался. А вот если важно, что именно случилось - упал коннект в БД или там просто нет записи, то там возвращатся ErrNoRows

Например такая: var ErrFoo = errors.New("...") func StaticError() error { return ErrFoo } // type ErrKey struct { name string } func (e ErrKey) Error() string { return fmt.Sprintf("Failed on key '%s'", e.name) } func NewErrKey(key string) error { return ErrKey{key} } func DynamicError() error { return NewErrKey("key name") } Преимущество в том что всегда можно проверить, что за ошибка была возвращена, либо сравнением с значением(StaticError), либо сравнением по типу(DynamicError). А подход с return errors.New("ololo") плох тем что оставляет разработчику лишь один способ узнать "что произошло" - сравнить сообщение об ошибке. За такое нужно отрывать руки.

Я через fmt.Errorf() ошибку возвращаю, если это просто строка, а не error

Обычно он все-таки вызывает mmap

When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). it depends

Я через fmt.Errorf() ошибку возвращаю, если это просто строка, а не error

На errors.Error() линтер ругается, что "лучше пользуйся fmt"

Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2).

На errors.Error() линтер ругается, что "лучше пользуйся fmt"

У тебя какой-то неправильный линтер, и у него неправильная ругань :)

Обычно разработчику всё равно, что призошло, если понятно, что действие не выполнилось. Файл, например, не переименовался. А вот если важно, что именно случилось - упал коннект в БД или там просто нет записи, то там возвращатся ErrNoRows

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

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

Наверное соглашусь

У тебя какой-то неправильный линтер, и у него неправильная ругань :)

Обычный gometalinter

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

В 90% случаев мне достаточно if err != nil, без всяких проверок на то, что там внутри. Когда надо, можно и со значением сравнить.

Какой именно модуль в нём - не вспомню

Обычный gometalinter

Код в студию, чтоб ругался на errors.New("...")

Код в студию, чтоб ругался на errors.New("...")

Ща

Всё слижком быстро меняется. Ну а насчет советов... можно посмотреть стандартную библиотеку go, но осторожно потому что там хватает не очень хороших практик в большинстве модулей. Например: - возврат ошибок через error.New() чуть ли не во всей std либе - куча неэкспортированных вещей, которые как бы говорят разработчику "скопипасти меня чтобы кастомизировать или построить сверху что-то своё" - отвратительное именование полей в структурах однобуквенными идентификаторами - использование interface{} там, где этого можно было бы избежать Список можно продолжить не совсем удачными архитектурными решениями. Смотреть можно любой код, но делать вывод о его качестве каждый должен сам для себя

Вот это что было сейчас? Напутствие новичку?

Вот это что было сейчас? Напутствие новичку?

Это было моё мнение

Можно считать его напутствием в некотором смысле, которое можно выразить так: "go не очень продуманный язык, так что не ожидай от него слижком многого"

https://play.golang.org/p/igiMJMywN4 я делаю вот такую штуку. она читает построчно файл, потом пропускает строки по цепочке каналов которые их обрабатывают и фильтруют. вопрос в том как корректно завершаться. я чё-то не догоняю

подскажите, люди добрые

Код в студию, чтоб ругался на errors.New("...")

Блин, когда библу писал то была (пускай и не обязательная в исполнении) ругать на "поменяй errors.New() на fmt.Errorf()". Сейчас написав самый простой скрипт с errors не смог это повторить

Блин, когда библу писал то была (пускай и не обязательная в исполнении) ругать на "поменяй errors.New() на fmt.Errorf()". Сейчас написав самый простой скрипт с errors не смог это повторить

у тебя, наверно, было errors.New(fmt.Sprintf("aaa %v", bbb))

у тебя, наверно, было errors.New(fmt.Sprintf("aaa %v", bbb))

Кстати да, возможно. Я уже не помню.

Просто с того раза я только fmt.Errorf() и юзаю, вместо того чтобы ещё один пакет подключать

https://play.golang.org/p/igiMJMywN4 я делаю вот такую штуку. она читает построчно файл, потом пропускает строки по цепочке каналов которые их обрабатывают и фильтруют. вопрос в том как корректно завершаться. я чё-то не догоняю

waitgroup и каналы закрывать

Это если кратко, если долго, то я не объясню

каналы получается закрывать тоже по цепочке через дефер?

https://play.golang.org/p/igiMJMywN4 я делаю вот такую штуку. она читает построчно файл, потом пропускает строки по цепочке каналов которые их обрабатывают и фильтруют. вопрос в том как корректно завершаться. я чё-то не догоняю

ну нет..

у тебя, наверно, было errors.New(fmt.Sprintf("aaa %v", bbb))

Да, ты прав - поймал: main.go:10:12:warning: should replace errors.New(fmt.Sprintf(...)) with fmt.Errorf(...) (golint) https://play.golang.org/p/uFFjBmSSqx

каналы получается закрывать тоже по цепочке через дефер?

хотя почти.. тебе нужен еще один chan bool на закрытие этой горутины

for scanner.Scan() { s := scanner.Text() string_chan <- s } Вот тут делать close(string_chan) Потом внутри стринг процессора, если канал закрыт - то закрывать выходной. И так далее.

А main должна ждать wg.Wait()

ну лучше сделать дефер который всё закроет

ну лучше сделать дефер который всё закроет

Где?

а не будут эти проверки на не закрыт ли канал на каждом чтении тормозить все? или они очень дешёвые?

а не будут эти проверки на не закрыт ли канал на каждом чтении тормозить все? или они очень дешёвые?

Они не на каждом чтении

Где?

смотри.. мне кажется можно в принципе сделать проще

и не париться с этими каналами

короче надо почитать про закрытие каналов

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

почему нельзя делать асинхронно и только через последний канал принимать результат

я просто в принципе не понимаю зачем здесь столько каналов

короче надо почитать про закрытие каналов

Там надо не проверять, там надо писать просто в твоих процессорах for incomingString := range incomingChannel { outputString := process(incomingString) outputChannel <- outputString } close(outputChannel) ```wg.Done

я просто в принципе не понимаю зачем здесь столько каналов

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

ERROR: S client not available

я просто упростил для примера кода чтоб не тащить все

так я же не про это

горутины это очень легковесные операции

Ну вот range читает из канала, а когда канал закрывают - то он выходит из цикла.

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

Там надо не проверять, там надо писать просто в твоих процессорах for incomingString := range incomingChannel { outputString := process(incomingString) outputChannel <- outputString } close(outputChannel) ```wg.Done

спасибо

а можешь без них просто фигачить горутины и их результат складывать в один канал

но для твоего случая можно сделать так

при выходе из цикла чтения файла - отправляешь в горутину в chan done bool <- true и по этому каналу вызываешь её закрытие

а можешь без них просто фигачить горутины и их результат складывать в один канал

я готов пожертвовать вероятностью гонок в угоду удобству сборки разных конструкций из обработчиков

при выходе из цикла чтения файла - отправляешь в горутину в chan done bool <- true и по этому каналу вызываешь её закрытие

естессно перед этим отправив этот сигнал дальше по цепочке

при выходе из цикла чтения файла - отправляешь в горутину в chan done bool <- true и по этому каналу вызываешь её закрытие

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

а ты посмотри библиотеки

работающие например с сокетами

или какие нибудь rpc

там специально делают done

что бы при каждом чихе не проверять открыт канал или нет

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

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

ну если через range его читать

хз, эту штуку не приходилось использовать..

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

На вход закроется сразу, на выход - когда опустошится.

На вход закроется сразу, на выход - когда опустошится.

спасибо )

короче спасибо

Я не знаю, может, с горутинами, switch'ами и <- done лучше, там надо всю задачу целиком смотреть, а мне неинтересно?

вроде работает тестик

счас все перепилю

Я не знаю, может, с горутинами, switch'ами и <- done лучше, там надо всю задачу целиком смотреть, а мне неинтересно?

тут пока целиком картину не увидишь - точно никогда не узнаешь ) но твой вариант с range выглядит красивым (с учетом небольших объемов)

А главное модульным