🔄 Вышел gokrazy/rsync v0.3.4

gokrazy/rsync это реализация протокола rsync на чистом Go, и клиент, и сервер, с поддержкой передачи файлов в обе стороны.

В версии v0.3.4 решены три проблемы

➡️ Политику landlock расширили, добавив в неё /etc, а на gokrazy ещё и /tmp, потому что без доступа к этим путям через какое-то время ломалось разрешение DNS на системах с запущенным Tailscale.

➡️ Отдельно поправили совместимость с новыми версиями форка openrsync от Apple, и закрыли баг, из-за которого передача файла иногда падала с ошибкой file has changed mid-transfer.

➡️ Из менее заметного, но полезного, в релиз попал вклад нового контрибьютора, добавляющий клиенту возможность задать собственный net.DialContext. Это позволяет управлять тем, как именно устанавливается сетевое соединение, например проксировать его или привязывать к конкретному интерфейсу, не трогая остальной код клиента.

Если вы используете gokrazy/rsync вместе с Tailscale или синхронизируете большие файлы, которые могут меняться во время передачи, обновление до v0.3.4 стоит того, чтобы не упираться в уже известные и закрытые баги.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

💡 Интересный факт о http.ListenAndServe

Второй параметр в http.ListenAndServe обязателен, но на самом деле Go — это гибкий язык.

Когда вы передаёте nil в качестве хендлера, то есть несколько вариантов, которые приходят в голову: паника, 404 на все запросы или сервер попросту не запустится.

➡️ Узнать ответ

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#ReadySetGo

🤓 Go получит SIMD-инструкции без ассемблера

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

Для задач вроде обработки векторов, хеширования, парсинга протоколов или AI-инфраструктуры это ощутимое ограничение. Команда Go предложила решение — добавить архитектурно-специфичные SIMD-интринсики прямо в язык, без изменения синтаксиса.

Что предлагают

Идея в двухуровневом подходе. Низкий уровень — это архитектурно-специфичный пакет simd, где операции почти один в один соответствуют машинным инструкциям. Высокий уровень — портируемый API поверх него, который появится позже. Сравнение с syscall и os тут в тему. Большинство кода будет работать с высокоуровневым API, а для редких случаев останется доступ к низкоуровневым операциям.

На старте фокус на AMD64. Пробуется всё это под флагом GOEXPERIMENT=simd, ветка называется dev.simd.

Векторные типы описаны как непрозрачные структуры, компилятор распознаёт их и хранит в векторных регистрах:

type Uint32x4 struct { a0, a1, a2, a3 uint32 }
type Float64x4 struct { a0, a1, a2, a3 float64 }

Операции реализованы как методы:

// Сложение элементов двух векторов.
// Соответствует инструкции VPADDD на x86.
func (Uint32x4) Add(Uint32x4) Uint32x4

Загрузка и сохранение работают через указатель на массив нужного размера:

func LoadUint32x4(*[4]uint32) Uint32x4
func (Uint32x4) Store(*[4]uint32)

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

func (Uint32x4) AddMasked(Uint32x4, Mask32x4) Uint32x4 // VPADDD.Z
func (Uint32x4) Equal(Uint32x4) Mask32x4 // VCMPEQD или VPCMPD

Для проверки поддержки процессором нужных возможностей добавлены функции вроде HasAVX512(). Компилятор считает их чистыми функциями, поскольку они не меняются после старта программы, и может использовать это для оптимизаций.

Предложение сейчас в статусе active и рассматривается на еженедельных встречах по Go-предложениям. Часть операций, как Gather и Scatter, отложена на Go 1.27 из-за вопросов безопасности памяти. Портируемый высокоуровневый API и поддержка масштабируемых векторов, таких как ARM64 SVE, тоже в планах на будущее.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoGiggle

📋 Чек-лист из 8 признаков, что вас скоро уволят

Услышали на созвоне слово «оптимизация» больше трех раз? Поздравляем, Вы уже в процессе.

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

➡️ Пройтись по чек-листу

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

🧑‍💻 В Go предлагают лимит на количество HTTP заголовков

В репозитории Go обсуждают новое поле Server.MaxHeaderValueCount в пакете net/http. Статус уже Likely Accept, идёт финальный период комментариев. Если всё пройдёт гладко, поле появится в Go 1.28.

