Advanced Go | balun.courses

Куда вписать «Глубокий Go» в обычную рабочую неделю

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

Поэтому сразу по цифрам: на «Глубокий Go» стоит закладывать примерно 8–10 часов в неделю на уроки и домашние задания.

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

Например, неделя может выглядеть так:

• вторник - 1,5–2 часа на первый урок
• четверг - еще 1,5–2 часа на второй
• выходные или свободные вечера - домашние задания
• отдельно раз в неделю - Q&A, если накопились вопросы.

И вот домашки здесь лучше сразу учитывать в расписании. Около 60% программы курса - практика: после лекции нужно не просто посмотреть код, а самому поработать с темой и закрепить, как устроен механизм. В некоторых заданиях участники даже воспроизводят отдельные части Go.

Если на работе внезапно случился завал и неделя пошла совсем не по плану - домашку можно сдать позже.

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

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

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

Седьмой поток «Глубокого Go» стартует 29 сентября.

➡️Посмотреть программу и записаться

Из FullStack в Go: как пригодились задачи с курса

Константин занимается разработкой семь лет. Раньше он работал с JavaScript и PHP как FullStack-разработчик, а сейчас пишет на Go и работает backend-разработчиком в Авито.

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

— Почему ты решил перейти в Go?
— Со временем меня все больше привлекал backend. Хотелось работать с более сложными задачами и глубже разбираться в архитектуре. Я решил полностью перейти на Go и сменить работу, поэтому нужно было за короткий срок углубить знания языка.

— Какие курсы сильнее всего повлияли на подготовку?
— Я прошёл несколько программ Balun Courses. Больше всего мне дали «Глубокий Go», System Design и Concurrency в Go.

— Что помогло тебе усвоить и закрепить материал?
— Я попал сразу на два формата: живые лекции и уроки в записи. И честно - мне очень зашел формат в записи. Я пересматривал лекции по два раза: информации много, и в голове она сразу не укладывается. Отдельно помогли практические задачи. Благодаря им появился запас знакомых ситуаций и решений, которого раньше не хватало. Стало проще сопоставлять новый вопрос с тем, что уже разбирал во время обучения.

— Где эти знания пригодились?
— После обучения собеседования проходили легче. На новой работе мы много занимаемся проектированием, и я неоднократно узнавал ситуации, похожие на те, что встречались на занятиях.
Изменения почувствовал и в повседневной работе: проводить code review стало проще, взгляд на возможные решения расширился. Задачи с курсов дали инженерную насмотренность, которой мне раньше не хватало.

— Порекомендовал бы обучение коллегам?
— Да. Я уже рекомендовал курсы коллегам из Авито.

🎥 Посмотреть полное интервью с Константином

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

Поэтому на курсе «Глубокий Go» материал продолжается за пределами лекций: участники выполняют домашние задания, разбирают кейсы из рабочей практики и проводят code review.

➡️ПОСМОТРЕТЬ ПРОГРАММУ КУРСА

Почему на собеседовании уже недостаточно объяснить map через старую схему бакетов

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

Начиная с Go 1.24 встроенные словари используют реализацию на основе Swiss Table. Одно из ключевых различий - способ поиска при коллизиях.

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

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

При этом для кода базовые свойства словарей не изменились: Go 1 версии сохраняет обратную совместимость, а конкретная организация бакетов, групп и управляющих слов относится к реализации рантайма, а не к гарантиям спецификации языка.

Поэтому технически точный ответ на собеседовании начинается с уточнения версии Go. Если речь идет о Go 1.24 и новее, одной схемы с бакетами и overflow-бакетами уже недостаточно: нужно объяснять группы слотов, управляющее слово и поиск кандидатов по части хеша.

На «Глубоком Go» отдельно разбираются прежнее устройство словарей и новая реализация на основе Swiss Table. Это позволяет понимать, почему механизм изменился и какую именно версию описывает привычная схема.

Зачем на курсе по внутреннему устройству Go переписывать части самого Go?

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

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

Около 60% курса занимает практика. На карточках показали, как она выглядит: домашние задания, Q&A-сессии, кейсы из рабочей практики и так далее.

