🔥 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.

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

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

Вышел Go 1.24 (интерактивные примеры тут)

Производительность

Снижение нагрузки на CPU на 2-3% благодаря:
- Новой реализации встроенных map на основе Swiss Tables
- Более эффективному выделению памяти для малых объектов
- Новой внутренней реализации mutex в runtime

Обобщенные псевдонимы типов

Теперь можно создавать параметризованные псевдонимы типов, например:

type Set[T comparable] = map[T]bool

Слабые указатели

Добавлен новый пакет weak, который предоставляет weak pointers – указатели, которые не препятствуют сборке мусора. Это полезно для реализации кэшей и других структур данных, где нужно избежать утечек памяти.

Улучшенные финализаторы

Представлена новая функция runtime.AddCleanup, которая является более гибкой и эффективной альтернативой runtime.SetFinalizer. Она позволяет:

- Прикреплять несколько функций очистки к одному объекту
- Работать с внутренними указателями
- Избегать утечек памяти при циклических ссылках

Ограниченный доступ к файловой системе

Новый тип os.Root позволяет ограничить файловые операции определенной директорией, что полезно для безопасной работы с файлами.

// Пример использования os.Root
root, err := os.OpenRoot("/path/to/dir")
if err != nil {
    log.Fatal(err)
}

// Операции ограничены директорией
f, err := root.Open("file.txt")
if err != nil {
    log.Fatal(err)
}

Улучшения для тестирования

Добавлен метод testing.B.Loop, который предоставляет более простой и надежный способ написания бенчмарков:

func BenchmarkMyFunc(b *testing.B) {
    // Вместо for i := 0; i < b.N; i++
    for b.Loop() {
        // код бенчмарка
    }
}

Новый пакет testing/synctest позволяет тестировать код с временными операциями, используя синтетические часы вместо реального времени.


Криптография

Добавлены новые криптографические пакеты:

crypto/sha3 - реализация SHA-3
crypto/hkdf - реализация HKDF
crypto/pbkdf2 - реализация PBKDF2


Работа с JSON

Добавлена новая опция omitzero для тегов структур, которая позволяет пропускать нулевые значения при сериализации в JSON. В отличие от omitempty, она работает корректно с time.Time и другими типами, имеющими метод IsZero().
Инструментарий
Go модули теперь могут отслеживать зависимости от исполняемых файлов с помощью директив tool в go.mod. Команды go build, go install и go test получили флаг -json для вывода результатов в формате JSON.

@crossjoin

Lazygit - простой консольный UI для git-комманд, написанный на Go

https://github.com/jesseduffield/lazygit

Да-да, в очередной раз я признаюсь в любви утилитам с минималистичным консольным (графическим) интерфейсом.

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

Но вообще, при работе с гитом, мне нравится гибридный вариант - сложные действия выполняю в хорошем GUI интерфейсе, а более простые текстом в терминале (особенно удобно с плагином oh my zsh).

#repo #terminal_ui

Тестирование конкурентного кода с помощью testing/synctest

https://go.dev/blog/synctest

Damien Neil из Go team рассказал про новый (экспериментальный) пакет testing/synctest для тестирования конкурентного кода, который доступе с версии Go 1.24

Экспериментальный — значит, он доступен только при GOEXPERIMENT=synctest

В чём суть:
Вместо ненадёжных sleep'ов и таймаутов для проверки асинхронных операций, пакет предлагает детерминированный подход. Весь тестируемый код выполняется в изолированном окружении - bubble. В этом окружении время виртуальное и продвигается только когда все горутины заблокированы. То есть, мы точно знаем, когда все горутины достигли точки блокировки с помощью Wait()

Никаких больше фейковых часов и моков time.Now() - всё работает из коробки.

При этом, у пакета всего два метода: synctest.Run() и synctest.Wait()

Пример до:

// Классический подход с time.Sleep
func TestAfterFunc(t *testing.T) {
    calledCh := make(chan struct{})
    context.AfterFunc(ctx, func() {
        close(calledCh)
    })

    // Ждем и надеемся...
    time.Sleep(10 * time.Millisecond)
    if called {
        t.Fatal("called too early")
    }
}

После:

// С synctest - детерминированно и без слипов
func TestAfterFunc(t *testing.T) {
    synctest.Run(func() {
        funcCalled := false
        context.AfterFunc(ctx, func() {
            funcCalled = true
        })

        synctest.Wait() 
        if funcCalled {
            t.Fatal("called too early")
        }
    })
}

#go_official #go_experimental