Сейчас сервер net/http ограничивает заголовки только по общему размеру через MaxHeaderBytes. Отдельного лимита на их количество нет. Этим пользуются атаки типа DoS. Злоумышленник шлёт тысячи мелких заголовков, например с именем в один байт без значения. На проводе такой заголовок почти ничего не весит, но во внутренних структурах сервера каждый занимает заметно больше памяти.

Реализация HTTP/2 в Go к DoS атаке устойчива. Сервер закладывает 32 байта накладных расходов на каждое значение заголовка при подсчёте MaxHeaderBytes. Но пользователи всё равно в неудобном положении. Кому нужны большие заголовки, скажем SSO куки на несколько килобайт, приходится поднимать MaxHeaderBytes. Вместе с лимитом растёт и число мелких заголовков, которые сервер готов принять. Слишком большой лимит открывает дорогу DoS, слишком маленький ломает легитимные запросы. Один параметр на два разных риска.

Предлагаемое решение выглядит так:

package http

// DefaultMaxHeaderValueCount is the maximum permitted number of
// header values in an HTTP request.
// This can be overriden by setting [Server.MaxHeaderValueCount]
const DefaultMaxHeaderValueCount = 500

type Server struct {
  // Other fields omitted...

  // MaxHeaderValueCount controls the maximum number of header
  // values that the server is willing to parse from a request.
  // If zero, DefaultMaxHeaderValueCount is used.
  MaxHeaderValueCount int
}

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

Ждать релиза Go 1.28 необязательно. Автор предложил переходный вариант через переменную окружения, он оформлен отдельным issue 80020. Запуск выглядит так.

GODEBUG=httpmaxheadervalues=500 ./your-server

Значение из GODEBUG задаёт дефолт, а явно выставленное поле в Server будет иметь приоритет.

Если у вас сервис на Go с большим MaxHeaderBytes, стоит следить за этим proposal. Новый параметр позволит держать оба лимита раздельно и защищаться от лавины мусорных заголовков без риска сломать реальный трафик.

➡️ Наша новостная рассылка не имеет лимитов

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

🤖 Дайджест недели

Первый июльский дайджест

— GitHub предлагает выслать код на CD-диске

GitHub иронично отреагировал на решение Sony прекратить выпуск дисков для PlayStation. Теперь разработчики могут заполнить специальную форму и получить свой публичный репозиторий записанным на физический CD-ROM.

— 1 часть цикла постов про сравнение двух структур

— Учимся уходить красиво

— gokrazy/rsync v0.3.4

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoLive

👨‍💻 Шардируйте локи или ускорение in-memory кеша до 8 раз

Конкурентный in-memory кеш в Go часто пишут через один sync.Mutex. Пока нагрузка низкая, всё в порядке. Но под конкурентным доступом единственный лок превращается в узкое место, и добавление ядер не помогает, а иногда даже вредит.

Миша Стребков собрал один и тот же кеш string → string шестью способами на чистой стандартной библиотеке и прогнал бенчмарки под чтением, сбалансированной нагрузкой и записью на 1–8 ядрах. Порядок победителей меняется в зависимости от профиля, а одно «очевидное» решение с ростом числа ядер работает медленнее.

Шесть вариантов

1. naive это обычная map без блокировок, не потокобезопасна и падает на конкурентной записи.
2. mutex использует один sync.Mutex, прост и корректен, но не масштабируется.
3. rwmutex даёт параллельные чтения и эксклюзивную запись через sync.RWMutex.
4. syncmap это встроенная sync.Map.
5. sharded разбивает данные на 256 частей, у каждой свой мьютекс, ключ выбирает часть по хешу.
6. cow реализует copy-on-write через atomic.Pointer, чтения без блокировок, но каждая запись копирует всю мапу.

➡️Что показали замеры

sharded и cow наращивают пропускную способность с ростом ядер, а mutex остаётся плоским. Более того, у mutex на 8 ядрах пропускная способность падает до 0.66 от одноядерной. Чтения не идут параллельно, а кеш-линия с локом гоняется между ядрами. Вы добавили железо и потеряли производительность.

