🚀 Hello World!

Первый пост в новом канале, это так волнительно

Вкратце что здесь планируется:
- Новости про Go конференции
- Новости и интересные штуки про сам Go
- Немного архитектуры
- Много духоты

О себе:
Go разраб, начал писать 9 лет назад и не могу соскочить
ex Positive Technologies
ex VK Tech

Вхожу в программный комитет конференции GoFunc и E-CODE.
Иногда являюсь спикером

Достаточно крутой доклад с осеннего GoFunc, про аллокации при работе со строками:

https://youtu.be/HDK3BPA-t68
https://vk.com/video-222141090_456239037

Конечно же он 🥁🥁🥁 мой

😀ЗАПУЩЕНО ПРИЛОЖЕНИЕ
😅ЗАПРОС ВЫПОЛНЯЕТСЯ БЕСКОНЕЧНО ДОЛГО
🥲ПО ЛОГАМ НЕ ПОНЯТНО ЧТО ПРИЛОЖЕНИЕ ЖДЕТ
🫡В ДЕБАГЕ ООЧЕНЬ МНОГО ГОРУТИН

Что делать?

pprof.Do() — позволит "пометить" горутины LabelSet(ом) внутри рантайма, с этими labels дружит как минимум профайлинг и дебаг в Jetbrains.

И достаточно важно, LabelSet наследуется на новые горутины.

Небольшой пример:

pprof.Do(
    ctx,
    pprof.Labels("path", r.URL.Path),
    func(ctx context.Context) {
       // next.ServeHTTP(w, r)
    },
)

В общем штука достаточно крутая, вижу следующие минусы:
- panic не пишет LabelSet горутины
- есть небольшой оверхед при создании горутины, но им можно пренебречь

Люблю когда простые вопросы заставляют копнуть вглубь какой-либо вещи

Простой вопрос:
Как посчитать длину строки?

len("👩🏻‍❤️‍👨🏻") // 28

Мы получили 28, хотя ожидали что получится 1

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

utf8.RuneCountInString("👩🏻‍❤️‍👨🏻") // 8

Ближе, но все равно не то, у нас ведь 1 символ, а получили 8 чего-то. Судя по названию функции каких-то rune.

И тут достаем лопату ⛏️⛏️⛏️

Строки в Go поддерживают Unicode, используя кодировку UTF-8.

Unicode — это набор символов.
Code point — минимальная единица Unicode.
UTF-8 — кодировка для Unicode, один из способов хранения Unicode.
Графема — последовательность из одного и более code point, которая отображается как один графический элемент.
Глиф — конкретный рисунок шрифта, который отображает графему.

Rune это как раз code point, считаю несколько странным, что только в Go spec это есть

Code point может быть самодостаточным: а может быть дополняющим, к примеру глиф 👩🏻‍❤️‍👨🏻 комбинирует несколько code point:
1. couple with heart
2. woman
3. man
4. light skin tone
все кроме последнего code point являются так же и графемой, а ligth skin tone не может использоваться самостоятельно.

В итоге используя стандартную библиотеку utf8, мы посчитали количество code point.

Для подсчета графем уже нужно будет взять стороннюю библиотеку.

uniseg.GraphemeClusterCount("👩🏻‍❤️‍👨🏻") // 1

И получаем 1, это то что мы хотели?

Не совсем, мы подсчитали количество графем, НО за количество глифов отвечает непосредственно тот, кто будет рендерить символы — браузер, терминал и так далее...

В итоге отвечая на вопрос: а количество чего именно мы хотим подсчитать в строке?

Продолжая тему кодировок и немного обещанной духоты.

ASCII фактически сейчас описывается не в ANSI X3.4-1968
А в Unicode, так как по ANSI это 7 битный код
На данный момент никто не отправляет 7 бит, ASCII по факту является 8 битной кодировкой, где старший бит помечен как: "reserved, do not use"

