Golang продолжает развиваться. Изначальные проектные решения ставятся под сомнения, а новые вызовы заставляют язык меняться: дженерики, итераторы, новая имплементация мап. Однако, даже нововведения приходят к нам не такими, как в других языках. Вспомните обсуждения сразу после релиза тех же дженериков. На Go, как мне кажется, в большинстве своём пишут люди, пришедшие из прочих языков, у кого Golang не первый ЯП. Они привыкли к другому подходу работы с абстракциями. И им порой не хватает того, что предлагает язык Гофера. Swiss Tables — попытка быть в тренде.

С вами Кирилл Кузин — ведущий подкастов про IT на канале gIT, где вместе с коллегами по цеху рассматриваем индустрию под разными углами, открывая новые горизонты для вас и самих себя. А работаю ведущим разработчиком в Ви.Tech — IT-дочке ВсеИнструменты.ру. Там мы с командой пишем внутренние системы на Go под задачи бизнеса и по ходу дела разбираемся, как наши инструменты устроены и как реально влияют на процесс разработки.

В этой статье речь пойдёт о новых мапах в версии Go 1.24, реализованных по принципу Swiss Tables — швейцарских таблиц. Попробуем найти ответы на вопросы о том, почему мапы изменились, что лежит в основе новой реализации и как к ней пришли.

Чтобы в этом разобраться, вернёмся в прошлое, когда появилась необходимость изменений внутри самого Go. В статье мы не будем погружаться слишком глубоко. Я также предполагаю, что читатели знакомы со старой реализацией мапы в Golang, и имеют поверхностное представление о том, что собой представляют Swiss Tables как концепция в Rust и C++. Если нет — рекомендую к просмотру мой доклад на Golang Conf X (YouTube, RuTube, VK), где я провёл ретроспективу и разбор швейцарских таблиц, а также сослался на более фундаментальный доклад ребят из Abseil, разработавших новый подход к работе хеш-таблиц («Designing a Fast, Efficient, Cache-friendly Hash Table, Step by Step»).

Однако, всё же акцентируем внимание на нескольких ключевых идеях каноничных швейцарских таблиц, чтобы у нас был общий контекст (все они также описаны в статье Abseil):

• Два массива — реализация предполагает массив с ключами и значениями, а также массив с метаданными. Последний хранит в своих ячейках состояния ассоциированных по индексу ключей-значений: ячейка массива с данными занята, свободна или же свободна, но помечена заглушкой (tombstone), что удалена. Последнее состояние позволяет не разрушать цепочки пробирования.

• Цепочка пробирования — цепочка значений, выстраиваемая хеш-функцией через состояние массива метаданных при разрешении коллизий. Она требуется, если в ячейке, определённой хеш-функцией, уже есть другое значение с таким же хешем, а новое всё равно надо где-то сохранить. Позволяет не терять конфликтующие ключи и их значения, выстраивая их последовательно друг за другом.

• Коллизия — ситуация, при которой два разных ключа имеют один и тот же хеш.

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

• Использование SIMD — для ускорения операций с массивом метаданных.

Сконцентрируемся на том, как мы получили именно такой код в исходниках, каким мы его увидели в версии 1.24, на чём он основан и почему реализация в новой версии может показаться неаккуратной. Ведь изначально переход реализации мап на швейцарские таблицы казался отличной идеей. Да и сейчас такой кажется.

Проблемы старой реализации мап

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

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

• Неоптимальное использование памяти. Каждая новая аллокация памяти для мапы требует объём в два раза больше текущего. Для больших in-memory кэшей это вызов, потому что с ростом x2 значительная часть памяти в конце концов может оказаться аллоцированной, но неиспользуемой.

• Эвакуация данных при росте мапы хоть и выполняется постепенно, но бьёт по CPU пиками нагрузки. В системах с миллионами записей это может привести к ощутимому замедлению работы.

• Рост количества данных увеличивает вероятность коллизий, а с ними начинает замедляться работа, в том числе из-за использования метода цепочек при разрешении коллизий в конкретном бакете.

• Последовательное пробирование на первом этапе таких операций, как вставка, удаление и изменение данных, — простое и действенное решение, к которому стремится язык. Только вместе с тем меняется скорость работы алгоритма мапы: вместо O(1) получаем O(n) в худшем случае.

• Бакеты, из которых состоит мапа, разбросаны по куче, а значит происходит overhead по CPU, так как доступ к памяти — случайный. Приходится скакать по памяти и страдать от кэш-промахов, чтобы найти нужный элемент по ключу. На больших объёмах данных это снова аффектит скорость выполнения программ.