rwmutex упирается в потолок около 2× и перестаёт расти после 4 ядер. Счётчик читателей сам становится точкой конкуренции. На записи он оказывается хуже обычного мьютекса.

cow выигрывает на чистом чтении с огромным отрывом, 87 миллионов операций в секунду на 8 ядрах. Но как только появляется запись, он проваливается почти в ноль, потому что каждый Set копирует мапу на миллион записей.

sharded единственный дизайн, который держится у вершины во всех профилях сразу.

Победитель в пятнадцати строках

sharded это просто N независимых мап, каждая под своим локом. Хеш ключа выбирает часть, поэтому операции над разными ключами почти никогда не трогают один и тот же лок. Конкуренция падает примерно в N раз:

const shards = 256 // степень двойки, чтобы маскировать вместо modulo

type part struct {
  mu sync.Mutex
  m  map[string]string
}
type Sharded struct{ parts [shards]*part }

func (c *Sharded) at(key string) *part {
  h := uint64(14695981039346656037) // FNV-1a
  for i := 0; i < len(key); i++ {
    h = (h ^ uint64(key[i])) * 1099511628211
  }
  return c.parts[h&(shards-1)]
}

func (c *Sharded) Get(key string) (string, bool) {
  p := c.at(key)
  p.mu.Lock()
  v, ok := p.m[key]
  p.mu.Unlock()
  return v, ok
}

func (c *Sharded) Set(key, value string) {
  p := c.at(key)
  p.mu.Lock()
  p.m[key] = value
  p.mu.Unlock()
}

Одна деталь про явный Unlock. На Go 1.26 замер показал, что defer p.mu.Unlock() здесь стоит около +8% (примерно 1 нс) поверх явного анлока. На горячем пути это заметно, поэтому горячие методы разблокируют лок явно.

Почему 256 частей

Достаточно, чтобы убить конкуренцию, и не так много, чтобы жечь память. Свип количества частей на 8 ядрах и сбалансированной нагрузке растёт круто до 256, а дальше выходит на плато. Переход от одного лока к 256 даёт скачок в 9 раз (с 4.6 до 43 миллионов операций в секунду). После 256 отдача падает, 1024 добавляют +13%, 4096 всего +18% при кратно большем расходе памяти.

Цифры на 8 ядрах, ns/op, меньше лучше, равномерное распределение

mix          mutex  rwmutex  syncmap  sharded  cow
read-only    168    53       30       21       11.5
read-heavy   168    259      37       22       12000000
balanced     190    282      57       24       46500000
write-heavy  208    222      73       25       82500000

Восьмизначные значения cow в столбце записи реальные и указаны в наносекундах. 82 500 000 нс это 82 миллисекунды на один Set. Такова цена чтений без блокировок.

➡️ Что использовать

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

cow подходит для данных, которые почти всегда только читают. Это снапшоты конфигов, таблицы маршрутизации, feature-флаги. Чтения непобедимы, но только если записи редкие и батчатся. Для записи он не годится.

sync.Map берите в её нише, ключи пишутся один раз и читаются вечно, либо горутины работают с непересекающимися наборами ключей. За пределами этого она посредственна и аллоцирует (40–72 B/op).

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

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

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

Весь код, сырой вывод benchstat и однокомандный свип для воспроизведения лежат в репозитории.

➡️ Источник

Нашу новостную рассылку не нужно ускорять, она и так быстрая

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

💻 Фреймворк, где файловая система это карта маршрутов

Связка Go и HTMX хорошо стартует, но со временем почти каждый проект обрастает одним и тем же обвесом. Диспетчер маршрутов, стек лейаутов, безопасные URL, проверки на устаревшую генерацию, отпечатки ассетов, команды для отладки.

Без общего фреймворка каждое приложение изобретает свою приватную конвенцию роутинга и растаскивает строковые пути по хендлерам, шаблонам, редиректам и тестам.

goldr стандартизирует этот слой и при этом оставляет приложение явным.

➡️ Что делает goldr

goldr это server-first, HTML-first, HTMX-native фреймворк на Go. Он не вытаскивает центр тяжести из Go. Файловая система становится картой маршрутов,

.templ файлы владеют HTML, HTMX остаётся видимым прямо в разметке, хендлеры остаются обычным Go, а сгенерированный код берёт на себя повторяющуюся работу вокруг маршрутов.