Дополнение к предыдущему посту.

Я не нашел PDF от 1968 года, только от 1977, но в самом документе сказано, что это версия от 1968.

Когда-то я напишу про то: почему в одном байте 8 бит, и почему ASCII 7 бит.

Каждый раз, когда заходит речь про JWT, Я вспоминаю эту схему, которую увидел аж в далёком 2021

В целом, отличный канал, советую подписаться:

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

Самый нормальный случай использования токена -- это oauth с третьесторонними сервисами авторизации типа google.

А в эту пятницу хочу поделиться легендарным видео: первой презентацией Docker

Docker родился и использовался внутри компании dotCloud (облачная платформа для разворачивания приложений)

В 2013 году Docker был презентован миру, при том что во время небольшой сессии lightning talks на PyCon US 2013

Docker на тот период был оберткой над LXC, 10 марта 2014 года уже научился напрямик использовать cgroups, namespcases и другими функциями ядра

Для понимания, как было до Docker:
1. Создать LXC.
2. Создать новую файловую систему.
3. Подмаунтить RW слой.
4. Создать нетворк.
5. Назначить IP для контейнера.
6. Настроить NAT.
7. Выполнить процесс в контейнере и захватить его output.

После: на видео видно, как легко запустить контейнер.


https://youtu.be/wW9CAH9nSLs

А на выходных поговорю подушню про B-tree.

Когда спрашивал у кандидатов, во время интервью про индексы в PostgreSQL, кандидаты вспоминали про B-tree, но очень часто ошибочно придают смысл букве B: Balanced или Binary.

Почему это не верно:
- Balanced tree — сбалансированность это свойство дерева.
- Binary tree — другой тип данных.

B-tree было создано в Boing в 1970 году, над созданием работали: Rudolf Bayer и Edward M. McCreight.
И вроде B может значит: или Bayer, или Boing :)

Но нет, буква B не значит ничего, в документе, где впервые рассказали про B-tree нет ни слова про то: что же значит буква B.

Микро факты:
- B-tree создан не совсем в Boing, а в Boeing Research Lab.

- Rudolf Bayer не связан с компаний Bayer :)

- Rudolf Bayer был причастен к созданию:
🤯 UB-tree (ломающее мозг дерево), надеюсь не нужно будет с ним работать;
👩🏻‍💻 Red-black tree (красно-черное дерево) самобалансирующееся бинарное дерево поиска.

В PostgreSQL нет B-tree

Да, в документации описан именно B-tree

Но PostgreSQL на самом деле использует Lehman and Yao's high-concurrency B-tree, в дальнейшем эту структуру данных буду называть как: B*-tree, так как в описании Lehman и Yao используют именно это определение.

В чем разница?

Как выглядит B-Tree:

     +------+      
     |11  13|      
  +--+--+---+--+   
  |     |      |   
+-v--+ +v-+ +--v--+
|9 10| |12| |14 15|
+----+ +--+ +-----+

Так выглядит B*-tree:

           +----+                  
      +----+ 11 +-----+            
      |    +----+     |            
      |               |            
    +-v+---------->+--v---+        
  +-|10|+      +---|12  13|---+    
  | +--+|      |   +--+---+   |    
  |     |      |      |       |    
+-v+  +-v-+  +-v-+  +-v-+  +--v---+ 
|9 |--> 10|--> 11|--> 12|--> 13 14|
+--+  +---+  +---+  +---+  +------+

У B-tree и у B*-tree есть параметр: k.

И в одной вершине содержится от k до 2k значений.
А это значит что для вставки возможно нужно как бы расщеплить/разделить вершину.

Видно по структуре B-tree что поиск ведется сверху-вниз, в связи с этим при вставке, путь до нужной вершины может поменяться во время вставки данных.

А вот в B*-tree есть возможность вести поиск сверху-вниз, слева-направо. В связи с этим можно осуществлять поиск без read locks.