• Рост нагрузки на GC при огромном количестве бакетов, особенно в случае удаления данных во время эвакуации.

Возможно, этот список не полон, и его можно уточнить, но остаётся факт — развитие интернета потребовало поиска нового решения. Как следствие — изменения мап. И, как уже понятно, одним из подобных решений стала концепция Swiss Tables, зарекомендовавшая себя в C++. Однако, первыми в публичном поле на неё обратили внимание не разработчики языка Golang, а комьюнити. В августе 2022 появилось предложение по изменению внутреннего механизма работы мапы. И пока идея доковыляла до конечной реализации, то же сообщество постаралось предложить собственное видение того, как могли бы выглядеть реализации Swiss Tables с учётом возможностей языка на тот момент. Рассмотрим две библиотеки:

• DoltHub / swiss — первая попытка применить новую идею;

• Cockroach / swiss — логичное развитие на основе интерпретации DoltHub.

Я предлагаю изучить каждую из них, чтобы понять, как идея Swiss Tables эволюционировала в Golang и что мы получили в итоге. И начнём с Dolthub.

Swiss Tables в DoltHub

Как выглядит эта мапа через призму швейцарских таблиц:

type Map[K comparable, V any] struct {
   ctrl     []metadata
   groups   []group[K, V]
   hash     maphash.Hasher[K]
   resident uint32
   dead     uint32
   limit    uint32
}

Это обычная структура, принятая в Golang, но с рядом интересных деталей:

• Во-первых, метаданные представлены как слайс массивов, где каждый массив связан со своей группой данных. Как водится, количество пар ключ-значение и битов в метаданных, константа groupSize — восемь:

type metadata [groupSize]int8

• Во-вторых, сами данные разбиваются на группы по восемь ключей-значений. Таким образом остаётся соответствие индекса массива с метаданными и индекса группы, к которой массив относится:

type group[K comparable, V any] struct {
   keys   [groupSize]K
   values [groupSize]V
}

• В-третьих, самое интересное, ребята не стали реализовывать свою хеш-функцию, а воспользовались уже существующей, вытянув её из внутреннего представления мапы в исходном коде Go. Избыточно говорить, что при таком подходе есть риск со временем поломать зависимости при попытке через интерфейс скопировать один в один нужную структуру и вытащить оттуда то, что вас интересует. Не делайте так. Тем более, что то самое представление уже удалили из исходного кода.

type hashfn func(unsafe.Pointer, uintptr) uintptr

func getRuntimeHasher[K comparable]() (h hashfn) {
   a := any(make(map[K]struct{}))
   i := (*mapiface)(unsafe.Pointer(&a))
   h = i.typ.hasher

   return
}

Помимо внутреннего устройства мап, нас в первую очередь интересуют три основные операции, которые реализуются на хеш-таблицах: получение данных (get), вставка или изменение данных (put) и их удаление (delete). Предлагаю начать с операции Get().

func (m *Map[K, V]) Get(key K) (value V, ok bool) {
   hi, lo := splitHash(m.hash.Hash(key))
   g := probeStart(hi, len(m.groups))
   for {
      matches := metaMatchH2(&m.ctrl[g], lo) 
                                             
      for matches != 0 { 
         s := nextMatch(&matches)
         if key == m.groups[g].keys[s] {
            value, ok = m.groups[g].values[s], true
            return
         }
      }
      
      matches = metaMatchEmpty(&m.ctrl[g])
      if matches != 0 { 
         ok = false
         return
      }
      g += 1 
      if g >= uint32(len(m.groups)) {
         g = 0
      }
   }
}

По факту, тут выполняется несколько этапов работы с данными и самой мапой:

1. Оптимизация поиска группы, с которой начнём искать нужные данные через старшие биты хеша. Так начинается процесс пробирования. Подобная оптимизация с частью битов хеша есть и в старых мапах.

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

3. Проверка полученных совпадений по метаданным на то, что имеется совпадение у какого-то конкретного сохраненного в мапе ключа с ключом из запроса.

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

5. Если пустой ячейки нет, то последовательно выбирается следующая группа и так до момента, пока либо алгоритм не пройдёт все группы, либо не найдёт интересующий ключ и значение.

Операция вставки значения выглядит почти также, за исключением первых строчек:

if m.resident >= m.limit { 
      m.rehash(m.nextSize()) 
}

Если мапе не хватает места, так как количество данных превысило установленный лимит, происходит её увеличение, то есть — рехеширование. И операция Put() нам ценна как раз этим.

