Вопрос: может кто знает сервис который markdown переводит в понятный телеге формат? Уже несколько раз бьюсь о то, что телега не умеет нормально парсить markdown ссылки, из-за чего приходиться редактировать уже в окне набора сообщений, что очень неудобно. И ведь явно эту проблему как-то решали?

Про итераторы.

Решил снова поиграться с итераторами на довольно простом примере

package main

import (
 "fmt"
 "iter"
 "strconv"
)

func IterSlice[V any](slc []V) iter.Seq[V] {
 return func(yield func(V) bool) {
  for i := range len(slc) {
   if !yield(slc[i]) {
    return
   }
  }
 }
}

func Map[V any, R any](seq iter.Seq[V], fn func(V) R) iter.Seq[R] {
 return func(yield func(R) bool) {
  for v := range seq {
   if !yield(fn(v)) {
    return
   }
  }
 }
}

func Limit[V any](seq iter.Seq[V], limit int) iter.Seq[V] {
 return func(yield func(V) bool) {
  i := 0

  for v := range seq {
   if i >= limit {
    return
   }

   if !yield(v) {
    return
   }

   i++

   if i >= limit {
    return
   }
  }
 }
}

func main() {
 slc := []int{1, 2, 3, 4, 5}

 imulIter := Map(Limit(IterSlice(slc), 3), func(v int) int { return v * 2 })
 strIter := Map(imulIter, func(v int) string { return strconv.Itoa(v) })
 strIter = Map(strIter, func(v string) string { return "Number is " + v })

 for v := range strIter {
  fmt.Println(v)
 }
}

Первое впечатление, это реально круто. На простом коде это скорее ведет к ухудшению восприятия кода, но на больших цепочках вызовов (например те которые берут данные из хранилища) это будет просто палочкой выручалочкой в плане потребления памяти и организации кода.

Однако есть минусы:
– Сильно ощущается отсутствие параметрических методов на типах. Я знаю причины, более того я знаю даже детали этих причин и всю подноготную сложность решения этой проблемы. Но блин, создавать отдельные переменные для вызова Map выглядит, прямо скажем, не очень удобно. А лесенка из скобочек напоминает лисп, но выглядит уродливо.
– Итераторы Seq[V] и Seq2[K,V]. Опять же ощущается отсутствие кортежей на уровне языка, т.к. получается необходимость писать функции для двух типов итераторов: с одиночными значениями и для пар ключ-значения. Про эту проблему знают, но полного решения ее похоже не предвидится. Текущий консенсус в том, что функции нужно написать всего один раз.

В остальном, пока очень доволен. Надо посмотреть на производительность, но в целом это близко к революции которую произвели дженерики два года назад.

Поиграться можно тут https://go.dev/play/p/aDX94GK8rYj?v=gotip

П.С. Библиотеки для работы с итераторами уже тоже начали появляться, например https://github.com/BooleanCat/go-functional/blob/main/v2/iter/count_test.go

⌛ runtime: special case timer channels.

У таймеров в Go есть интересная особенность: если на них не вызвать метод Stop то сборщик мусора не соберет их пока они не закончат свою работу или не будут явно остановлены. И если в случае функции time.After (которая возвращает канал) время сборки мусора отодвигалось до срабатывания таймера, то тикер time.Tick (функция которая тоже возвращает канал) не будет собран сборщиком мусора вообще никогда. Документация, конечно, объясняет эти моменты, но хотелось бы, что-бы рантайм делал свою работу а не оставлял мусор из-за особенностей работы языка. В частности из-за этой особенности time.Tick невозможно было применять в реальных долгоживущих приложениях.

Сейчас корректная работа с таймерами выглядит примерно вот так:

ticker := time.NewTicker(time.Second)
defer ticker.Stop()
for {
    select {
    // some other cases
    // ...
    case t := <-ticker.C:
        fmt.Println("Current time: ", t)
        return
    }
}

Issue которое описывает проблему и потенциальное решение существует уже почти 10 лет. Более того, Расс хотел придумать и внедрить решение еще в Go 1.7. Однако время шло и к проблеме никто не возвращался.

В июле 2023го (спустя почти 9 лет) Расс наконец предложил решение в новом issue. Решение не успевало попасть в Go 1.21, но была надежда, что оно попадет в Go 1.22. Более того, в августе решение было одобрено, а так как PR уже был готов, была мысль, что оно попадет в мастер как можно скорее. Однако время продолжало идти, а PR висел и висел. К своему смущению, я был уверен, что проблема была решена в 1.22.