Вы получаете полный рабочий цикл приложения на Go и HTMX. Это маршрутные страницы, вложенные лейауты, HTMX-фрагменты, экшены на мутации, сгенерированные хелперы для URL, live reload, отпечатанные и встроенные статические ресурсы, команды инспекции маршрутов и визуальный инспектор в браузере, который умеет подсвечивать области отрендеренной страницы.

При этом приложение по-прежнему владеет своим net/http сервером, миддлварями, статикой, авторизацией, сессиями, парсингом запросов, валидацией и деплоем. goldr не компилирует CSS, не бандлит JavaScript, не регистрирует хендлеры за вас и не выбирает CDN.

➡️ Как устроены маршруты

В goldr файловая система и есть карта маршрутов. Директория маршрута это единица локального поведения:

app/routes/
  layout.go          -> логика лейаута для / и ниже
  layout.templ       -> HTML лейаута
  route.go           -> GET /
  page.templ         -> HTML страницы
  users/
    route.go         -> GET /users, GET /users/table, POST /users/create
    page.templ       -> HTML страницы users
    by_id/
      route.go       -> GET /users/{id}
      page.templ     -> HTML детальной страницы
    frag_table.templ -> HTML фрагмента

Один route.go объявляет страницу, HTMX-фрагменты и POST-экшены для этой части приложения:

var Route = goldr.RouteDef{
  Page: page,
  Fragments: goldr.Fragments{
    goldr.FragmentRoute("/table", table),
  },
  Actions: goldr.Actions{
    goldr.Action(http.MethodPost, "/create", postCreate),
  },
}

Из файловой системы и этих объявлений goldr генерирует диспатч и типобезопасные хелперы URL. Вместо захардкоженных путей шаблоны ссылаются на сгенерированные хелперы:

urls.Users.Path()
urls.Users.Table.Path()
urls.Users.Create.Path()
urls.Users.ByID.Bind(id).Path()

Важно, что HTMX остаётся видимым на месте вызова. Сгенерированный путь фрагмента подставляется прямо в атрибут hx-get, а не прячется за проприетарными компонентами:

templ UsersView() {
  <button
    hx-get={ urls.Users.Table.Path() }
    hx-target="#users-table"
    hx-swap="innerHTML"
  >
    Refresh users
  </button>
  <div id="users-table"></div>
}

Директория by_id/ маппится в динамический сегмент {id}. Подчёркивания в статических именах превращаются в дефисы в URL, поэтому Go-безопасное имя build_info/ отдаёт путь /build-info.

➡️ Команды разработки

goldr dev держит локальный цикл в движении. Он генерирует templ и маршруты, отпечатывает ассеты, перезапускает приложение и перезагружает браузер. goldr generate обновляет обвязку маршрутов, хелперы URL, вывод templ и отпечатки ассетов одной командой. goldr check проверяет, что сгенерированные файлы актуальны, ничего при этом не записывая.

Команды routes list, routes explain и routes layouts показывают дерево маршрутов из терминала, а routes refs собирает прямые HTMX-ссылки из .templ файлов.

Если у вас растёт Go-приложение с HTMX, которое должно оставаться читаемым, goldr стоит посмотреть.

➡️ Репозиторий

Иногда маршруты ведут сюда.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

📎 Клонирование, которое возвращает тот же тип

В Go 1.26 самоссылающееся ограничение дженериков вида [T Constraint[T]] заработало не только для функций, но и для объявлений обобщённых типов. Один из приёмов, которые это открывает, это клонирование с сохранением конкретного типа.

Что это решает

Представьте пайплайн, стадии которого форкаются под A/B эксперименты, и каждому форку нужно своё независимое состояние. Стадии имеют разные конкретные типы.

Если написать обобщённое копирование, которое возвращает интерфейс Stage, вызывающий код получит абстракцию и не сможет использовать результат как *TransformStage без приведения типа. Приведение прячется где-то в глубине кода, компилятор перестаёт вам помогать, а в рантайме появляется место для паники.

До 1.26 выразить «операция над T возвращает T» на уровне объявления обобщённого типа было нельзя. Компилятор ругался на рекурсивный тип.

Как это работает

Идея в том, что параметр типа T появляется в ограничении на сам T. Тип обязан уметь клонировать именно себя:

type Cloneable[T any] interface {
    Clone() T
}

// DeepCopy возвращает T, а не Cloneable[T].
func DeepCopy[T Cloneable[T]](v T) T {
    return v.Clone()
}

Тот же приём на реальном пайплайне выглядит так:

type Stage[T any] interface {
    Clone() T
    Execute(ctx context.Context, event Event) (Event, error)
    Name() string
}

// ForkStage возвращает T, а не Stage[T].
// Вызывающий получает *TransformStage, без приведения.
func ForkStage[T Stage[T]](s T) T {
    return s.Clone()
}

На вызове конкретный тип остаётся живым:

original := &TransformStage{ /* ... */ }
fork := ForkStage(original) // fork имеет тип *TransformStage
fork.SomeSpecificMethod()    // доступно без приведения

Тип пронесён через операцию целиком. Ни одного скрытого .(TransformStage) в коде.

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

💸 ROI на джуна в первый год — отрицательный

Результат джуна близок к нулю, время сеньоров он сжигает колоссально, а зарплата с учётом overhead — всё равно деньги. Бизнес просто взял и пересчитал стоимость сотрудника — и джуны не прошли по цифрам.

👉 Разбираемся, что пошло не так

Новостная рассылка, с которой всегда всё так

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoGiggle

🧑‍💻 Билдеры, которые не ломаются при встраивании

Продолжаем разбирать [T Constraint[T]] в объявлениях обобщённых типов. Это чинит старую проблему флюентных билдеров, где цепочку вызовов ломало встраивание.

Какую боль это решает

У билдера в Go давнее противоречие. Чтобы работала цепочка .WithX().WithY().Build(), каждый метод возвращает *Builder. Пока билдер один, всё в порядке. Но как только вы расширяете его через встраивание, цепочка рвётся. Метод встроенного типа возвращает встроенный тип, а не внешний, поэтому после первого же вызова вы теряете доступ к методам расширения. Приходится либо дублировать методы, либо приводить типы вручную.

Как это работает

Ограничение задаёт набор методов, а параметр типа B несёт конкретный тип билдера через всю цепочку:

type Builder[B any] interface {
    WithTimeout(d time.Duration) B
    WithRetry(attempts int, backoff time.Duration) B
    Build() (Config, error)
}

// ApplyDefaults возвращает B, а не Builder[B].
func ApplyDefaults[B Builder[B]](b B, env Environment) B {
    b = b.WithTimeout(env.DefaultTimeout())
    b = b.WithRetry(env.MaxRetries(), env.RetryBackoff())
    return b
}

На вызове конкретный тип остаётся живым, поэтому специфичный метод вроде WithHeader доступен прямо в цепочке:

client, err := ApplyDefaults(NewHTTPClientBuilder("https://api.internal"), prodEnv).
    WithHeader("X-Service-ID", serviceID). // всё ещё доступно
    Build()

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

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

👀 Инфографика по горутинам

➡️ Сохраняйте к себе, чтобы не потерять

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoVisual

🧑‍💻 Четыре года разработки без документации

Код собирался. Тесты проходили. Но никто в команде не мог объяснить, зачем существуют три пакета. Инженер получил сервис на 47 000 строк Go. Зелёный CI, четыре года в проде, последние 14 месяцев без серьёзных инцидентов.

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

Долг был не в качестве кода, а в понимании

Здесь ломается привычное определение. Обычно техдолг это плохой код. Спагетти, нет тестов, устаревшие зависимости. Но в этом проекте покрытие было 71%, стиль ровный, зависимости под контролем, сборка чистая. Метрики говорили, что всё в порядке.

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

Работать с кодом, чью логику структуры вы не можете восстановить, это не то же самое, что работать с плохим кодом. Вы не отличите «так сделано по хорошей причине, которую я пока не понял» от «так сделано из-за ограничения, которого давно нет». Каждое изменение несёт эту неопределённость.

➡️ Три пакета, которые никто не смог объяснить

sync2 повторял куски x/sync из стандартной библиотеки. Семафоры, errgroup, пул. Из 11 мест импорта семь тянули только Pool, у которого в стандартной библиотеке есть почти идентичный sync.Pool. Скорее всего, когда сервис писали, стандартных примитивов не хватало, sync2 был затычкой. Потом стандартная библиотека догнала, а затычка осталась.

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