Разница между «я читал, как это работает» и «я могу сам объяснить механизм и последствия его работы» особенно заметна в двух ситуациях:

〰️когда в продакшене появляется проблема, которую уже не решить знанием API
〰️когда на собеседовании после вопроса «что произойдет?» спрашивают «почему?».

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

Новый поток «Глубокий Go» стартует 29 сентября. Набор уже идет, количество мест на потоке ограничено.

❗️Ближе к старту стоимость обучения повысится❗️

Для тех, кто уже учился в Balun Courses, действует отдельная цена:

• после 1 курса – 10% скидка
• после 3+ курсов – 20% скидка
• после 5+ курсов – 30% скидка

Если понимаете, что в работе с Go все чаще хочется не просто знать, что делать, а уверенно объяснять, почему код ведет себя именно так- сейчас хороший момент закрыть этот пробел.

◻️ЗАПИСАТЬСЯ НА САЙТЕ

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

Рассказывает Владимир Балун, ex-Team Lead в Яндекс.

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

🎙 В голосовом Владимир делит internals Go на три уровня: то, что влияет на код почти каждый день, знания для сложных production-задач и детали, к которым можно возвращаться уже по необходимости.

Главная мысль простая:

сильному инженеру важнее не знать как можно больше фактов о Go, а понимать,

какие механизмы реально влияют на его решения в коде

.

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

➡️ПОСМОТРЕТЬ ПРОГРАММУ КУРСА

Почему срез из 1000 элементов занимает 24 байта?

Возьмем простой код:

arr := [1000]int{}
slice := arr[:]
fmt.Println(len(slice))
fmt.Println(unsafe.Sizeof(slice))

На 64-битной архитектуре получим:

1000
24

В срезе тысяча int, но unsafe.Sizeof показывает всего 24 байта. Причина в том, что срез не хранит элементы внутри себя. Сам срез содержит указатель на массив, длину и емкость. Поэтому unsafe.Sizeof(slice) показывает размер самого значения срез, но не массива, на который оно ссылается.

С массивом результат будет другим:

fmt.Println(unsafe.Sizeof(arr))
// 8000

Здесь тысяча int действительно входит в само значение масства, поэтому учитывается весь объем памяти.

Со строками работает похожий принцип:

str := "hello"
fmt.Println(len(str))                   // 5
fmt.Println(unsafe.Sizeof(str)) // 16

len(str) показывает длину строки в байтах, а unsafe.Sizeof(str) - размер самого значения string. Данные строки хранятся отдельно и в эти 16 байт не входят.

Небольшая шпаргалка:
◻️len() - количество элементов или байт, доступных через значение
◻️unsafe.Sizeof() - размер самого значения
◻️ни одна из этих функций сама по себе не показывает всю память, которую значение может удерживать через ссылки на другие данные

Такие детали редко мешают написать обычный код, поэтому их можно годами не замечать. Но на уровне Middle+/Senior все чаще приходится не просто использовать Go, а объяснять, почему программа ведет себя именно так - на собеседовании, при поиске проблем с памятью или при оптимизации сервиса.

На курсе по Глубокому Go мы системно разбираем внутреннее устройство языка: строки и срезы, map, интерфейсы, аллокатор, GC, планировщик и другие механизмы, которые обычно остаются за пределами документации. Большая часть курса - практика, а домашние задания проверяет лично Владимир Балун.

❗️Новый поток стартует 29 сентября. Количество мест ограничено

Почему два почти одинаковых куска кода дают разный результат escape analysis?

С escape analysis легко привыкнуть к простым правилам: взяли адрес переменной - значит она уйдет в кучу, вернули указатель - тем более.

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

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

Когда строка из 20 байт удерживает в памяти гигабайт данных

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

Такое может произойти из-за обычного среза строки:

content := loadLargeFile()
id := content[start:end]
store(id)

Допустим, в content лежит 1 ГБ данных, а в id - всего 20 байт. При создании подстроки Go не будет копировать эти 20 байт в отдельную область памяти - id будет продолжать ссылаться на тот же массив байт, в котором хранится исходная строка.

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

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

В таком случае короткую строку можно явно отделить от исходных данных:

id := strings.Clone(content[start:end])

strings.Clone создаст отдельную копию строки. Мы получим дополнительную аллокацию на 20 байт, зато большая исходная строка сможет стать недостижимой и быть собрана GC.

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

Больше примеров утечек памяти в Go собрали здесь
➡️https://balun.courses/courses/deep_go/memory_leak

Курс подойдет Go-разработчикам уровня Middle и Senior, а также тем, кто недавно перешел в Go из другого backend-стека и хочет глубже разобраться в многопоточном программировании, а не просто пользоваться готовыми решениями.

В результате вы получите системное понимание concurrency в Go: сможете лучше разбираться в сложных production-задачах, понимать причины поведения конкурентного кода и осознанно выбирать подходящие решения, а не просто использовать знакомые инструменты.

Новый поток стартует 3 августа.

Если давно хотели глубоко разобраться в Concurrency in Go, сейчас лучший момент присоединиться к новому потоку.

Именно поэтому мы создали курс Concurrency in Go, в котором собрали все ключевые темы по Concurrency в Go в одну последовательную программу с упором на практику..

За 5 недель вы разберете, как устроена concurrency на уровне, который нужен в реальной разработке.:
- как Go runtime управляет выполнением горутин;
- почему возникают race condition и как их находить;
- как работают каналы и примитивы синхронизации внутри;
- как память и процессор влияют на производительность;
- когда выбирать mutex, когда channel, а когда другой подход.

70% обучения - реальные инженерные задачи, основанные на ситуациях, с которыми сталкиваются разработчики в IT-компаниях. Финальная работа - разработка собственной in-memory key-value базы данных с асинхронной репликацией, где все изученные темы соединяются в одном проекте.

Concurrency в Go - тема, которую сложно освоить только по статьям и отдельным примерам кода.

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

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

Наконец-то почувствовал уверенность на собеседованиях

Андрей в разработке уже около 7 лет: начинал с верстки на Java и PHP, а последние три года пишет на Golang. Недавно он решил прокачать архитектуру и параллельное программирование – и курсы по Concurrency в Go и System Design помогли ему без лишнего стресса пройти собеседования и занять новую позицию.

– Что тебе дало обучение?

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

Знания по System Design - это скорее вложение на перспективу: теперь мне гораздо проще обсуждать архитектурные решения и понимать подходы крупных компаний.

– Что особенно понравилось на курсах?

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

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

Я не успел сделать все домашние задания, но благодаря доступу к записям на год планирую вернуться к ним позже – уверен, так материал усвоится еще лучше.

– Насколько сложно было совмещать с работой?

– Я совмещал обучение с фуллтайм-работой и подготовкой к собеседованиям. На учебу уходило около 10-12 часов в неделю: лекции по вечерам, на выходных – 2-3 часа практики. Совмещать непросто, но вполне реально.

– Рекомендовал бы наши курсы коллегам?

– Однозначно да! Если хочется не просто «поверхностно пройти тему», а реально прокачать алгоритмы и архитектурное мышление.

⚡️Курс по Concurrency в Go стартует уже в понедельник – 3 августа

На нем мы глубоко изучим Concurrency в Go, попрактикуемся на реальных задачах, с которыми сталкивались IT-компании и разработаем In-memory key-value базу данных с асинхронной репликацией

◻️ЗАПИСАТЬСЯ НА КУРС

Как выглядит инженерное мышление уровня Senior разработчика

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

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

💾Senior-инженер думает последствиями

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

С ростом уровня меняется не только объем знаний. Меняется цена решений, которые принимает инженер.

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

Если вы уже пишете на Go и хотите перейти от «знаю, как реализовать» к «понимаю, какое решение выбрать» - курс Concurrency в GO поможет закрыть этот разрыв.

⚡️Самая недооцененная тема в Go

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

Но на собеседованиях и при разборе проблем с производительностью этого уже недостаточно.

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

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

Поэтому на экспресс-подготовке к собеседованию по Golang мы разбираем внутреннее устройство Go как единую систему. Это помогает увереннее отвечать на вопросы про runtime и GC, понимать причины проблем с производительностью и быстрее разбираться в поведении приложения.