Итераторы… TL;DR: в iter.Seq итератор сам передаёт следующие элементы в код внутри range, а через yield получает сигнал, продолжать обход. Ошибку можно передавать вторым значением через Seq2[T, error], но тогда, если она должна дойти до конца цепочки, все промежуточные итераторы тоже должны уметь её принять и передать дальше, даже если она им не нужна (!). Стоит ли оно такой запары? Вспомним обычный обход:

for i := 0; i < source.Len(); i++ {
    process(source.Get(i)) 
}

Это типичная pull-модель: внешний код сам сначала вытаскивает значение из источника Get(i), а потом передаёт его в бизнес-логику process. Обратный вариант - обход с callback функцией:

source.Scan(func(v Value) bool {
    process(v) // принимает то, что будет попадать из цикла ниже
    return true
})

func (s *Source) Scan(process func(Value) bool) {
    for i := 0; i < s.Len(); i++ {
        if !process(s.Get(i)) {
            return
        }
    }
}

Внешний код вызывает Scan один раз, а дальше уже Scan достает данные и сам вызывает коллбек process - в ответ получает bool и принимает решение об остановке. С точки зрения вызывающего кода это push-модель. Многострадальные итераторы работают по тому же принципу, только такой callback-обход стандартизирован общим типом iter.Seq

go 
func Numbers(n int) iter.Seq[int] {
    return func(yield func(int) bool) {
        for i := 0; i < n; i++ {
            if !yield(i) {
                return
            }
        }
    }
}

Коллбек-механика спрятана внутри range:

 go
for v := range Numbers(10) {
    // callback логика тут, а вызывает ее код из Numbers
    if v == 5 {
        break
    }
}

Numbers сам вызывает yield с очередным значением. Код внутри range получает значение, обрабатывает (в нашем случае сравнивает с 5), и отдает bool итератору, где последний решает, продолжать ли обход. С остановкой по инициативе коллбека внутри range всё ок. Но что, если продолжить обход не может уже сам итератор - например, если чтение следующего значения закончилось ошибкой. В Seq[T] передать её некуда. Один из вариантов - вынести ошибку во второе значение:

func Values() iter.Seq2[int, error] {
    return func(yield func(int, error) bool) {
        for i := 0; i < 10; i++ {
            v, err := readValue(i)
            if err != nil {
                yield(0, err)
                return
            }

            if !yield(v, nil) {
                return
            }
        }
    }
}

Тогда ошибка приходит в тот же range, что и данные:

for v, err := range Values() {
    if err != nil {
        return err
    }

    process(v)
}

Для одного итератора это выглядит естественно. Но в композиции с другими итераторами, например c

func Double(seq iter.Seq[int]) iter.Seq[int] {
    return func(yield func(int) bool) {
        for v := range seq {
            if !yield(v * 2) {
                return
            }
        }
    }
}

eсли ошибка из Values должна пройти через Double до конечного потребителя, то`Double` (который сам упасть не может и которому не нужна ошибка), вынужден перейти на Seq2[int, error] (иначе у нас просто не скомпилится тк Double принимает `Seq[int]`) и явно передавать чужую ошибку Чтобы не разводить зоопарк предложили даже собирать такие ошибки через отдельный хелпер`slices.CollectError` в #70631

func CollectError[T any](seq iter.Seq2[T, error]) ([]T, error) {
    var err error

    result := slices.Collect(func(yield func(T) bool) {
        for v, e := range seq {
            if e != nil {
                // записываем первую ошибку
                err = e
                // завершаем обход
                return
            }

            if !yield(v) {
                return
            }
        }
    })

    return result, err
}

Просто как кейс стандартизации обработки ошибки через Seq2[T, error]. Или очередной способ задать себе правила 🙂 Еще нашла #71901 где решают, какой контракт для итераторов с ошибками стоит считать стандартным. Но мне страшно туда лезть.. #go

