Код конечно слабенький (человек не понимает ООП в 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, чем довериться постороннему человеку, который не разбирается.
Хах, вот откуда шквал вакансий для бэка. Рекрутёры прям очень бойко постят, им попускают из-за положительной репутации Авито как работодателя, видимо, зря.
На Java писали или на C# ? Горутины ничего общего не имеют с паттернами многопоточки из языков с серьёзными тредами. Пока горутин меньше 100000 - просто запускайте ещё одну, главное убедитесь, что она завершится так, как ожидается. Если горутин меньше 1000000, это всё ещё окей, но надо иметь в виду нагрузку на железо. Горутины и каналы нужны не для того, чтобы очевидно тяжёлое или медленное считать в несколько потоков, а для того чтобы максимально использовать то, что во всех(!) современных процессорах больше 1 ядра и самое главное - делать это легко! Все (почти) части программы исполняются на максимуме ядер, даже места, которые кажутся простыми и быстрыми, но на практике бывают бутылочным горлышком. Рантайм Go сам создаст столько серьёзных потоков в ОС, сколько имеет смысла, а ваш расчёт не учитывает того, что main - отдельная горутина и многие библиотеки активно используют многопоточность под капотом (но это окей, как я уже говорил).
Последние 8 релизов были отличными, но именно этот какой-то глючный: куча жалоб в соответствующем сабреддите (преимущественно на ноутбучное железо, которое работало в 38, а в 39 нет), подождём ещё месяц А вот про это не понял: "включено аппаратное ускорение видео" (где? какое? разве оно не работало везде 100 лет? - цитата из блока про Гном).
macOS - это просто винда, сделанная правильно (но со своими проблемами). Процессоры Apple - это искусство. Другой ноут (Lenovo с ryzen 5800u) у меня уже есть, но m1-m2-m3 это мобильные процессоры с соответствующим потреблением, при этом их производительность сопоставима с настольными. Какой любой другой ноут это предоставит? Нет таких.
Почему бы ей так делать? Это специальный хак внутри драйвера для компенсации проблемного железа. Для другого диска он не нужен, да и macOS я использовать не собираюсь - Linux уже сносно работает, а через год-два вообще будет норм.
Нет ссылки под рукой, но героические транс-женщины, которые портируют Linux на железо Apple, выяснили, что macOS не делает fsync, и врёт, что сделала. Если же писать на диск как положено, без хитрых хаков в драйверах, производительность в некоторые моменты встаёт на колени.
А есть ли шансы на какой-то девайс, где apple silicon, но флеш не распаян? Хочу с нормальным nvme комп (wd black или лучше), а не той ерундой, что в предыдущих маках.
Спасибо за перевод. Статья слабовата: автор явно писал на другом ЯП и тащит оттуда плохое, но до некоторых важных моментов (сделать сервис структурой интерфейсов и собрать их в main например) автор уже догадался. Осталось разобраться с неймингом (сейчас с ним швах) и структурой пакетов (на самом деле в 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, чем довериться постороннему человеку, который не разбирается.
Пример некорректный: стринг билдер должен быть быстрее конкатенации т.к. он специально заточен и официально рекомендован на перфу, а конкатенация нет.
Хах, вот откуда шквал вакансий для бэка. Рекрутёры прям очень бойко постят, им попускают из-за положительной репутации Авито как работодателя, видимо, зря.
На Java писали или на C# ? Горутины ничего общего не имеют с паттернами многопоточки из языков с серьёзными тредами. Пока горутин меньше 100000 - просто запускайте ещё одну, главное убедитесь, что она завершится так, как ожидается. Если горутин меньше 1000000, это всё ещё окей, но надо иметь в виду нагрузку на железо. Горутины и каналы нужны не для того, чтобы очевидно тяжёлое или медленное считать в несколько потоков, а для того чтобы максимально использовать то, что во всех(!) современных процессорах больше 1 ядра и самое главное - делать это легко! Все (почти) части программы исполняются на максимуме ядер, даже места, которые кажутся простыми и быстрыми, но на практике бывают бутылочным горлышком. Рантайм Go сам создаст столько серьёзных потоков в ОС, сколько имеет смысла, а ваш расчёт не учитывает того, что main - отдельная горутина и многие библиотеки активно используют многопоточность под капотом (но это окей, как я уже говорил).
Последние 8 релизов были отличными, но именно этот какой-то глючный: куча жалоб в соответствующем сабреддите (преимущественно на ноутбучное железо, которое работало в 38, а в 39 нет), подождём ещё месяц А вот про это не понял: "включено аппаратное ускорение видео" (где? какое? разве оно не работало везде 100 лет? - цитата из блока про Гном).
Спасибо за идею! Гигантская тёрка правда мне не очень подходит, но глянуть что к чему всё равно стоит.
Нет, у меня есть парочка, они в другой лиге вообще (на данный момент потери в скорости будут раз в 8, что даже медленнее распаянного флеш от Apple).
macOS - это просто винда, сделанная правильно (но со своими проблемами). Процессоры Apple - это искусство. Другой ноут (Lenovo с ryzen 5800u) у меня уже есть, но m1-m2-m3 это мобильные процессоры с соответствующим потреблением, при этом их производительность сопоставима с настольными. Какой любой другой ноут это предоставит? Нет таких.
Почему бы ей так делать? Это специальный хак внутри драйвера для компенсации проблемного железа. Для другого диска он не нужен, да и macOS я использовать не собираюсь - Linux уже сносно работает, а через год-два вообще будет норм.
Нет ссылки под рукой, но героические транс-женщины, которые портируют Linux на железо Apple, выяснили, что macOS не делает fsync, и врёт, что сделала. Если же писать на диск как положено, без хитрых хаков в драйверах, производительность в некоторые моменты встаёт на колени.
А есть ли шансы на какой-то девайс, где apple silicon, но флеш не распаян? Хочу с нормальным nvme комп (wd black или лучше), а не той ерундой, что в предыдущих маках.
Спасибо за перевод. Статья слабовата: автор явно писал на другом ЯП и тащит оттуда плохое, но до некоторых важных моментов (сделать сервис структурой интерфейсов и собрать их в main например) автор уже догадался. Осталось разобраться с неймингом (сейчас с ним швах) и структурой пакетов (на самом деле в Go это одно и то же) и можно будет пользоваться.