Строго говоря оба параметра vm.dirty* непоняты и неверно поданы. Первый "vm.dirty_expire_centisecs" ничего не сбрасывает. Он только помечает данные к сбросу (как устаревшие). Периодически флашер (он работает параллельно) проверяет, какие данные помечены устаревшими и сбрасывает их на диск. У него своя настройка периодичности "vm.dirty_writeback_centisecs". Из коробки 5 секунд, но можно и час поставить. Тогда данные будут сбрасываться каждый час, а не когда там "vm.dirty_expire_centisecs" что-то пометил. Второй "vm.dirty_ratio" вообще с флашем не связан. Он определяет максимальный размер буфера. Когда мы добираемся до него - запись становится синхронной постоянно блокируясь пока диск что-то пишет. Флашинг начинается сильно раньше этого и его контролирует "vm.dirty_background_ratio". И он не может быть больше половины "vm.dirty_ratio". Т.е. флашинг начинается не тогда, когды мы вбрали весь буфер, а сильно заранее, где-то при заполнении на половину или даже ещё раньше.
Коллега ниже верно подметил, комменты актуализируются с другой скоростью относительно кода. Иными словами, я могу понять любой Go-код кроме того, в котором комментарий вводит в заблуждение.
Ничего маргинального в понимании ненужности комментариев в Go нет. Роб Пайк много лет на своих лекциях повторяет: "Комментарий никогда не должен отвечать, "что?" делает код. Если вам приходится писать такой комментарий - код плох и его надо переписать. Комментарий может отвечать только на вопрос "почему?" т.е. иногда нужно указать причину того, что код делает именно это (совместимость с каким-то хитрым API или легаси, неочевидные особенности работы железа, хитрая оптимизация и т.д.)". Отсюда и вытекает упомянутый идеоматичный нейминг (e.g. namespace.New), код сам описывает что делает.
На первый взгляд логично и обосновано, но только на первый. Если внимательно посмотреть на рынок вакансий, то видно, что спрос на middle+/senior огромный, а на jun/jun+ его нет вообще. У этого могут быть разные причины, но я почти уверен, основная - "набрали с софтскилами, а инженерные задачи решать некому", вот и бегают, ищут профи.
Долина Кремниевая, там полупроводники производят (они являются по сути кусками кремния). Если безграмотным англоязычным ещё можно простить (у них эти 2 слова отличаются всего на 1 букву при написании, и ещё меньше при произношении), то на русскоязычном ресурсе - нет 🤷♂️
Т.е. променяют родную, понятную и прозрачную юрисдикцию и премиальный рынок на сотрудничество с полубезумными царьками из диких нищих бантустанов? Это же гарантированое разорение уже в среднесрочной перспективе. И эти ребята прекрасно всё просчитали, потому и не делают такое.
Это то, как мы в Go делаем decoupling. Есть конечно те, кто по привычке с условных шарпов делают инстанс интерфейса и таскают его туда-сюда, но они обычно профнепригодны.
Хороший пример в стдлиб bufio.Scanner (https://pkg.go.dev/bufio#NewScanner). Конструктор принимает reader, и сканер может работать хоть поверх файла, хоть поверх stdout, хоть поверх http request body, да хоть поверх обычной строки, из которой можно сделать reader с помощью пакета strings.
В итоге мы никак не зависим от конкретной реализации reader и буквально можем переехать на другой 1-2 строками кода. Это правило работает и с бизнес-кодом. Хотим сменить логгер или базу на другую? - Отлично, меняем строку импорта на другую реализацию + меняем строку инициализации логгера или базы и передаём уже другую реализацию интерфейса в конструктор. Кто-то скажет DI для бедных. Так и есть 😄
Боюсь, всё немного сложнее. Вообще, 40 часов в неделю откуда взялись? От монотонной, простой (относительно), нетворческой смены рабочего на заводе. Нам, программистам, особенно тем, кто что-то серьёзное делает положено по 4 часа в день работать. Многие, кстати, так и делают, а остальные 4 часа "работают". И да, я понимаю, что после смены на заводе руки и ноги отваливаются. Но тело восстанавливается за ночь, а ум - скорее нет, чем да. Отсюда и выгорания.
Вы посмотрели кто авторы Go? Если Роб Пайк и Кен Томпсон не умеют « в разработку языка» , то может подскажете кто умеет?
Я нигде этого не писал, совсем. "Достижения" в моём сообщении потому и в кавычках, что я их таковыми не считаю (как и Пайк, чьи статьи и книжки я читал ещё для Си, который он предпочитал в эпоху до Go). Вы не в ту сторону тут воюете.
Зачем вам интерфейсы в HTTP сервисе, в части которая отвечает за обработку запросов?
Я нигде этого не писал, совсем. Они не нужны в обработке запросов, они нужны в конструкторе сервиса.
У вас точно в фильтре стоит "показывать статьи с рейтингом -50"?) Не думаю, что он будет выше. Аргументы в духе "так написан net/http и он работает хорошо (в общем случае)", "любой кусок легко протестировать", "мы ни разу не теряем информацию о типе (типобезопасность)" никогда не помогают, и меня всегда сливают. Дело в отношении к привычным паттернам и анти-паттернам, первые считаются обязательными априори (но неприменимы к Go), а вторые порой применять надо (хоть и осторожно). Это связано с тем, что авторы по сути наплевали на десятилетия развития ЯП и "переизобрели" что-то заново, откинув многие "достижения" (например исключения и наследование, которое сильно повлияло на полиморфизм, а значит и на внутреннее устройство типов).
Код конечно слабенький (человек не понимает ООП в Go, не использует интерфейсы почти нигде), но это гораздо, гораздо лучше обычного "давайте писать на Go как на жалком подобии Java с кучей пустых интерфейсов и фабрик фабрик".
тож хейчу сторис, но грустная правда в том, что банки уже давно не банки, а сборщики биг-дата для впаривания всего сразу: поэтому Сбер стал озоном, билайном и пикпоинтом одновременно - чтобы всё про нас знать, а сторис нужны для впаривания того, что они думают, нам нужно
А почему? Пять последних видюх для PC покупал от AMD. Ноут специально покупал на базе Ryzen 5800u без внешней видюхи. На обоих компах только Fedora, работает идеально.
Спасибо за статью. Небольшой тип по перфе: Go не буферизует IO (т.е. дорогой сискол дёргается на каждый байт, при этом как минимум Linux не может записать меньше 4кб за раз), так что при работе с os.Stdin и os.Stderr надо оборачивать их в bufio и не забыть defer с flush в случае с записью.
Да никак конечно, ерунда написана. Люди любят потереть за горутины и каналы (особенно на собесах), но на практике их по назначению (передача значений, а не сигнализации) почти никто не использует. Идея по сути простая: та горутина, которая пишет в канал, отрабатывает полностью (записывает всё, что у неё было) и закрывает канал. Всё, никаких проверок. Если есть fan-out (горутина, которая порождает горутины, записывающие в канал), то это она следит за тем, чтобы все порождённые горутины успели записать или, ещё лучше, переиспользуем этот канал всё время жизни программы и не закрываем его никогда. От утечки одного канала (в отличии от паники посреди работы) ничего страшного не будет.
Да всем плоха. Bloated, opinionated - вы платите ценой диких тормозов (оно в десятки раз тормознее zsh со своим конфигом) за функционал 90%+ которого вы скорее всего не используете. Лучше потратить один раз несколько часов на ручную настройку zsh, чем довериться постороннему человеку, который не разбирается.
Строго говоря оба параметра vm.dirty* непоняты и неверно поданы. Первый "vm.dirty_expire_centisecs" ничего не сбрасывает. Он только помечает данные к сбросу (как устаревшие). Периодически флашер (он работает параллельно) проверяет, какие данные помечены устаревшими и сбрасывает их на диск. У него своя настройка периодичности "vm.dirty_writeback_centisecs". Из коробки 5 секунд, но можно и час поставить. Тогда данные будут сбрасываться каждый час, а не когда там "vm.dirty_expire_centisecs" что-то пометил. Второй "vm.dirty_ratio" вообще с флашем не связан. Он определяет максимальный размер буфера. Когда мы добираемся до него - запись становится синхронной постоянно блокируясь пока диск что-то пишет. Флашинг начинается сильно раньше этого и его контролирует "vm.dirty_background_ratio". И он не может быть больше половины "vm.dirty_ratio". Т.е. флашинг начинается не тогда, когды мы вбрали весь буфер, а сильно заранее, где-то при заполнении на половину или даже ещё раньше.
Коллега ниже верно подметил, комменты актуализируются с другой скоростью относительно кода. Иными словами, я могу понять любой Go-код кроме того, в котором комментарий вводит в заблуждение.
Спасибо за статью.
Ничего маргинального в понимании ненужности комментариев в Go нет. Роб Пайк много лет на своих лекциях повторяет: "Комментарий никогда не должен отвечать, "что?" делает код. Если вам приходится писать такой комментарий - код плох и его надо переписать. Комментарий может отвечать только на вопрос "почему?" т.е. иногда нужно указать причину того, что код делает именно это (совместимость с каким-то хитрым API или легаси, неочевидные особенности работы железа, хитрая оптимизация и т.д.)". Отсюда и вытекает упомянутый идеоматичный нейминг (e.g. namespace.New), код сам описывает что делает.
На первый взгляд логично и обосновано, но только на первый. Если внимательно посмотреть на рынок вакансий, то видно, что спрос на middle+/senior огромный, а на jun/jun+ его нет вообще. У этого могут быть разные причины, но я почти уверен, основная - "набрали с софтскилами, а инженерные задачи решать некому", вот и бегают, ищут профи.
Долина Кремниевая, там полупроводники производят (они являются по сути кусками кремния). Если безграмотным англоязычным ещё можно простить (у них эти 2 слова отличаются всего на 1 букву при написании, и ещё меньше при произношении), то на русскоязычном ресурсе - нет 🤷♂️
Т.е. променяют родную, понятную и прозрачную юрисдикцию и премиальный рынок на сотрудничество с полубезумными царьками из диких нищих бантустанов? Это же гарантированое разорение уже в среднесрочной перспективе. И эти ребята прекрасно всё просчитали, потому и не делают такое.
Это то, как мы в Go делаем decoupling. Есть конечно те, кто по привычке с условных шарпов делают инстанс интерфейса и таскают его туда-сюда, но они обычно профнепригодны.
Хороший пример в стдлиб bufio.Scanner (https://pkg.go.dev/bufio#NewScanner). Конструктор принимает reader, и сканер может работать хоть поверх файла, хоть поверх stdout, хоть поверх http request body, да хоть поверх обычной строки, из которой можно сделать reader с помощью пакета strings.
В итоге мы никак не зависим от конкретной реализации reader и буквально можем переехать на другой 1-2 строками кода. Это правило работает и с бизнес-кодом. Хотим сменить логгер или базу на другую? - Отлично, меняем строку импорта на другую реализацию + меняем строку инициализации логгера или базы и передаём уже другую реализацию интерфейса в конструктор. Кто-то скажет DI для бедных. Так и есть 😄
Боюсь, всё немного сложнее. Вообще, 40 часов в неделю откуда взялись? От монотонной, простой (относительно), нетворческой смены рабочего на заводе. Нам, программистам, особенно тем, кто что-то серьёзное делает положено по 4 часа в день работать. Многие, кстати, так и делают, а остальные 4 часа "работают". И да, я понимаю, что после смены на заводе руки и ноги отваливаются. Но тело восстанавливается за ночь, а ум - скорее нет, чем да. Отсюда и выгорания.
Я нигде этого не писал, совсем. "Достижения" в моём сообщении потому и в кавычках, что я их таковыми не считаю (как и Пайк, чьи статьи и книжки я читал ещё для Си, который он предпочитал в эпоху до Go). Вы не в ту сторону тут воюете.
Я нигде этого не писал, совсем. Они не нужны в обработке запросов, они нужны в конструкторе сервиса.
У вас точно в фильтре стоит "показывать статьи с рейтингом -50"?) Не думаю, что он будет выше. Аргументы в духе "так написан net/http и он работает хорошо (в общем случае)", "любой кусок легко протестировать", "мы ни разу не теряем информацию о типе (типобезопасность)" никогда не помогают, и меня всегда сливают. Дело в отношении к привычным паттернам и анти-паттернам, первые считаются обязательными априори (но неприменимы к Go), а вторые порой применять надо (хоть и осторожно). Это связано с тем, что авторы по сути наплевали на десятилетия развития ЯП и "переизобрели" что-то заново, откинув многие "достижения" (например исключения и наследование, которое сильно повлияло на полиморфизм, а значит и на внутреннее устройство типов).
Спасибо за перевод.
Код конечно слабенький (человек не понимает ООП в Go, не использует интерфейсы почти нигде), но это гораздо, гораздо лучше обычного "давайте писать на Go как на жалком подобии Java с кучей пустых интерфейсов и фабрик фабрик".
тож хейчу сторис, но грустная правда в том, что банки уже давно не банки, а сборщики биг-дата для впаривания всего сразу: поэтому Сбер стал озоном, билайном и пикпоинтом одновременно - чтобы всё про нас знать, а сторис нужны для впаривания того, что они думают, нам нужно
Вы приблизились к изобретению Go)
А почему? Пять последних видюх для PC покупал от AMD. Ноут специально покупал на базе Ryzen 5800u без внешней видюхи. На обоих компах только Fedora, работает идеально.
Спасибо за статью. Небольшой тип по перфе: Go не буферизует IO (т.е. дорогой сискол дёргается на каждый байт, при этом как минимум Linux не может записать меньше 4кб за раз), так что при работе с os.Stdin и os.Stderr надо оборачивать их в bufio и не забыть defer с flush в случае с записью.
Да никак конечно, ерунда написана. Люди любят потереть за горутины и каналы (особенно на собесах), но на практике их по назначению (передача значений, а не сигнализации) почти никто не использует. Идея по сути простая: та горутина, которая пишет в канал, отрабатывает полностью (записывает всё, что у неё было) и закрывает канал. Всё, никаких проверок. Если есть fan-out (горутина, которая порождает горутины, записывающие в канал), то это она следит за тем, чтобы все порождённые горутины успели записать или, ещё лучше, переиспользуем этот канал всё время жизни программы и не закрываем его никогда. От утечки одного канала (в отличии от паники посреди работы) ничего страшного не будет.
Идеоматичный мьютекс делается так:
mu.lock
defer mu.unlock
<тут операции под мьютексом, он разблокируется при выходе из зоны видимости благодаря defer>
Спасибо за статью.
щутка
Крайней бывает мера, необходимость и плоть, а версия - последняя
Да всем плоха. Bloated, opinionated - вы платите ценой диких тормозов (оно в десятки раз тормознее zsh со своим конфигом) за функционал 90%+ которого вы скорее всего не используете. Лучше потратить один раз несколько часов на ручную настройку zsh, чем довериться постороннему человеку, который не разбирается.
Пример некорректный: стринг билдер должен быть быстрее конкатенации т.к. он специально заточен и официально рекомендован на перфу, а конкатенация нет.