Паттерны многопоточности в Go

https://habr.com/ru/articles/852556/

Ещё одна хорошая статья от того же автора. Хорошая тема — одно дело понимать, как работают горутины, другое — уметь ими правильно пользоваться в разных ситуациях. Благо, за нас уже придумали хорошие решения различных типовых задач и оформили это в виде паттернов. И эта статья — очень неплохой способ с ними познакомиться.

————
UPD: автор статьи здесь также присутствует, можете обращаться к нему в комментариях к этому посту:

Если есть еще какие-то паттерны о которых я забыл, напишите. Дополню статью

#article

GO Scheduler: теперь не кооперативный?

https://habr.com/ru/articles/502506/

Да, это довольно старая статья, которая описывает изменения в работе планировщика Go в версии 1.14, которые касались вытеснения горутин.

Статья довольно сложная, но полезная. Поможет лучше осознать, что же там такого интересно произошло в 1.14

Если очень кратко:

Раньше горутину могла прервать только она сама, снаружи можно было лишь поставить флаг о желании её прервать, но проверяла его она сама. Из-за довольно легко можно было написать код, из-за которого горутина никогда не будет вытеснена, а это может привести к дедлоку программы.

В версии же 1.14 появился механизм, который позволяет прерывать такие вот жадные горутины с помощью сигнала SIGURG. Теперь если горутина работает более 10мс, планировщик может легко её прервать.

————

Но в статье это разобрано НАМНОГО подробней, мягко говоря. Настолько хорошего разбора я пока нигде не встречал.

Ranging over functions in Go 1.23

https://eli.thegreenplace.net/2024/ranging-over-functions-in-go-123/

Ещё один неплохой пост про range по функциям, который ввели в Go v1.23: что это и как пользоваться.

#go_1_23

🔥 weak: new package providing weak pointers 🔥

Соскучались по интересным изменениям? Их есть у меня!

Начиная с Go 1.24 у нас появится пакет который даст там т.н. "слабые указатели". Суть этих указателей заключается в том, что сборщик мусора вправе в любой момент времени собрать данные на которые они указывают. Т.е. сделать их указатели невалидными.

Простой пример кода:

weakPtr := weak.Make(&SomeStruct{someData})
runtime.GC()
println(weakPtr.Pointer() == nil) // может быть true, а может и false

На самом деле эти указатели появились еще с приходом пакета unique о котором я писал ранее. Но затащить два пакета в рамках одного proposal'а нельзя, поэтому пришлось ждать Go 1.24. Go Core Team (и в особенности Расс Кокс) очень долго сопротивлялись добавлению этого вида указателей в язык, т.н. они ломают абстракцию со сборщиком мусора и имеют очень неочевидные механики взаимодействия с finalizers. Однако после добавление пакета unique отрицать необходимость (хоть и редкую) такой вещи стало невозможно, поэтому было принято решение дать ее использовать всем.

Основной плюс этого пакета в том, что разработчикам кешей стало намного легче собирать мусор. Даже человек, который слабо помнит алгоритмы, теперь может реализовать LRU кеши элементарно на мапах. Как именно? А вот это я покажу в сообщении о следующем за этим изменении.

Как писать качественные unit-тесты

https://habr.com/ru/articles/854546/

Немного про unit-тесты и как их прокачать: что такое мутационные тесты и зачем они нужны, что такое стабы и моки, в чем опасность использования моков и др.

Если вы уже умеете писать unit-тесты, но дальнейшие шаги пока не делали, статья вам будет полезна.

Развлекаемся с итераторами в Go

Перевод и оригинал

Очередной пост про итераторы в Go. Не воспринимайте его как руководство к действию, такого посыла там и нет. Скорее как повод порассуждать.

В чём суть. Автор недоволен громоздкими конструкциями по типу:

// В пакете slices нет функций Map, Filter или ForEach
// Это просто пример
slices.ForEach(
    slices.Filter(
        slices.Map(
            slices.Reverse(slices.All([]int{1,2,3,4})), 
            func(i int) int { return i * i},
        ),
        func(i int) bool { return i % 2 == 0 }
    ),
    func(i int) { fmt.Println(i) }
)

И хочет сделать как в JS:

From([]int{1,2,3,4}).
    Reverse().
    Map(func(i int) int { return i * i }).
    Filter(func(i int) bool { return i%2 == 0 })

Поэтому он реализовал методы: From (создание итератора), Collect (сбор в слайс), Each (обход), Reverse (разворот), Map (преобразование) и Filter.

Получается, конечно, красиво, но автор сам же признаёт:

я понимаю почему команда Go реализовала итераторы по другому

А я напомню, что желание красоты, без учёта других потребностей, когда-то привело людей к CoffeeScript.

#iterators #go_1_23

Автоматизация напоминаний клиентам

https://habr.com/ru/companies/exolve/articles/861346/

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

В чём суть: клиент соглашается на что-то во время разговора, и через месяц автоматически получает SMS-напоминание.

Технически это реализовано через связку звонка и транскрибации (Exolve API), анализа текста, планирования и отправки SMS. Всё на Go + SQLite.

————

Теперь позволю себе немного покритиковать текст:

1) При поиске согласия не учитывается контекст: просто ищутся слова "да", "согласен", "конечно" где угодно в тексте. Но диалог может быть таким:

- Вам интересно?
- Да, но сейчас не готов
Или:
- Раньше было да, а сейчас нет

И система посчитает это за согласие

2) Отправка SMS планируется в памяти, с помощью time.AfterFunc: если сервис перезапустится, все запланированные сообщения пропадут.
Нужно хранить задачи на отправку (не только общую инфу) в базе и использовать какой-то планировщик.