transport определял кастомный HTTP-транспорт с ретраями и настройкой пула. Исходящих вызовов было три, два использовали transport, один обычный http.DefaultClient. Никакой причины для разницы. Это было не решение, а накопление. Разные инженеры добавляли вызовы, кто-то не знал про transport, кто-то не посчитал, что он подходит.

➡️ Зелёные тесты врут

Тесты проверяют поведение. Они не проверяют, что поведение вообще нужно, что абстракция под ним правильная, что это тот код, который должен решать задачу. У transport было 23 теста, все проходили. Они проверяли, что ретраи работают и пул настраивается. Они не проверяли, нужен ли этот транспорт вообще.

Вот показательный кусок. У этой функции было четыре теста, все зелёные, но никто не знал, что значит «legacy» в контексте:

func (c *Client) fetchWithLegacyFallback(ctx context.Context, req Request) (*Response, error) {
    resp, err := c.primary.Fetch(ctx, req)
    if err == nil {
        return resp, nil
    }

    // If primary fails, try legacy endpoint
    // TODO: remove when migration complete
    return c.legacy.Fetch(ctx, req)
}

Комментарию TODO было два года. Миграция, на которую он ссылался, нигде не задокументирована. legacy-клиент всё ещё вызывался при каждой ошибке. Никто не знал, завершилась миграция или идёт до сих пор.

Налог на онбординг

Время на эту археологию не бесплатное. По заметкам автора счёт вышел такой:

• 11 часов на три загадочных пакета

• 9 часов на разбор кэша против Redis

• 7 часов на цепочку middleware, которая протаскивала значение сквозь четыре слоя ради трейсинга. Библиотеку трейсинга заменили годами раньше, а значение осталось
• 4 часа на разбор utils/

Итого около 31 часа, три четверти рабочей недели. И этот счёт оплатит заново каждый следующий инженер, который придёт в проект.

➡️ Оригинал

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep

⭐️ Самоупорядочивающиеся типы в Go для доменных значений

Снова поговорим про [T Constraint[T]], ведь оно работает и для объявлений обобщённых типов. Это удобно для коллекций, которые сортируют доменные типы по их собственному правилу сравнения.

Стандартный constraints.Ordered покрывает числа и строки, но не богатые доменные типы вроде Priority, SemanticVersion или Money. Для них порядок задаётся своей логикой, а не оператором <. Обычно это решают через sort.Slice с замыканием на каждый вызов или через хранение значений как interface{} с приведением при каждом сравнении. Первый вариант рассыпает логику сравнения по коду, второй теряет типобезопасность и добавляет работу рантайму.

➡️ Как это работает

Ограничение требует, чтобы тип умел сравнивать себя с себе подобным:

type Ordered[T any] interface {
    Less(other T) bool
}

// T обязан реализовать Less(T) bool.
type SortedSlice[T Ordered[T]] struct {
    items []T
}

func (s *SortedSlice[T]) Insert(v T) {
    i := sort.Search(len(s.items), func(i int) bool {
        return !s.items[i].Less(v)
    })
    s.items = append(s.items, v)
    copy(s.items[i+1:], s.items[i:])
    s.items[i] = v
}

Доменный тип реализует Less для себя:

type Priority int

func (p Priority) Less(other Priority) bool {
    return p < other
}

set := &SortedSlice[Priority]{}
set.Insert(High)
set.Insert(Low)


SortedSlice[Priority] на этапе компиляции знает, что хранит именно Priority. Вызов .Less прямой, без интерфейсной прослойки в рантайме. Если попытаться вставить тип, который не реализует Ordered[T] для себя, компилятор отклонит его прямо на месте вызова, а не оставит падать под нагрузкой.

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoToProduction

💰 Бонусы-призраки и грейды из параллельной вселенной

Широкая вилка 250–450, а на руки 270? Бонусы до 100%, которых никто в глаза не видел? Оффер, который «горит до конца дня»? Всё это не совпадения, а рабочие схемы, на которых компании экономят прямо сейчас.

👉 Читайте, пока вам снова не пообещали «пересмотрим через полгода»

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика