Go *

Ко мне в телеграм канал заглянул один из разработчиков Графини (убийцы Grafana), с пояснением, зачем они её родили, и что писали полностью с нуля.

Я верю.

Многие крупные компании применяют Go, а спрос на опытных инженеров, владеющих Go, высок как никогда. Онбординг проходит действительно быстро, и у нас есть успешные тому примеры. Все благодаря общей простоте языка и отсутствию function coloring. В карточках рассказываем, как это получилось у Кирилла в 2ГИС↓

Хотите подтянуть свои знания Go?

Тогда новый бесплатный курс для вас!

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

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

Несколько материалов для старта.

• Как написать свой REST API на Go? Разрабатываем сокращатель ссылок. Делимся пошаговой инструкцией, как написать REST API сервис URL Shortener и развернуть готовое приложение на сервере.

• Fuzzing-тесты в Go после v1.18. Рассказываем, как устроено fuzzing-тестирование в Go и как проверить функцию на корректную валидацию данных.

• Создаем сервис авторизации. Пошаговое руководство по написанию полноценного gRPC-сервиса с архитектурой на Go.

Открыть курс →

Бесплатные курсы Route 256 от Ozon Tech для Go-инженеров уровня middle

Route 256 — это эффективная прокачка знаний и навыков работы с микросервисами. Программа курса составлена ведущими экспертами Ozon Tech — командой, которая разрабатывает сервисы, выдерживающие экстремальные нагрузки до 382 000 RPS.

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

Как минимум, они бустанут ваше портфолио. Как максимум, вы получите оффер в команду. Заходите на сайт Route 256, изучайте требования и подавайте заявку.

Отборочный контест уже 3 августа!

Эффективные хеш-таблицы на Go

В Go нет недостатка хеш-таблиц. Вы всегда можете использовать встроенную map[Key]Val, с ошеломительной скоростью обладающую непревзойденным удобством! А изобилие типов Key, разрешенных к использованию, способно довести до изумления!

Вот только ни указатель, ни слайс не подходят... Невозможно подсунуть свои операции (равенства и хеширования). Но хоть со скоростью все хорошо! (извините, не удержался)

Итого, мне пришлось написать HashMap[K, V any], закрывающую проблемы.

------------------8<------------------

В это трудно поверить, но:

• Без резервирования памяти (конфигурация R0), map[uint64]uint64 работает в 1.93 раза медленнее UintMap! И производит в 5.64 раза больше мусора!!

• А с полным резервированием (R1), в 1.72 раза медленнее! И аж в 16.5 раз больше мусора!!!

Вдумайтесь! На коленке написанная хеш-таблица для целых чисел UintMap почти в два раза обгоняет ЖУТКО оптимизированную нативную map[uint64]uint64!! И существенно менее мусорит!!!

Но раз трудно поверить, то давайте проверим:

func MyUintMap() {
    const N = umN

//R0|    um := lib.NewUintMap(0)
    um := lib.NewUintMap(N) //R1|

    for i := uint64(0); i < N; i++ {
        um.Findsert(i, i+N)
    }
    lib.Assert(um.Size() == N)

    cnt := 0
    for i := uint64(0); i < N; i++ {
        if *um.Val(um.Find(i)) == i+N {
            cnt++
        }

        if um.Find(i+N) == -1 {
            cnt++
        }
    }
    lib.Assert(cnt == N*2)

    for i := uint64(0); i < N; i++ {
        um.Delete(i)
    }
    lib.Assert(um.Size() == 0)
}

func GoUintMap() {
    const N = umN

//R0|    m := make(map[uint64]uint64)
    m := make(map[uint64]uint64, N) //R1|

    for i := uint64(0); i < N; i++ {
        m[i] = i + N
    }
    lib.Assert(len(m) == N)

    cnt := 0
    for i := uint64(0); i < N; i++ {
        if m[i] == i+N {
            cnt++
        }

        if _, ok := m[i+N]; !ok {
            cnt++
        }
    }
    lib.Assert(cnt == N*2)

    for i := uint64(0); i < N; i++ {
        delete(m, i)
    }
    lib.Assert(len(m) == 0)
}

Здесь всего-то лишь вставка, два поиска и удаление. Запустите go test -bench=UintMap -benchmem и увидите сами. Вот только можно ли ругать Google за неэффективный map[uint64]uint64?

------------------8<------------------

Итоги?

1. Смело берите HashMap[K, V any] для слайсов и указателей!

2. Немного оптимизированная BytesMap -- лучший выбор для []byte.

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

И как всегда, исходный код, подробности и пару неудачных шуток вы можете найти в моей статье https://ders.by/go/hashmap/hashmap.html

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.