3) Отсутствие учёта часовых поясов: SMS отправляются ровно через месяц без учёта времени клиента. Можно разбудить человека в 3 часа ночи.

Также стоило бы написать пару слов по поводу аутентификации веб-хука.

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

#automation #sqlite

Интересное из комментов

Как пишет nuklearlord, это не первая попытка создать event-driven сетевую библиотеку для Go, предлагая альтернативу стандартному подходу "One Conn One Goroutine":

- evio first commit - Jul 4, 2017
- gnet first commit - Sep 7, 2019
- cloudwego/netpoll first commit - Feb 25, 2021

nuklearlord:

Между тем ключевой вопрос - как прикрутить TLS, не могут решить годами (в том числе потому, что стек TLS в Go нужно переписывать под асинхрон):

https://github.com/tidwall/evio/issues/28 "TLS support ?" - Nov 13, 2018

https://github.com/panjf2000/gnet/issues/16 "TLS support ?" - Sep 24, 2019

И без вот этого TLS не получится написать высокопроизводительные аналоги nginx или unbound... И про "focus on scenarios like Redis, HAProxy" тоже самое, TLS там же тоже не нужен...

И интересный комментарий от Алексея Акуловича:

AterCattus:

У меня тоже в 2017 была первая попытка (весьма успешная) самописной оберки поверх epool, ибо встренное ну никуда не годилось. Потом еще несколько реинкарнаций.

Но в наше время как раз таки сменился фокус на grpc, ибо по работе примерно все общение сервисов на нем, а реализация в google.golang.org/grpc отвратительна по эффективности (на GoFunc рассказывал подробности и что можно сделать).

P.S. У Go несколько лет назад (сейчас, емнип, уже исправили) при работе http2 на каждое соединение уходило по три горутины. Весело было, когда нужно хотя бы 100к коннектов держать.

————

Также если вам интересна эта тема, стоит обратить внимание на доклад Алексея Акуловича на GopherCon Russia 2018 про ускорение TCP путём избавления от слоёв абстракций в stdlib Go. Там не было готовой либы, только примеры в репе, но объяснялось где и на чем теряем, и какие альтернативы.

#networking #performance #netpoll

🎉 Вышел Go 1.24! 🎉

Этот момент настал.

Ключевые нововведения:
— Дженерики теперь умеют в псевдонимы (aliases) т.е. теперь можно писать так

type MyType[T any] = myType[T,*T] 

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

— Теперь можно отслеживать версии и использовать утилиты прямо с помощью команды go tool. Краткий смысл сего: оно помещает все зависимости добавляемой тулзы в require блок, а саму утилиту в блок tool. Учтите, что если вы не указываете отдельный go.mod файл с помощью флага -modfile (его принимают большинство команд) то зависимости внешней тулзы перемешаются с вашими. Однако есть и хорошая новость — из-за умного механизма «вычистки» MVS если кто то импортирует ваш модуль, то зависимости которые нужны для утилит к нему не попадут.

— go test теперь гоняет go vet с небольшим числом анализаторов перед запуском тестов для поиска распространенных ошибок (в том числе ошибок в оформлении тестов). go vet тоже подтянули, теперь, например, ругается на printf функции где аргумент только строка.

— Бинари запущенные с помощью go run и go tool теперь кешируются внутри внутри билд кэша. Никаких больше пересборок на каждом go run.

— go build и go install научили в json вывод.

— С помощью новой переменной окружения GOAUTH можно определить принцип для авторизации на приватных серверах модулей. Подробности с помощью go help goauth

— go build теперь вставляет в бинарь информацию о версии (наконец-то можно перестать делать это вручную!) с использованием тега и/или хеша коммита вашего гита (или mercurial и прочая).

— Новая реализация map на основе Swiss Tables. Бигтехи ваши вопросы на собесах больше неактуальны 🤡.

— Инлайнинг стал мощнее. Теперь, с большей вероятностью, тело функции которую вы передаете как аргумент будет вставлено в место ее вызова. Делали в основном для итераторов которые уступали по скорости циклам. Вместе с прошлым изменением и прочими изменениями в рантайме дало совокупный буст в 3-5% по производительности.

— Различные улучшения CGO с помощью новых директив.

— Новый способ гонять бенчи for b.Loop() { ... }. Основной плюс (кроме того, что меньше писать) в том, что гонялке бенчмарков больше не нужно вызывать вашу функцию несколько раз, ибо сама найдет нужные параметры во время цикла. А значит дорогие блоки инициализации и удаления по итогу бенча стали дешевле.

— С помощью переменной окружения GOCACHEPROG можно настроить свое утилиту которое будет отвечать за кеширование, вместо стандартного «все на диск в папочку». Пригодиться тем, у кого распределенные билды или много чего собирается в докере. Документация.

— Пакет со слабыми указателями стал доступен всем.

— Подъехала замена финалайзерам. С типобезопастностью и сигнатурой которая намекает как делать правильно (и длинной докой объясняющей все сценарии). А еще их можно повесить сколько угодно в отличии от финалайзеров. Почему это важно я писал ранее.

— Пакет testing/synctest который в будущем позволит нам полностью дропнуть все моки времени. Пока обещают изменения API поэтому скрыто за флагом GOEXPERIMENT=synctest

— Появился OpenRoot. TLDR: открыв каталог таким образом из него нельзя убежать используя симлинки и прочая. Штука интересная для тех у кого пути до файлов генерируются извне.

— Куча прочих улучшений, включая новый функции для итераторов в пакеты bytes и strings.

— У тестов и бенчей появился свой контекст! Можно будет дропнуть кучу кода отвечающего за создание контекстов в тестах.

Полное описание (жирного) релиза вот тут.