И вот наконец, момент настал: https://github.com/golang/go/commit/508bb17edd04479622fad263cd702deac1c49157. И даже документация теперь отражает, что вызов Stop на таймерах и тикерах больше не обязателен.

Ну что, как говорится «лучше поздно, чем никогда». Теперь time.Tick можно использовать в горячих местах. Еще одно место для легких правок в 1.23.

П.С. Если вам зачем-то нужно старое поведение, то переменная окружения GODEBUG=asynctimerchan=1 даст вашей программе старый вариант.

Новый материал по обновлениям в стандартной библиотеке (и не только) Go уже в работе.

А пока я его пишу, вот вам небольшая викторина навеянная недавним багом который я искал в проде.

init[1055]: segfault at 40 ip 00000000008ef4f8 sp 000000c000e23500 error 4 in init[400000+245f000] likely on CPU 0 (core 0, socket 0)

Что выведет код:

type MyString string

func (s *MyString) String() string { return "world! " + string(*s) }

func main() {
 var str *MyString

 fmt.Println("Hello", str)
}

Что-бы дать правильный ответ нужно понимать три вещи:

1. Как работает вызов по nil указателю.
2. Как работает семейство fmt.*Print* функций.
3. Какие паники можно ловить через recover.

Во первых вызов по nil указателю это вполне корректный код в отличии от, например, Java или C++. До тех пор пока вы не обращаетесь к данным внутри переменной типа, никаких ограничений язык не накладывает. Этим пользуются например в grpc генераторах для создания типов с цепочками методов — даже если переменная nil она все равно может быть рабочей. Единственное но: это работает только с конкретными типами. Для интерфейсов нужно что-бы переменная-интерфейс знала о том какой у нее тип внутри. Да-да тот самый typed nil про который любят спрашивать на собесах иногда имеет реальную применимость.

Для второго идем читаем документацию https://pkg.go.dev/fmt#hdr-Format_errors где видим:

If an Error or String method triggers a panic when called by a print routine, the fmt package reformats the error message from the panic, decorating it with an indication that it came through the fmt package. For example, if a String method calls panic("bad"), the resulting formatted message will look like

%!s(PANIC=bad)

The %!s just shows the print verb in use when the failure occurred. If the panic is caused by a nil receiver to an Error or String method, however, the output is the undecorated string, "<nil>".

Т.е. в случае паники fmt.Println постарается перехватить ее и вывести, что было внутри паники. Исключением являются попытки разыменования по нулевому указателю, вывод паники которой даст <nil>. Почитать исходники можно тут: https://go.googlesource.com/go/+/refs/tags/go1.22.2/src/fmt/print.go#587

И наконец третье - перехватить через recover можно любую панику кроме паники о одновременном чтения и записи (или одновременной записью из разных горутин) в тип map. Вызов runtime.Goexit() перехватить тоже нельзя, т.к. он не является паникой.

А теперь повысим сложность для тех кому интересно:

Ядро очень чутко относится к процессу с PID 1. Оно и понятно: нет процесса — нет юзерспейса ОС. Segfault который вы видели выше, это как-раз и есть эта самая паника с точки зрения ядра. Которое ее видит и пишет в логи. Отсюда получаем неприятный момент — паника как-бы есть, но видим мы ее только потому-что наш Go процесс служит init процессом. Другая возможность увидеть эту панику это подключится к процессу через дебаггер, но с init процессом это довольно проблематично. А вот тесты в таком сценарии не особо помогают.

Я это к чему: было несколько предложений в трекере про функцию для установки глобального перехватчика на паники. Но Go Core Team с упорством каждый раз отклоняет их с фразой «не нужно, есть recover()». Вроде и да, но вот в таких случаях нас спасает только вывод go tool objdump -S и знание ассемблера. И как улучшить ситуацию я, честно говоря, не знаю.

Тем временем Shieldy обезумел и не пускал никого в обсуждения. Заменен другим ботом, посмотрим как новый работник справится.

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

🛠 runtime/debug: add SetCrashOutput

По следам прошлого бага мне тут подсказали, что в Go 1.23 нам дадут глобальную функцию для обработки паник. Однако есть два но:

1. Функция работает только с теми паниками, которые никто не перехватил используя recover().
2. Функция позволяет выбрать только куда выводить сообщение. А если точнее, в какой файловый дескриптор направить вывод.

Т.е. общая идея данной функции состоит в том, что-бы разработчик мог выбрать куда конкретно он будет писать фатальные паники при схлопывании приложения. В документации есть удобный и показательный пример. А кому интересна внутрянка, то все самое важное происходит вот тут. Число изменений минимальное - Go рантайм уже использует файловый дескриптор когда пишет текст паники, поэтому все, что мы (условно) делаем это атомарно подменяем этот самый дескриптор в функции SetCrashOutput.

Однако для случая выше это бы никак не помогло, т.к. паника уже перехвачена с помощью recover() во внутрянке пакета fmt. Моя идея состояла скорее в глобальном хуке, который позволяет вклиниться в любую панику до ее обработки. Но именно для анализа, а не для остановки или восстановления т.к. для этого уже есть другие механизмы.

П.С. Спасибо Алексею Палажченко за наводку.

🎂 Тем временем Земля сделала полный оборот вокруг Солнца, и мне исполнилось 32.

В этот раз буду предельно краток: я жив, у меня всё хорошо, и этот блог не заброшен. Единственное, чего мне пока очень сильно не хватает, — это времени. Заметок скопилось за три десятка, но оформить их во что-то целостное у меня пока никак не получается. Очень надеюсь, что к релизу Go 1.23, который будет в ближайшие одну-две недели, у меня наконец появится время для оформления небольшого обзора, ибо, кроме итераторов, там есть и другие интересные и приятные вещи.

На этом у меня всё. Увидимся ещё через год в ближайшее время.

🎉 Вышел Go 1.23! 🎉

Ключевые нововведения:
• Итераторы — больше вот тут. TLDR: теперь можно делать range по таким функциям:

func(func() bool)
func(func(K) bool)
func(func(K, V) bool)

• Opt-in телеметрия — опциональный сбор метрик и периодическая отправка их. Детальный док вот тут. TLDR: эта вещь позволяет понять как часто и каким командами пользуются Go разработчики, какие флаги они применяют и как часто люди сталкиваются с ошибками компилятора. Статистика обезличенная, а сам формат полностью в открытом доступе. Важно! Сбор по умолчанию включен, но никуда не отсылает метрики. Включить отправку можно с помощью команды go telemetry on. Выключить полностью можно с помощью команды go telemetry off.
• Директива godebug в go.mod файлах.
• Больше нельзя обратится к неэкспортируемым именам в стандартной библиотеке с помощью //go:linkname (за исключением ряда функций).
• time.Timer и time.Ticker больше не нужно останавливать для того, что-бы сборщик мусора смог их собрать. Во вторых, канал который ассоциирован с этими таймерами теперь небуферизированный и гарантирует, что в канале нет данных после остановки. Другими словами, после остановки time.Timer и time.Ticker больше не требуется пытаться вычитать данные из канала, на случай если таймер уже истек и послал данные в канал. Включается только если go.mod содержит go 1.23.0 и выше. Заметку про это обновление можно прочитать вот тут.
• Пакет unique. Про него тоже писал раньше.
• Много функции для итераторов.

Полное описание релиза вот тут.

✍️ Официальный мануал о том, как создавать и работать с итераторами.

Go Team опубликовали достаточно подробную инструкцию о том, как работать с новыми механизмом range-over-func (range по функциям, итераторы). Запись в блоге достаточно короткая, что ее можно прочитать за бизнес-ланчем. А с ее переводом легко справится тот-же Google Translate, если вы не уверены в своем английском. А для ответа на часто задаваемые вопросы еще есть эта запись.

TL;DR: теперь можно делать так:

sortedKeys := slices.Sorted(maps.Keys(myMap))

Всем привет! Небольшое объявление: 3го октября в 18:30 я буду выступать на митапе Витеха. Подключайтесь онлайн или приходите лично!

А кроме меня там будут:
🔦 Кирилл Кузин
Бросил работу инженера-конструктора, чтобы разрабатывать на Go. Сейчас работает над сервисами и PaaS в Ви.Tech

🔨 Эдгар Сипки
Эксперт в Go с 2018 года. Основатель open-source инструмента EasyP, член ПК GolangConf. Ozon Банк.

🛠 Даниил Подольский
Глава программного комитета GolangConf, активист Go Spb и просто хороший человек. YADRO.

🔩 Алексей Мясников
Руководитель команды в Яндекс — на проекте YDB. В IT с 2006 года. Писал код на более чем 20 языках программирования: больше всего на C++, Java, Go, TypeScript.

🗓 3 октября, 18:30 мск, Четверг
📍Офлайн | 💻 Онлайн

🔧ОГО! Ви.Tech meetup #1

Приходите на первый митап по Go от IT-команды ВсеИнструменты.ру! Обсудим интеграцию gRPC с frontend, замену слайсов итераторами и оптимизацию Go через компилятор. Завершим дискуссией с экспертами и нетворкингом

🔗 Регистрируйтесь по ссылке