Привет Хабр! Это мой первый пост, и я просто хотелось спросить, стоит ли уходить в Go? У меня есть небольшая база в программировании, делал сайты на реакт и ларавел, реализовывал бэкенд с Солид и паттернами, писал на нативном пхп файловые обменники и апи. Не много знаю базы данных соответственно, гит, докер. Сейчас засматриваюсь на Go, где то вычитал что мол крутая штука для бигтехов в России, а сам я студент и пока сижу на шее у родителей, но в следующем году я окончу к курс, и хочу где то месяца за 4-5 изучить все нужное в го и во всех других сопутствующих технологиях для разработки высоконагруженных приложений и микросервисов и всякого подобного. Стоит ли сворачивать на этот путь, или добить стек ларавел плюс вью? Немного боюсь, так как слышал что в го нужны уже 25 летние синьоры со стажем работы минимум в 20 лет, но и не хочется проторчать всю жизнь в челябинской галере на фуллстеке за 70 деревянных на руки.

Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.

Моё видение:

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

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

Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).

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

То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.

У меня остались также холиварные вопросы к вам. Как считаете:

• Передавать в юзкейсы структуру или поля по отдельности?

• Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?

• Транзакции: где их начинать/заканчивать?

• Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?

• Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?

Мои коллеги по ИТ-компании "Криптонит" пишут на Go. Я попросила их придумать ошибку — сможете её найти? Ждём в комментариях ваши варианты.

package main

import "fmt"

type User struct {
 name string
 meta map[string]string
 }

func (u *User) SetMeta(key, value string) {
 u.meta[key] = value
 }

func main() {
 u := &User{name: "Alice"}
 u.SetMeta("role", "admin")
 fmt.Println("Meta:", u.meta)
 }

.

.

.

ОСТОРОЖНО! ДАЛЬШЕ СПОЙЛЕР

В main() мы создаём указатель на User, но не инициализируем вложенную map[string]string (Meta)

Присвоение значения через u.Meta[key] = value, вызовет панику (panic: assignment to entry in nil map), потому что u.Meta всё ещё nil, и в Go нельзя присваивать значения в nil-мапу.

Одним из вариантов было бы добавить функцию NewUser(), создавать пользователя через нее, и сразу инициализировать мапу:

 func NewUser(name string) *User {
 return &User{
 name: name,
 meta: make(map[string]string),
 }
 }

func main() {
 u := NewUser("Alice")
 u.SetMeta("role", "admin")
 fmt.Println("Meta:", u.meta)
 }

