🙄 go4.org/unsafe-assume-no-moving-gc: когда все равны, но некоторые равнее.

В модуле go4.org/unsafe/assume-no-moving-gc есть интересное место. В нём вызывается функция из рантайма Go с помощью go:linkname (управляющая директива в комментариях, которая позволяет вызывать приватные функции и методы из других пакетов) - heapObjectsCanMove. Функция крайне простая - пока GC не двигает объекты в хипе, она возвращает false. Если (когда) начнёт, то будет возвращать true.

Прикол в том, что эта функция появилась специально в Go 1.21 именно для этого модуля. А причина проста: без неё модуль assume-no-moving-gc надо было обновлять с каждой новой версией компилятора Go. Именно этим ребята и оправдывают включение этой приватной функции в пакет runtime.

И всё же приятно, когда твои бывшие коллеги работают над компилятором, который ты используешь в разработке своего продукта 😆.

😂 Вся сиутация как тот мем:

Рядовой разработчик: мне нужна функция которая позволит получить id горутины. Предоставьте такой функционал, пожалуйста.
Go Core Team: 🤨 тебе это не нужно. И вообще во внутрянку лезть не надо.

Разработчики Tailscale: мы тут намутили модуль полностью состоящий из черной магии который понимают десять человек в мире. Сделайте функцию в рантайме быренько, что-бы это все не развалилось на следующем релизе.
Go Core Team: 🫡 Сейчас все будет.

🦎 proposal: slices: have Delete clear the tail

В своем докладе на GolangConf 2023 я буду рассказывать про эволюцию Go, в том числе и про новые пакеты в стандартной библиотеке. Изучая один из этих пакетов мне стало интересно, как там реализована функция Delete. А реализация там крайне простая:

func Delete[S ~[]E, E any](s S, i, j int) S {
 _ = s[i:j] // bounds check

 return append(s[:i], s[j:]...)
}

И вроде бы все верно, так? Даже те из вас, кто давно работают с Go скорее всего не смогут сходу сказать, что тут не так. Признаюсь, я к пониманию глубины проблемы пришел только в рамках подготовки самих слайдов.

Допустим у нас есть такой код:

 var slc []*int64
 for i := 0; i < 10_000_000; i++ {
  val := i
  slc = append(slc, &val)
 }

 slc = slices.Delete(slc, 1, 10_000_000)

 runtime.GC()

 // Report memory metrics
 var m runtime.MemStats
 runtime.ReadMemStats(&m)
 fmt.Printf("Alloc = %v MiB\n", m.Alloc / 1024 / 1024)

Первичный анализ подсказывает, что после вызова GC у нас должен остаться в памяти слайс на 10 миллионов указателей и на один int. Ну т.е. программа в памяти будет занимать от 80 до 90 МБ на amd64.

Пробуем запустить и получаем вывод:

Alloc = 170 MiB

Наш анализ некорректен: в Go сборщик мусора не собирает память на которую есть указатели в активной памяти, даже если эти указатели находятся за пределами длинны слайса. Причина простая: никто не мешает вам сделать от слайса выше новый слайс с длинной 3 и тем самым восстановить указатель на 3ий элемент.

Интересно то, что этой проблемой озаботились не в Go Core Team, а простой Go разработчик-город-Тверь из Франции. Такую же проблему содержат и другие функции: DeleteFunc, Compact, CompactFunc и Replace.

При этом сам issue есть эталон того как это правильно делать: там и лаконичная мысль, разбитая на параграфы, и картинки которые круто визуализируют проблему, и разные варианты решений. В общем понравилось не только мне - Расс тоже оценил. А решение выбрал максимально простое: будем занулять элементы которые выкинули, благо у нас теперь есть встроенная функция clear.

Текущий статус: likely accept. А это значит, что пока есть все шансы, что мы увидим сие в 1.22.

❄️ runtime/secret: add new package: о тех кто застрял в лимбе.

Как часто вы зануляете память? Подозреваю, что ответ большинства Go разработчиков будет где-то между "никогда" и "зачем?". И действительно, в большинстве приложений такая задача никогда не появляется. Однако когда речь заходит о криптографии, этот вопрос резко становится важным, так как очистка ключей из памяти есть обязательное условие Perfect forward secrecy (совершенной прямой секретности).

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

Джейсон Доненфельд (автор протокола WireGuard VPN и его реализации, как минимум, на C и Go) поднял эту проблему и вариант решения еще в 2017ом году, однако на обсуждение деталей ушло аж 4 года, перед принятием предложения в октябре 2021го. Само обсуждение интересно тем, что в нем не раз и не два поднимается вопрос об особенностях зачистки памяти в языках со автоматической сборкой мусора и количестве изменений которые необходимо сделать в рантайм для поддержки подобного.

Тем временем, на дворе ноябрь 2023го. И с момента принятия предложения по нему не было никакой работы. Такое впечатление, что про само предложение забыли, либо сложность его реализации перекрывает любые бенефиты. Однако отозвать предложение тоже нельзя, ибо противоречий к его реализации нет. Вот и получается, что вроде и приняли, а реализовывать его никто не хочет (или не может). Застряло в лимбе.

А какие вы знаете предложения которые находятся в похожей ситуации?

🔒proposal: Tuple Types for Go

Я наконец оправился после конференции, а ребята из Go Core Team ненадолго вернулись к обсуждениям после ноябрьских праздников в США, перед тем как снова уйдут уже на рождественский отдых.

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

И тут появляется традиционный вопрос - а зачем? Их много раз предлагали, но каждый раз упирались в вопрос "А чем мало простых структур?". И ведь правда, обычно структур должно хватать за глаза, а там где очень хочется можно притянуть множественный возврат из функции (тоже, кстати, своего рода кортеж). Но сила кортежей не в инновациях, а в облегчении каждодневной разработки. А именно в этих двух вещах:

• Для кортежа не нужно создавать отдельный тип (но можно). Ближайший аналог это анонимная структура, только в случае кортежа не нужно указывать имена полей.

• Для распаковки и упаковки кортежей в несколько переменных в язык добавляются специальные конструкции.

Посмотря на количество предложений, ребята наконец назрели и решили провести эксперимент по итогу которого сделали свое предложение: в их случае синтаксис выглядит как-то так:

val := (1, "foo", false)
x, y, z := val...
fn(val...) // вызываем функцию в которую распаковываем кортеж

func fn(int, string, bool) { ... }

Так-же можно получить конкретный элемент:

val := (1, "foo", false)
x := val.0 // получаем первый элемент

Функции тоже могут возвращать кортежи, но выглядит это немного странно (по причине обратной совместимости):

func f() ((int, int)) {  // обратите внимание на двойные скобки

Однако по мнению Go Core Team это не настолько нужно, чтобы внедрять принципиально новый тип в язык. Поэтому сам proposal это даже не предложение, а скорее заметка о том, какое исследование они провели внутри Google и какие выводы сделали. Выводы кстати простые: делать они эту фичу не будут.

На мой взгляд, здесь они правы, так как для полноценного внедрения кортежей нужно было бы решать вопрос с возвратом функций без этих ужасных двойных скобок. Да и анонимные структуры решают 80% описанных проблем. Однако само исследование породило интересные выводы о том как можно улучшить язык не внедряя новые типы. Об этом мы поговорим в следующий раз.

P.S. И да я очень надеюсь вывести количество заметок хотя-бы до трех в месяц 😆️️️️️️

Немного обновлений тех предложений которые рассмотрены выше:

- slices: have Delete clear the tail: принято и уже реализовано. Ждем в 1.22 и в пакете exp для тех кто пока не может обновиться.
- cmd/go: add support for dealing with flaky tests: принято, но реализации пока ждет (судя по всему не ранее 1.23)
- spec: memoization (likely decline): ожидаемо отклонено и закрыто.
- intern package proposal: принято, хотя и с оговорками. Теперь это unique: new package with unique.Handle. Реализации пока нет.

Про итераторы: им быть, но в 1.22 они будут скрыты за флагом GOEXPERIMENT. Нужно для дополнительной полировки как самих изменений так и новых функций и типов в стандартной библиотеке. Зато точно появится новый формат записи циклов for о чем я говорил вот тут.

🆒 Fixing For Loops in Go 1.22

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

package main

import "fmt"

func main() {
 var slc []fmt.Stringer

 for _, s := range []st{{"Hello "}, {"World"}, {"!"}} {
  slc = append(slc, s.toStringer())
 }

 fmt.Print(slc)
}

type st struct{ str string }

func (s *st) String() string { return s.str }

func (s *st) toStringer() fmt.Stringer { return s }

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

[Hello World !]

Пробуем запустить и видим совсем другой ответ: https://go.dev/play/p/5m7YTUeNjfl Возникает вопрос: почему?

В Go внутри цикла, на каждой итерации, испольузется одна и та же переменная. Фактически компилятор переписывает наш код вот в такую конструкцию:

 temp := []st{{"Hello"}, {"World"}, {"!"}}

 if len(temp) > 0 {
  var s st
  for i := 0; i < len(temp); i++ {
   s = temp[i]
   slc = append(slc, s.toStringer())
  }
 }

Однако это еще не все. Обратите внимание, что toStringer свою структуру получает по указателю. Для нас это происходит неявно, из-за того как работает вызов методов в Go. Дальше он конвертирует себя-по-указателю в тип fmt.Stringer и спокойно возвращает для вставки в слайс.

Проблема тут в том, что мы берем указатель на одну и ту же переменную все три итерации и каждый раз добавляем ее в слайс. И если во втором примере, это еще более менее очевидно, то в первом нужно знать о том, что циклы в Go создают переменную не на итерацию, а на весь цикл сразу. При этом Go тут не одинок - в JS и C# изначально было так же и создатели, впоследствии, решали ровно те же проблемы. В свое время (2012ый год ЕМНИП) Расс Кокс был уверен, что такую ошибку он никогда не допустит. Но сейчас, более десяти лет спустя, он был вынужден признать, что при всем своем опыте и знании Go, он совершил не один десяток подобных ошибок.

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

 temp := []st{{"Hello"}, {"World"}, {"!"}}

 if len(temp) > 0 {
  for i := 0; i < len(temp); i++ {
   var v st
   v = temp[i]
   slc = append(slc, v.toStringer())
  }
 }

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

Однако это все-же ломающее изменение, поэтому включено оно будет только в проекте где go.mod ставит версию go 1.22.0 и выше и только для самого модуля (модули которые вы импортируете продолжат работать по старому если сами не перейдут на go 1.22).

А попробовать можно уже сейчас:

- На playground через управляющий комментарий (работает только там) либо через Go dev branch. https://go.dev/play/p/QjEKVbvX59-
- Локально, если стоит переменная окружения GOEXPERIMENT=loopvar и у вас Go >= 1.21.0

🎄 Ежегодное обязательное поздравление с новым годом.

Я долго думал над тем, что написать тут. Поэтическое оставило меня, но два слова я думаю мне связать удастся.

Это был сложный интересный год для Go. В стандартую библиотеку наконец добрались функции и типы на дженериках, поэтому их изучение стало не прихотью а необходимостью. Создатели языка взялись за исправление ошибок дизайна, при этом не забывая о тех, кто построил поведение своих приложений вокруг этих особенностей. Кроме того продолжился тренд на улучшение языка и рантайма. Были, впрочем, и те вещи которые создатели языка пока улучшать не готовы. В следующем году я надеюсь на продолжение этого тренда: внедрение нового не забывая о старом.

Каждому из вас, в новом году, я желаю того же - уверенно двигайтесь в будущее, не забывая о прошлом. Я очень рад и благодарен каждому из вас за интерес к теме развития языка Go - нас уже больше 1300, что для канала с очень специфичными интересами я считаю крайне хорошим результатом. А я в свою очередь продолжу о освещать важные и интересные нововведения и обсуждения вокруг языка.

С новым годом! И тех у кого он уже наступил, и тех у кого он только наступит. И пускай все будет!

🎉 Состоялся релиз Go 1.22

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

— Расширение синтаксиса циклов for. Теперь можно писать

for i := range 10 {
 println(i)
}

Вместо

for i := 0; i < 10; i++ {
 println(i)
}

Изменение приятное, уменьшающее число когнитивной нагрузки. Само изменение шло в довесок к итераторам, которые отложили до Go 1.23 (но которые можно попробовать уже сейчас).

— Изменение принципов создания переменных внутри объявления циклов. Об этом я писал вот тут, но если в кратце больше не нужна конструкция вида tt := tt внутри циклов.

— Итераторы доступны в экспериментальном режиме. Включить и поиграться можно через переменную окружения GOEXPERIMENT=rangefunc. Можно установить через go env -w GOEXPERIMENT=rangefunc если не хочется каждый раз возится. В комплекте так-же идет пакет iter который позволяет создавать pull итераторы из push. Почитать про все это от разработчиков языка можно тут.

— go test -cover теперь корректно выводит 0% покрытия для пакетов где нет тестов, но есть исполняемый код. Для пакетов где нет go файлов или они содержат только структуры выводит старое [no test files].

— Переделали trace – и пакет и UI.

— net/http роутер теперь поддерживает указание метода и паттерны. Про это расширение роутера было много статей и блогов, поэтому тут будет просто упоминание.

— Первый v2 пакет math/rand/v2. Заменили Mitchell & Reeds LFSR генератор rand.Source случайных чисел на более современный и криптографически стойкий ChaCha8. А сие значит, что его можно использовать для криптографических операций. Плюс он быстрее и жрет меньше памяти. Так-же есть PCG генератор, который не криптографически стойкий, но еще быстрее. Кроме этого пакет получил дополнительные методы (в том числе дженерик функция rand.N для работы с семейством int типов, например time.Duration).

— PGO (оптимизация использующая данные профилировщика) теперь генерирует еще более быстрый код. Обещают от 2% др 14% прироста производительности при использовании PGO.

— Оптимизации "встраивание функций" и "девиртуализатор" теперь работают совместно, что позволяет выполнять один после другого и обратно. Этого очень просили пользователи функций криптографических пакетов которые возвращают интерфейсы.

— Оптимизацию "встраивание функций" сделали еще более умной - теперь она пытается отработать внутри циклов и других горячих местах, и наоборот пытается не инлайнить в коде обработки паник. Но пока все это тоже в экспериментальном режиме. Попробовать можно через GOEXPERIMENT=newinliner. Почитать тут.

— Из лично приятного: в пакет slices добралась функция Concat для соединения произвольного числа слайсов. Больше не нужно городить цепочку append.

На мой взгляд релиз в целом приятный, но половинчатый: многое из действительно интересных вещей скрыты за флагом GOEXPERIMENT, а часть вообще осталась ждать Go 1.23. Тем не менее обновится стоит, хотя-бы ради нового синтаксиса циклов for.

Полный список изменений как всегда тут.

Вопрос: может кто знает сервис который 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))