Для тех у кого не открывается ссылка сверху, тык сюда.

Репо с сорцами с «лайв кодинга».

crypto/rand: crash process on error reading randomness

Интересное улучшение/изменение которое грядет в Go 1.24: функция Read и переменная Reader в пакете crypto/rand больше никогда не будут возвращать ошибку, несмотря на то, что сигнатура останется прежней. Связано это с тем, что на всех современных операционных системах, функции для получения криптографически случайных данных никогда не возвращают ошибку.

В самой функции, при этом, вставлена паника для проверки того, что контракт исполняется.

net/http: delete inappropriate headers in func Error

Из недавних мелких изменений: начиная с Go 1.23 (и выставленной директиве go 1.23.0 в go.mod) функции ServeContent, ServeFile, and ServeFileFS в случае ошибки удаляют заголовки Cache-Control Content-Encoding, Etag, и Last-Modified. Это стоит учитывать, если у вас есть матрешка вокруг интерфейса ResponseWriter которая, например, сжимает ответ и добавляет заголовок Content-Encoding: gzip.

Старое поведение можно восстановить с помощью директивы GODEBUG=httpservecontentkeepheaders=1.

Изначально планировалось сделать тоже самое для функции http.Error. В последствии от этого отказались, так как это изменение ломало слишком много пользовательского кода.

🔥 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 кеши элементарно на мапах. Как именно? А вот это я покажу в сообщении о следующем за этим изменении.

🧹 runtime: add AddCleanup - типобезопасная альтернатива SetFinalizer

Сейчас для отслеживания настоящего момента удаления объекта из памяти у нас есть одна функция: runtime.SetFinalizer. Она говорит рантайму, что нас (через коллбэк) нужно уведомить о том, что объект был убран из памяти сборщиком мусора. Чаще всего это нужно, чтобы мы не забыли закрыть внешние дескрипторы (файлы/сеть/прочее), ассоциированные с объектом.

Однако у этой функции есть и ряд минусов:
‣ Она не является типобезопасной. Вот вам простой пример кода, который развалится только во время выполнения.
‣ Она допускает "воскрешение мёртвых объектов" (ситуации, когда через финализатор можно вернуть данные по удаляемому указателю обратно к жизни - пример кода). Эту штуку кстати ребята из TailScale использовали в своей либе go4.org/intern. У них еще крутая статья есть.
‣ Нельзя поставить несколько финализаторов на объект. Это здорово мешает, когда есть дополнительные вещи которые мы хотим выполнить при «смерти» объекта, а автор вызываемого кода уже повесил свой финализатор. Обходные пути есть, но у всех них есть свои тонкости.

В качестве решения предложена функция AddCleanup вот с такой сигнатурой:

func AddCleanup[T, S any](ptr *T, cleanup func(S), arg S) Cleanup

type Cleanup struct { ... }

// Stop cancels the cleanup call.
func (c Cleanup) Stop() { ... }

Суть в том, что мы вешаем коллбэк на указатель (ptr), но в сам коллбэк приходит объект (arg) который мы ассоциировали с указателем.

Что это нам дает?
‣ Больше нельзя указать неправильную сигнатуру для коллбэка.
‣ Идет разделение между тем, что мы отслеживаем и тем, что мы получаем в коллбэк при «смерти» отслеживаемого. Более того, сама функция пытается уберечь нас от ситуаций типо arg == ptr (правда, только в рантайме).
‣ Сначала выполняется финализатор (если он есть), а затем выполняется один или более коллбэк который мы повесили с помощью нового механизма.

А ждет нас это счастье в Go 1.24, ведь само изменение уже в мастере.

LRU Cache Example

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

Главное:
‣ Создаем словарь/мапу ключей к слабым указателям.
‣ Удаляем ключ как сработает AddCleanup.

На этом всё - у вас есть минимальный пример самоочищающегося кеша.

🐧 Go 1.24 будет требовать ядро Linux 3.2 и выше.

Небольшая, но важная, заметка. В 2021 году (Go 1.18) минимальным ядром на Linux стала версия 2.6.32. Спустя почти четыре года, нас снова ждет изменение требования: теперь в Go 1.24 минимальную версию ядра поднимут до 3.2. Учтите это при обновлении, если у вас очень старые дистрибутивы на серверах (или у вас зоопарк), а разрабатываете вы на самом новом и крутом.

П.С. Да, я в курсе, что актуальная версия ядра вообще 6.x.y 🙂️️️️️️

Минутка юмора.

Можете отправить это человеку который продолжает вас убежать в том, что ChatGPT скоро заменит всех разработчиков инженеров людей.