func (m *Map[K, V]) rehash(n uint32) {
   groups, ctrl := m.groups, m.ctrl 
   m.groups = make([]group[K, V], n)
   m.ctrl = make([]metadata, n)

   for i := range m.ctrl {
      m.ctrl[i] = newEmptyMetadata()
   }

   m.hash = maphash.NewSeed(m.hash)
   m.limit = n * maxAvgGroupLoad
   m.resident, m.dead = 0, 0

   for g := range ctrl { 
      for s := range ctrl[g] {
         c := ctrl[g][s]
         if c == empty || c == tombstone { 
                                           
            continue
         }
         m.Put(groups[g].keys[s], groups[g].values[s])
      }
   }
}

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

Метод удаления данных рассмотрим лишь частично:

for {
      matches := metaMatchH2(&m.ctrl[g], lo)
      for matches != 0 {
         s := nextMatch(&matches)
         if key == m.groups[g].keys[s] {
            ok = true
            if metaMatchEmpty(&m.ctrl[g]) != 0 { 
               m.ctrl[g][s] = empty
               m.resident--
            } else { 
               m.ctrl[g][s] = tombstone
               m.dead++
            }
            var k K
            var v V
            m.groups[g].keys[s] = k
            m.groups[g].values[s] = v
            return
         }
      }

Здесь и скрывается логика проставления tombstone (заглушек) в цепочках пробирования. Всё снова сводится к тому, заполнена ли группа полностью.

По итогу реализация библиотеки Swiss Tables выглядит довольно просто за счёт структуры, последовательного пробирования по группам и внутри них, а также имеет следующие очевидные плюсы:

• load factor (тот самый, который в старых мапах Golang ~82%) — здесь все 87%;

• неплохой перенос основных концепций Swiss Tables в плоскость Go;

• использование SIMD через ручной код ассемблера.

Но есть и минусы:

• очень простая реализация, которая затрагивает при рехешировании весь объём мапы (этим же страдает старая мапа);

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

Теперь предлагаю посмотреть на вторую библиотеку — Swiss Tables от Cockroach.

Swiss Tables в Cockroach: что изменили

Здесь код значительно сложнее, а модель включает несколько уровней: мапу, бакеты, группы и слоты:

type Map[K comparable, V any] struct {
   hash hashFn
   seed uintptr

   allocator Allocator[K, V]

   bucket0 bucket[K, V]
   dir     unsafeSlice[bucket[K, V]]
   used    int
   
   globalShift       uint32
   maxBucketCapacity uint32
   _                 noCopy
}

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

• bucket0 — тот самый бакет, с которого начинается мапа, «нулевой пациент». Разросшись до непотребного размера, он дробится и все его части уезжают в следующее поле dir, а поле bucket0 становится nil.

• dir — слайс, ячейки которого уже помогают общаться с бакетами, когда их больше одного. Будем называть каталогом бакетов.

• used — количество занятых ячеек в мапе по всем бакетам.

Особняком стоит поле hash, в котором живёт хеш-функция. Реализовали ли Cockroach свою? Нет, она получена тем же способом, что и в DoltHub, о чём в коде оставлено прямое замечание:

// https://github.com/dolthub/maphash provided the
// inspiration and general implementation technique.
func getRuntimeHasher[K comparable]() hashFn {
   a := any((map[K]struct{})(nil))

   return (*rtEface)(unsafe.Pointer(&a)).typ.Hasher
}

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

type bucket[K comparable, V any] struct {
   groups    unsafeSlice[Group[K, V]]
   groupMask uint32

   capacity   uint32
   used       uint32
   growthLeft uint32

   localDepth uint32
   
   index uint32
}

По факту, бакет — это та же мапа в понимании библиотеки Dolthub, но с более сложной логикой разрешения коллизий. Сами данные хранятся глубже — в группах, а бакет содержит информацию, которая помогает с ними работать. Группа — простая структура: один массив метаданных из восьми ячеек и массив из восьми слотов, каждый из которых хранит пару ключ-значение:

type Group[K comparable, V any] struct {
   ctrls ctrlGroup
   slots slotGroup[K, V]
}
type slot[K comparable, V any] struct {
   key   K
   value V
}

Заметно, что идеи Dolthub преобразились, усложнились и теперь работают иначе, визуально более приближенно к тому, что из себя представляли мапы до версии 1.24. Но возникает закономерный вопрос — каков механизм роста мапы? В старой реализации и в реализации Dolthub рост затрагивал мапу целиком. Тут, обращаясь к документации, механизм иной. Он называется Extendible Hashing и работает с полем dir.

Разберёмся, что из себя представляет этот каталог бакетов:

Представим, что в мапе есть три бакета. И каждый имеет доселе неизведанную характеристику — localDepth, или локальную глубину (уж простите меня за дословный перевод). По сути — это счётчик того, сколько раз данный бакет и его потомки/родители разделялись надвое. У самой мапы есть свойство globalDepth, или глобальная глубина, которая подсказывает максимальную локальную глубину бакетов. Другими словами — сколько раз дробился самый используемый бакет (и его потомки). Здесь работает несколько правил:

• глобальная глубина не может быть меньше максимальной локальной глубины, поэтому обязательно возможности инкрементируется, если максимальная локальная глубина становится больше по значению;

• количество ячеек в dir равно степени двойки и длина адреса ячейки равна глобальной глубине;

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

Если в последний бакет добавить ещё данных, превысив их количество, которое он может содержать, бакет разобьётся надвое.

Локальная глубина бакета и его нового собрата увеличится на единицу, как и глобальная глубина. Dir увеличится по степени двойки и перераспределит указатели ячеек на бакеты по новому. Вот и весь механизм роста. Он потрясающ тем, что не затрагивает мапу целиком, а только одну её часть.

Теперь перейдём к реализации методов. Delete() и Get() опустим — они по логике похожи на то, что мы уже видели у Dolthub. А у метода Put() интересно рассмотреть, как он рехеширует бакет программно.

func (b *bucket[K, V]) rehash(m *Map[K, V]) {
   if b.capacity > groupSize && b.tombstones() >= b.capacity/3 {
      b.rehashInPlace(m) 
                         
      return
   }

   newCapacity := 2 * b.capacity
   if newCapacity > m.maxBucketCapacity {
      b.split(m)       return
   }

   b.resize(m, newCapacity) 
}

Ребята из Cockroach реализовали целых три стратегии рехеширования:

• Первая стратегия предлагает перестроить существующий бакет, если количество заглушек внутри него более трети от всей ёмкости. Эта оптимизация ведёт к тому, что существующий бакет перестраивает цепочки пробирования, избавляясь от неиспользуемых для хранения данных заглушек. Считаю, что ход отличный.

• Вторая стратегия предлагает разделение бакета пополам в случае, если достигнут лимит по максимальной ёмкости.

• Третий классический ход — увеличить ёмкость бакета в два раза.

На моём оборудовании (Mac Air M4 16 Gb), при работе с мапой на строках в лёгком (6 элементов), среднем (> 8 тысяч элементов) и тяжёлом весе (> 4 млн. элементов), реализация Cockroach выиграла и у Dolthub, и у старых гошных мап по скорости работы. По памяти, к сожалению, тесты не проводил.

Результаты при малом количестве кэш-промахов:

Результаты при большом количестве кэш-промахов, что наиболее ценно:

Единственный минус у Cockroach — это отсутствие SIMD, но в Golang это можно исправить так же, как это сделали в DoltHub.

Что попало в Go 1.24

Так как логика библиотеки Cockroach очень схожа с тем, что уже есть в исходном коде языка, то она и легла в основу новых мап в Golang. В этом и заключается прелесть: разработчики языка по сути переиспользовали наиболее удачный вариант от комьюнити, слегка доработав его под свои ограничения. Всё осталось таким же: и иерархия (только бакеты поменяли на таблицы); и работа с разделением бакетов — один в один. Даже код методов одинаков. Посмотрите сами на эту мапу:

type Map struct {
   used uint64
   seed uintptr

   
   dirPtr unsafe.Pointer
   dirLen int

   
   globalDepth uint8
   globalShift uint8

   writing uint8

   clearSeq uint64
}

Отличия есть, но концептуально — это Cockroach. И именно поэтому я предложу вам сконцентрироваться не на исходном коде новых мап, потому что эволюцию мы уже проследили и понимаем, как они выглядят, а на интересные решения внутри.

И буду честен — готовясь к конференции, я ещё не до конца понимал причины принятия тех или иных решений. Сейчас уже могу ответить на некоторые вопросы «почему». А на остальные приглашаю ответить в комментариях.

Во-первых, по неведомой мне изначально причине, код мап разбит на несколько пакетов с путями:

• src/runtime/map_noswiss.go

• src/runtime/map_swiss.go

• src/internal/runtime/maps/runtime_swiss.go

И вроде бы логично, что мы оставляем старую реализацию для сохранения обратной совместимости. Но почему новая мапа разъехалась на два файла — немного не понятно. А на самом деле, она разъехалась на все три. Есть ещё src/internal/runtime/maps/map.go.

При этом, если посмотреть в исходный код методов, то удивляет, что методы Get() и Put() описаны в одном месте, а логика Delete() тянется из последнего упомянутого мной файла (в котором, кстати, есть реализация и прочих методов, впрочем, неиспользуемых).

К этому у меня был большой вопрос. И по поводу кода методов Get() и Put() этот вопрос остаётся — зачем? А вот на счёт разных файлов в отдельных частях кодовой базы всё немного понятнее. Причин для такого решения несколько. И одна из них, как мы любим, историческая. Связана с директивой go:linkname, которую использовали некоторые библиотеки, чтобы залезть во внутренности рантайма. Теперь просто так не поменять контракты и реализацию. Приходится постепенно вводить изменения, максимально их контролируя и вынося из ядра языка.

Также, как известно, пакет runtime компилируется по особому, и, в частности, не использует race-detector. Старые мапы жили самодостаточно и без него — как и без тестов. Чилили в рантайме. Но, кажется, что разработчики языка решили изменить подход, вынеся отдельную логику во вне, чтобы иметь возможность тестировать изменения и контролировать ключевые аспекты работы новых мап. А уже их реализация будет подключаться и в рантайм (метод Delete(), как пример), и в будущем в остальные части исходного кода. Скорее всего это будет вообще отдельная библиотека, доступная извне.

Как видно, причин сделать некоторое количество файлов в разных частях кода, да ещё где-то через go:linkname к старой реализации — вынужденный компромисс, ввиду особенностей развития Golang. И подобная топология точно должна со временем измениться.

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

И это ещё не всё. Методы keys и values остались висеть не имплементированными. Судя по issue, функции заезжали для работы с итераторами, но в конечном итоге убрали их реализацию и пока не почистили окончательно.

Теперь посмотрим на рехеширование внутри новой реализации мап:

func (t *table) rehash(typ *abi.SwissMapType, m *Map) {
   newCapacity := 2 * t.capacity
   if newCapacity <= maxTableCapacity {
      t.grow(typ, m, newCapacity)
      return
   }

   t.split(typ, m) 
}

К сожалению, здесь не нашлось места для рехеширования по месту — механизма, который учитывает количество заглушек внутри конкретной таблицы, как это реализовано у Cockroach. Разработчики честно признаются в комментариях к коду и в issue, что такой подход трудно реализовать.

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

Другие отличия Swiss Tables от канонической реализации

А чем ещё Swiss Tables в Golang отличается от канонической реализации? Прежде всего тем, что SIMD поддерживается лишь частично. В рантайме и стандартной библиотеке можно найти SIMD-инструкции, но это пока только ручной ассемблер, который, при желании, можно написать самому — и для x86, и для Neon на ARM. Но полноценной поддержки таких оптимизаций, особенно для новых мап, пока нет. Здесь есть куда расти.

Поэтому если вдруг вы не захотите использовать новые мапы и продолжите работать со старым, проверенным инструментом, то можете указать глобальную переменную GOEXPERIMENT=noswissmap, и будет вам счастье. Никаких новых неизвестных багов. Только старые и известные.

Бенчмарки: кто быстрее

Сравним мапы между собой. На моей аппаратуре новые мапы стали пошустрее старых, однако, они всё ещё проигрывают Cockroach. Вот результаты с малым количеством кэш-промахов:

Тут с большим количеством кэш-промахов:

Оглядываясь на всё выше написанное — во многом повторяющее мой доклад на Golang Conf — не могу сказать, что релиз получился совсем уж сырым. Шероховатости есть, как и вопросы к реализации, но в целом это обычная инженерная задача: внести изменения в уже работающую систему, не сломав её. На процесс повлияли и окружение, и фраза «так исторически сложилось». Так что в этой статье я говорю тому себе, что выступал на конференции — нормально, и так сойдёт!

При этом очевидно, что у разработчиков языка есть огромный потенциал для оптимизации и дальнейшей модернизации швейцарских таблиц. Как минимум, нужно догнать библиотеку Cockroach в быстродействии. Так что главный вопрос остаётся открытым: готовы ли мы доверять новой версии мап прямо сейчас? Или пока предпочтём остаться на старой реализации?

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

А мы теперь понимаем, откуда получили то, что получили, какие этапы осмысления прошли швейцарские таблицы до того, как попали в исходный код. На этом спасибо за ваше внимание. И у меня остался к вам ещё один вопрос: нравятся новые мапы в Go?