Второй вариант решения изменить SetMeta что бы инициализировать мапу, если она равна nil

 func (u *User) SetMeta(key, value string) {
 if u.meta == nil {
 u.meta = make(map[string]string)
 }
 u.meta[key] = value

Ошибку и решение нам помог составить Алексей Косов, системный инженер департамента инфраструктуры в «Криптоните». Его материал про особенности, применение, плюсы и минусы Golang можно прочитать в этой статье.

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

Но где сейчас обитает студент? Где можно рассказать о себе, и закинуть удочку для поиска интернов? Хотелось бы и собрать команду, и дать молодым специалистам возможность пополнить свое портфолио реальным кейсом. Заранее спасибо.

Поддержка должна быть бесплатной. Всегда!

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

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

Я основатель облака для простого деплоя проектов через Git push – Amvera Cloud. И вижу, что пользователи пишут нам в поддержку. И говоря честно – люди пишут только тогда, когда другие способы не помогли и они не знают, как решить их насущную проблему. А это значит мы не доработали и сделали что-то непонятно или неудобно. И это наша обязанность постараться им помочь. И я не вижу морального права просить за это с них деньги.

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

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

Поддержка должна быть бесплатной, всегда, и без всяких но! 

Оплачиваемая стажировка Cloud.ru Camp — успей подать заявку до 12 мая 📢

Присоединяйся к Cloud.ru Camp — оплачиваемой стажерской программе, которая поможет студентам и начинающим специалистам прокачать скиллы и с головой погрузиться в IT-сферу. 

Ты можешь выбрать направления:

• Продуктовая разработка: DevOps или Golang.

• Кибербезопасность: мониторинг событий и автоматизация или сертификация программных продуктов.

• Команда внедрения: QA.

• Технические продажи: технический менеджер клиентов.

Что тебя ждет:

• оплачиваемая стажировка,

• работа в реальных проектах,

• поддержка наставников и экспертов,

• регулярная обратная связь.

А у лучших стажеров будет возможность попасть в штат Cloud․ru.

Прием заявок открыт до 16 мая включительно, а для прошедших все этапы отбора стажировка начнется 16 июня. Пройти стажировку можно очно в офисе Cloud.ru в Москве, а также удаленно из любой точки РФ. График гибкий — от 20 часов в неделю.

📬 Подать заявку на Cloud.ru Camp

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

Есть такая мантра в гошке - "всегда обрабатывать ошибки"

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

Недавно работал с либой валидатора, и нашел функцию у которой можно не проверять ошибку так как если она не отработает то приложение не запустится в любом случае

То есть ошибка равна панике

validator.Register("", func any)

if err := validator.Register("", func(
  
); err != nil {
  return err
}

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

В 2ГИС мы пишем на Go и помогаем инженерам перейти на него с других языков. Знакомство с Go открывает возможность контрибьютить в одну из самых востребованных технологий современности. На Go написаны проекты, без которых сложно представить мир распределённых систем: K8s, CockroachDB, Badger, Prometheus, VictoriaMetrics, Jaeger, NATS, Temporal. 

Переход на Go — реальность! В карточках рассказываем, как это получилось у Саши ↓

Хочешь так же? Прямо сейчас ищем ребят с Java и C#.

От картотеки Лумана к современным графам: учим языки программирования с методом Цеттелькастен

В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.

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

Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.

Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки. 

Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →

Новый запуск Route 256 эксклюзивно для Go-разработчиков.

Это бесплатные курсы от экспертов Ozon Tech.
2 месяца онлайн-занятий.
Реальные задачи бигтеха.

Чтобы попасть на Route 256, нужно пройти отборочный контест. Он состоится 20 апреля.

Зачем это вам?

• получить передовые знания от IT-команды ведущего e-com;

• попробовать работу в бигтехе;

• пополнить портфолио крутыми проектами для миллионов пользователей;

• получить оффер в команду Ozon Tech.

Почему именно Go?
У Ozon высоконагруженная и отказоустойчивая микросервисная инфраструктура. Сервисы выдерживают до 382 000 RPS к бэкенду с мобильных приложений и сайта — и это не стресс-тесты. Команде нужны сильные Go-разработчики, чтобы развивать и масштабировать маркетплейс.

🎓Если вы ещё учитесь в вузе, но уже имеете небольшой опыт программирования и понимаете, как устроены алгоритмы и базы данных, регистрируйтесь на уровень junior: https://s.ozon.ru/3lip8Ey

💻Если вы уже имеете опыт коммерческой разработки (на любом языке кроме низкоуровневых, 1С и low-code), регистрируйтесь на уровень middle: https://s.ozon.ru/Q1vHnSc

Переходите по ссылкам, чтобы узнать все детали и отправить заявку на отборочный тур.
Удачи!

А почему нет нормального дженерика для мап? 👀

У кого-то спина белая, а мы собрали бинго из боли, кринжа и немного гордости каждого гошника. Наши ребята из Go-сообщества отобрали самый сок!

Пишите в комментариях, что прожито на личном опыте. Есть чем дополнить? Смело предлагайте 😉

Конкурентность в Go: просто запустить — сложнее управлять

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

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

Например, в статье Curious Channels Дейв Чени описывает два важных свойства каналов в Go:

1. Закрытый канал не блокируется. После закрытия в него нельзя отправлять данные, но можно читать. Если данных нет, возвращается нулевое значение. Это удобно при использовании range, который автоматически завершает цикл.

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

В отличие от языков вроде C, где конкурентность управляется через блокировки и разделяемую память, в Go используются более простые и безопасные механизмы. Однако работа с каналами требует понимания нюансов.

Владислав Белогрудов, эксперт по разработке ПО в YADRO, собрал полезные материалы про конкурентность в Go. В статье — блоги, выступления и книги, которые помогут разобраться, как в Go работать с горутинами и каналами без хаоса и дедлоков.

Как не надо использовать Assert, если реализуете подход Design by Contract

Использовать Assert вместо if err != nil { return err}

Одно из неправильных применений Assert — это замена им проверки, которая действительно должна быть и на которую нужно реализовать реакцию в коде.

Выполнять вычисления при вызове Assert

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

•  e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),

•  Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).

Удалять Assert, несмотря на то, что это часть описания контракта

Непонимание, что Assert — это реализация контракта, может привести к тому, что разработчик, незнакомый с DbC, захочет просто удалить проверку. Однако нужно всегда помнить, что срабатывание Assert говорит о нарушении контракта одной из сторон. То есть, если срабатывает Assert, надо прежде всего найти баг и пофиксить. А уж если контракт действительно должен быть изменен, Assert подскажет, где находятся участки кода, на которые нужно обратить внимание.

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

В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.

Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →

Приглашаем на первый Cloud․ru Tech Lab: Golang — митап для Go-разработчиков и технических лидеров 🎙️

📅 Дата: 13 марта, 19:00
📍 Место: Москва, Большая Почтовая улица, 40с7, Гоэлро Лофт

В программе четыре доклада от разработчиков Cloud․ru и приглашенного гостя. А еще — нетворкинг и afterparty с диджеем, музыкой и ужином.

Темы докладов:

• Как устроена Go-разработка в Cloud․ru — Александр Шакмаев и Андрей Рацеров, технические лидеры;

• Балансировка gRPC в Kubernetes — Михаил Абраш, старший Go-разработчик;

• Как мы бутстрапим пользовательское окружение с Go, Temporal и Kubernetes — Евгений Третьяков, ведущий Go-разработчик;

• Осторожно unsafe! Практические примеры и ошибки использования — Владимир Балун, основатель balun․courses.

👉 Зарегистрироваться

А еще заглядывайте в наши статьи и делитесь размышлениями в комментариях:

• Клиентоцентричность с точки зрения Go-разработчика и причем тут рефлексия

• Гармония железа и кода: ускоряем Go, проектируя приложение с учетом архитектуры процессора