😐 Ультимативный разбор... Go 1.27? Честно, не знаю зачем я это сделал, но я сделал.. Ну почти. https://golang.guide/go-1-27/ Сначала я решил просто написать базовый обзор релиза. Но потом я увлёкся и не смог вовремя остановиться. Мне хотелось не просто сухо рассказать об изменениях, а добиться глубокого понимания читателя — причины этих изменений, какие проблемы они решают, как реализовано, почему именно сейчас, какая история стоит за самыми интересными фичами. При этом, я старался писать так, чтобы всё это читалось интересно и легко. В итоге, работа над статьёй так сильно затянулась, что когда она выйдет, сам релиз уже никому не будет интересен. Поэтому я решил опубликовать ту её часть, которая уже готова — это примерно 60%, и туда вошло всё самое интересное и важное: - Дженерик-методы, которые десять лет обещали не добавлять - Новый движок JSON v2 - Пакет uuid наконец-то в стандартной библиотеке - Детектор утечек горутин, который переиспользует сборщик мусора — на мой взгляд, самое красивое, что есть в этом релизе Во вторую половину войдут: постквантовые подписи, рантайм, net/http, SIMD и тулинг. Это я дописываю прямо сейчас, оно появится в той же статье. Все код-сниппеты запускаются прямо из статьи на актуальном go1.27. Каждый из них можно редактировать и экспериментировать — не нужно открывать отдельный плэйграунд. А ещё я подготовил для вас наглядный виджет с демонстрацией механики работы детектора утечки горутин. Я потратил на эту статью ОЧЕНЬ много времени. Возможно, стоило потратить на более фундаментальный гайд — тот же GC, над которым я также сейчас работаю. Но надеюсь, вам всё же понравится ❤️ Стоит ли писать подобные обзоры про новые релизы? ———— А ещё я прикрутил к сайту email-рассылку (и письмо про Go 1.27 туда ушло сильно раньше этого поста) и комментарии к статьям. Если вдруг заметите какие-то баги, пишите в комментариях, постараюсь оперативно поправить. И не хулиганьте в комментариях на сайте! 👍 #article #go1_27

Что на самом деле нужно сохранять при сериализации сложной структуры? TL;DR: Важно отделить логические данные от производного состояния: часть структур можно восстановить после загрузки, а часть - вообще заменить другим физическим представлением под нужный сценарий. Вспомним хотя бы слайс: само значение - это дескриптор с указателем на нижележащий массив, len и cap. После рестарта старого расположения памяти всё равно не будет: появится новый массив и новый дескриптор. То же самое относится к lookup-таблицам, оффсетам, кешу и другим производным структурам, которые существуют ради удобной работы с данными в рантайме. Поэтому в вопросе сохранения структур для дальнейшего переиспользования можно отделить основные данные от производного состояния: сохранить то, что нельзя потерять, а всё, что однозначно выводится из данных, построить заново после загрузки. В инвертированном индексе каждый раз заниматься переиндексацией дорого, поэтому были добавлены два варианта экспорта структур в файлы: snapshot, если после загрузки есть необходимость менять индекс (например, дополнять его новыми термами), и sealed segment, если после загрузки индекс используется только для поиска. Возьмём упрощённый пример: "go" -> doc 10: [2, 7] doc 14: [3] go — term, 10 и 14 — документы в posting list, [2,7] и [3] — позиции слова. Например flat.Index состоит из следующих частей: type Index struct { arena []byte // где лежат термы entries []entry // где хранятся оффсеты термов в арене и список документов byHash map[uint64]int32 // поиск entry по его term hash positions [][][]uint32 // позиции слова для каждого документа внутри каждого entry } Snapshot: сохранить данные для восстановления mutable-структуры В snapshot мы сериализуем в отдельный файл термы, документы и позиции слов - то есть логическое состояние индекса. При загрузке по этим данным заново собирается flat.Index, после чего в него снова можно добавлять данные. Чтобы уменьшить размер snapshot, DocOrd сохраняются как разница с предыдущим ordinal, а получившиеся числа кодируются через uvarint. Про uvarint и delta encoding я рассказывала тут. При загрузке декодер восстанавливает абсолютные DocOrd, последовательно прибавляя сохранённые дельты, а затем собирает структуру индекса заново. byHash мапа после этого тоже строится заново по загруженным термам. (де)сериализация на примере flat индекса Segment: сохранить read-only индекс без восстановления структуры вообще В segment режиме сериализации экспортируются те же основные данные: термы, списки документов, позиции термов - в отдельный read-only бинарный формат. Он разделен на области байт по назначению: [header][postings area][positions area][term index][footer] Postings и positions участки лежат подряд, а term index хранит оффсеты и длины диапазонов для каждого терма. Поэтому при загрузке такого сегмента обратного преобразования индекса в структуру flat.Index уже нет. Для запроса "go" мы находим его оффсеты в term index, берём через mmap (или через обычный `ReadAt`) только нужный диапазон данных и декодируем postings: подробнее про построение segment. То есть в snapshot данные сначала декодируются, а производные структуры типо byHash собираются заново - получаем готовую к использованию структуру индекса. В sealed segment эти структуры вообще не нужны: данные сразу раскладываются в компактный формат с оффсетами, который оптимизирован под чтение. Получается, что одни и те же логические данные можно сохранить по-разному в зависимости от того, что нужно после загрузки. Этот вывод не относится только к поисковым системам: при сохранении сложной структуры не нужна ее in-memory копия. Производное состояние можно не сохранять, если его дешевле восстановить. А если после загрузки данные будут использоваться иначе, из одного и того же состояния можно вообще построить другое физическое представление - под запись или только под чтение. PS: finally совесть чиста и можно готовить вторую часть про HSNW #fts #perf #projects

Привет! Вас стало больше, так что пора наконец представиться 🙂 Я Даша, давно пишу на Go, но на своем тернистом пути постоянно нахожу интересности во внутренностях языка. Пишу про производительность, работу с бд и свои наблюдения, которыми грех не поделится. Параллельно развиваю свой поисковый движок - fts-engine: https://github.com/dariasmyr/fts-engine Из-за него тут регулярно появляются посты про full-text search, индексы, фильтры, хранение данных и разные эксперименты вокруг темы поисковиков. Пока тут легкий хаос с темами: от рабочих кейсов до иногда странных углублений в исходники и ищьюс ;’) Чтобы во всём этом было чуть проще ориентироваться, я разметила посты тегами:

#go - Go, рантайм, реализации техник и описание внутрянки #perf - производительность, профилирование и бенчи #db - базы данных, оптимизации #fts - поиск, индексы и устройство движка #projects - мои проекты и эксперименты

Пишите, если заинтересовала какая то тема или идея, буду рада обсудить. Welcome!

В Go 1.27 завезли SIMD Двенадцать лет Go не умел в векторные инструкции без плясок с ассемблером. В 1.27 приехал портируемый пакет simd, и один исходник без единой правки разворачивается в Neon на Apple Silicon и AVX2 на Intel. Автор проверил обещание на двух машинах, полез в дизассемблер и наткнулся на странное. На Mac четыре полосы дали 4,2x, почти потолок. У i9 полос вдвое больше, восемь, а вышло ровно 5x. Куда делись ещё три икса? Разгадка неуютная для всех, кто верит в ширину регистра. Ту же половину выигрыша снимает обычный скаляр, без единой векторной инструкции, стоит завести четыре аккумулятора вручную. Ширина регистра тут вообще на втором плане.

Вышел TypeScript 7.0 стал быстрее в 10 раз. что сделали: - Переписали компилятор на Go → нативная скорость + многопоточность - Ускорение сборки: x7.7 – x11.9 на реальных проектах - VS Code (repo): 125.7s → 10.6s - Sentry: 139.8s → 15.7s - Playwright: 12.8s → 1.47s - Память: -6% до -26% - First error в редакторе: 17.5s → 1.3s (x13 быстрее) Реальные кейсы: - Slack: -40% времени merge, CI check 7.5 мин → 1.25 мин - Microsoft: -400 часов в месяц на сборку билдов - Canva: ошибки в редакторе 58s → 4.8s Вопрос: сколько стоит 1 минута ожидания в вашей команде? Это классический эффект второго порядка. Вы ускоряете не билд. Вы ускоряете итерацию гипотез. - Было: 5–10 циклов в день - Стало: 30–50 циклов А значит: - быстрее проверка фичей - меньше batch-thinking - выше скорость обучения команды Это уже не DevEx. Это growth-фактор продукта.