N.B.
Разработчики PostgreSQL (PostgreSQL Global Development Group) реализовали B*-tree с изменениями.

Так какие изменения были внесены B*-tree командой PostgreSQL?

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

Расскажу вот о чем:
Для нижних узлов добавили связь справа-налево:

+--<--+---<--+---<--+---<--+------+
|9 |  | 10|  | 11|  | 12|  | 13 14|
+--+-->---+-->---+-->---+-->------+

Что позволяет использовать index scan backward, для агрегатной функции max или ускорить обратную сортировку.

TIP_0:
PostgreSQL позволяет указать в каком порядке хранить данные в индексе (пока что поддерживается только B-tree)
При создании индекса можно указать ASC | DESC, на больших данных или в составных индексах это может сильно ускорить запрос, особенно при ORDER BY в сочетании с LIMIT n.

TIP_1:
PostgreSQL поддерживает Index-Only Scans — возможность выполнения SELECT обращаясь только к индексу, без обращения к страницам таблицы.

Продолжая тему кодировок, но уже немного практики теории:

fmt.Println(
    leftStr,
    rightStr,
    leftStr == rightStr,
) // output: ё ё false

У нас есть две строки: leftStr и rightStr, которые отображают один и тот же рисунок из шрифта, но эти строки неравны друг другу.

С помощью UTF-8 некоторые символы Unicode можно закодировать разными способами:

Символ ё, как ё (U+0451)
Символ ё, как комбинацию: е и ¨ (U+0435 и U+0308)

И 🥁🥁🥁 leftStr и rightStr объявляются таким образом:

leftStr := "\u0435\u0308"
rightStr := "\u0451"

А Go сравнивает строки бит за битом.

И назревает вопрос: а как с этим жить?
Ведь если у нас есть какой-то фильтр, его можно будет обойти.

На этот вопрос уже есть ответ и даже blog post на go dev от 2013 года и это нормализация строк.

Если лень читать, то:
Нормализация это приведение строк к единому виду.

И в Go можно нормализовать стоки таким образом:

package main

import (
    "fmt"
    "golang.org/x/text/unicode/norm"
)

func main() {
    leftStr := "\u0435\u0308"
    rightStr := "\u0451"
    leftStr = norm.NFC.String(leftStr)
    rightStr = norm.NFC.String(rightStr)
    fmt.Println(
       leftStr,
       rightStr,
       leftStr == rightStr,
    ) // output: ё ё true
}

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

UPD:
Только заметил, что в первом примере е с умляут (две точки сверху) по-разному отображаются в браузерной и мобильной (Android) версии браузера.

Если у кого-то IOS, можете пожалуйста скриншот сделать и в коммент кинуть?)

Про это как раз писал выше: за количество глифов отвечает та сторона, которая рендерит эти глифы

Endianness или конечность порядок байт

Компьютеры по-разному хранят данные в оперативной памяти.

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

А все потому что люди до сих пор не договорились как хранить данные.

Есть системы, которые хранят от старшего (MSB most significant byte) к младшему (LSB least significant byte), а есть наоборот от LSB к MSB.
MSB и LSB не стоит путать с MSb (most significant bit) и LSb (least significant bit) одно про биты, другое про байты.

В 1980 году для обозначения порядка байтов было введено два понятия: Little-Endians и Big-Endians, ссылаясь на документ под названием Gulliver's Travel (1726 г.).

Little-Endian — (LE) порядок байт от LSB к MSB (слева направо)
Big-Endians — (BE) порядок байт от MSB к LSB (справа налево)

Как выглядит на практике?

const u uint32 = 1
le := make([]byte, 4)
binary.LittleEndian.PutUint32(le, u)

be := make([]byte, 4)
binary.BigEndian.PutUint32(be, u)

fmt.Printf("%b\n", le) // output: [1 0 0 0]
fmt.Printf("%b\n", be) // output: [0 0 0 1]

Берем 1 в uint16, в байтовом представлении у нас должна быть только одна единица в позиции LSB.

В Little-Endian единица находится слева.
В Big-Endian единица находится справа.

Важно: сами байты не поменялись, поменялся именно их порядок.

И зачем же знать все это дело?
Чтоб в ногу не стрелялось

— При работе с UTF-16, UTF-32 следует помнить про BOM (byte order mark), константа которая поможет определить порядок байт.
В LE это [254 255] в BE это [255 254].

— При сериализации слайс байтов в конкретный тип.

К примеру нам приходит слайс байтов, мы знаем что этот слайс на самом деле uint64.
И если мы сконвертируем через unsafe, мы можем выстрелить в ногу, из-за разности понимания старшого и младшего бита (пример выше).

— Обратный пример использования unsafe:

t := &struct {
  first, second uint16
}{
  first:  1,
  second: 0,
}

v := *(*uint32)(unsafe.Pointer(t))
fmt.Println(v) // output: 256 or 1

Результат может быть разным:
- 1 при Little-Endian
- 256 при Big-Endian

В комментарий скину код, который симулирует поведение при LE и при BE.

— В других случаях, которые я еще не придумал.

P.S.
PostgreSQL хранит файлы страниц как представление оперативной памяти, поэтому копирование файлов на другую машину с целью скопировать базу данных может быть ошибкой, из-за порядка байт.

Небольшой факт:

Название операционной системы Plan 9, а если быть точнее Plan 9 from Bell Labs было вдохновлено очень спорным фильмом Plan 9 from Outer Space.

Как связана эта ОСь с тематикой канала?

Команду Plan 9 возглавляли: Rob Pike, Ken Thompson, они же в дальнейшем работали над Golang и многое привнесли из Plan 9 в сам язык.

На эту тему могу посоветовать доклад: Почему Golang такой странный.

Достойно упоминания:
Plan 9 строился на идее Name Space, спустя 10 лет подобный функционал появился в Linux под названием: namespaces это одна из основ контейнеризации.

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

src/strconv/itoa.go

// small returns the string for an i with 0 <= i < nSmalls.
func small(i int) string {
  if i < 10 {
    return digits[i : i+1]
  }
  return smallsString[i*2 : i*2+2]
}

const nSmalls = 100

const smallsString = "00010203040506070809" +
  "10111213141516171819" +
  "20212223242526272829" +
  "30313233343536373839" +
  "40414243444546474849" +
  "50515253545556575859" +
  "60616263646566676869" +
  "70717273747576777879" +
  "80818283848586878889" +
  "90919293949596979899"

И функции, которые возвращают строковое представление по целочисленному типу используют эту микро оптимизацию.

Не могу описать свой восторг, когда натыкаюсь на подобное.

Еще нечто подобное есть в пакете net/textproto, функционал которого использует net/http.Header{} для канонизации.

src/net/textproto/reader.go

func initCommonHeader() {
  commonHeader = make(map[string]string)
  for _, v := range []string{
    "Accept",
    "Accept-Charset",
    "Accept-Encoding",
    ...
    "X-Powered-By",
  } {
    commonHeader[v] = v
  }
}

Для того чтоб избежать копирования слайса байт при string(a):

src/net/textproto/reader.go:782

// The compiler recognizes m[string(byteSlice)] as a special
// case, so a copy of a's bytes into a new string does not
// happen in this map lookup:
if v := commonHeader[string(a)]; v != "" {
  return v, true
}
return string(a), true

Давно не следил за SwissMap в Golang.

И кажется, есть вероятность, что в Go 1.24 поменяется алгоритм мап на Swiss Tables.

Три недели назад в master ветке появился коммит:

internal/runtime/maps: initial swiss table map implementation

Почитать про SwissMap можно тут:
Оригинальный issue: тык
Описание Swiss Tables: тык
Success story команды DoltDB: тык