Igor Panasyuk | IGORoutine Programming

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

Не для кого ни секрет, что компании часто ищут спикеров для внешних конференций среди своих сотрудников.

Говоря откровенно, для себя я уже прошёл эту игру с конференциями, ни один раз выступил с высокими оценками за доклады на самых крупных конференциях у нас и даже за рубежом.

При этом сам начинал с полного нуля, когда ещё даже не было этого канала.

Но зачем конференции вообще делают? В чём польза для докладчиков и компаний? Как устроена модель конференций? Это отдельный и не такой очевидный разговор.

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

Но их что-то останавливает.

Я синтезировал и постарался развеять топ-3 причины:

1) Моя тема никому не будет интересна

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

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

Порой доменная область даже интереснее, чем технологии.

Подумайте, многим интересно, как устроены, например, какие-нибудь медицинские, пожарные или военные системы.

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

Подобных тем и развилок очень много.

2) А что, если я выйду и опозорюсь перед всеми, как потом жить с этим?

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

Конференции устроены так, чтобы докладчик не утонул.

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

3) А что, если меня не возьмут? Просто поставят плохие оценки, а потом ещё выложат в открытый доступ запись выступления? Я просто боюсь...

На все подобные вопросы у меня есть только один ответ.

Все мы порой испытываем страх и стресс, боимся чего-то в моменте.

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

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

К тому же сама жизнь по длине - раз, два и обчёлся.

Это помогает заиметь незыблемость в таких ситуациях.

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

😎 Поднимите сегодня за меня тост, ибо я не пью, в стакане был чай)

😊 С Наступающим Новым Годом!

🙂 ПАНЕЛЬ УПРАВЛЕНИЯ 🙂

😎 Новогодний розыгрыш 😊

🥇 1 место: большой плюшевый гофер
🥈 2 место: большой тематический Java-коврик для компьютера
🥉 3 и 4 место: стильные блокноты
🎁 ещё 10 мест: фирменные браслеты
🎁 и ещё 20 мест: фирменные значки

Участвовать очень просто: нужно быть подписчиком канала, нажать кнопку «Участвовать» внизу поста и следовать инструкциям бота.
Если захочется увеличить шансы - в боте будет реферальная ссылка.

✨ Итоги подведём 17 января

Спасибо, что вы здесь, что думаете и развиваетесь вместе со мной ❤️

👇 «Участвовать»

Участников: 198
Призовых мест: 34
Дата розыгрыша: 23:59, 17.01.2026 MSK (завершён)

Победители розыгрыша:
1. Александр - 4mnl35
2. Виктория - 4q3o3e
3. Илья Борисов - 4mnbbi
4. Ildar Khakimov - 4n4dk7
5. Danil Shadrin - 4mu9on
6. Angelina - 4psrvd
7. Виктор Васькин - 4mov0a
8. Roman Karlov - 4mnjmb
9. Manalassa - 4q5d4u
10. ❤️Дмитрий 🍀Андреевич - 4q41lk
11. Айнур - 4mvi2f
12. Dmitrii Koval - 4n3hcm
13. Слаик - 4oq3no
14. Blaizer - 4ps85t
15. RomanTsarkofff - 4mve66
16. DamirLut - 4mniom
17. Maxim Vasilyev - 4mo32d
18. Илья Шишкин - 4pimge
19. Евгений - 4mo32a
20. arsenii - 4mng3r
21. Дмитрий Большаков - 4mng7j
22. Маришка👾 - 4mo25b
23. Ivan - 4mnede
24. (Д)Иван - 4mqfkq
25. LiuGong CLG 920E - 4mo080
26. Иван - 4mnf1h
27. StounhandJ - 4mp928
28. Sergey Komarov - 4mnict
29. Ivan - 4mnh3b
30. Aleksey - 4mnpsh
31. Programmist - 4mo7e2 (переразыгран)
32. Тим - 4mnpc8
33. Vasporelya - 4q6qsv
34. Ruslan - 4mpfud

😎😎 Тайны компилятора и истории Go | Полное руководство

Задумывались ли вы когда-нибудь, почему Go именно такой, каким мы его знаем?
Почему компиляция такая быстрая?
Почему нет встроенной векторизации?

Более того, похожие вопросы нередко задают на собеседованиях, например, про устройство inlining'a или escape analysis.
При этом видео и статей про это очень мало.

В этом видео я прошёлся по истории Go. Начиная от Bell Labs и Plan 9, заканчивая первым релизом языка. Подробно показал внутреннее устройство пайплайна компиляции и на практике скомпировал программу с помощью go tool compile и go tool link, заглянув во все внутренности.

Верю, что будет полезно даже тем, кто пишет не на Go.

❤️ Приятного просмотра!

▶️ YouTube
📱 VK Видео
⚫️ Дзен
🟣 Rutube

🙂 ПАНЕЛЬ УПРАВЛЕНИЯ 🙂

😁😁 Новый сборщик мусора в Go 1.26! Полное руководство про GC

Готовлю новогодний розыгрыш, анонс которого будет уже совсем скоро.

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

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

В новом видео полностью разобрал сборщик мусора. Начиная от фундаментальной идеи и исследований, заканчивая использованием, оптимизациями, тонкостями и нововведениями в Go 1.26. Приятного просмотра!

▶️ YouTube
📱 VK Видео
⚫️ Дзен
🟣 Rutube

🙂 ПАНЕЛЬ УПРАВЛЕНИЯ 🙂

🫡🫡Мы начинаем

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

Для тех, кто хочет чего-то большего — завтра стартует второй поток моего курса The Nature of Concurrency. Он не только про Go, но для этого языка он особенно актуален, ведь почти на каждом собеседовании спрашивают что-то про concurrency.

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

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

До старта осталось менее 24 часов. Нас уже 17 человек, осталось 4 места.
Буду рад тем, кто готов присоединиться 👉 здесь

❤️ Для тех, кому хочется под вечер поразмышлять о смысле жизни)
https://t.me/igoroutine_speech/15

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

😎😎 Убийственная задача с собеседования в UzumMarket

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

Говоря про Go, почти каждое собеседование содержит задачи с concurrency. Пример одной из задач:

«Необходимо написать собственный sync.Once»

func (o *Once) Do(f func())

Проще говоря, если две горутины вызывают Do(f1) и Do(f2), по итогу только одна из функций должна выполниться, даже если f1 == f2.

Попробуем реализовать:

❗️STOP 😱😱😱
Здесь 97% кандидатов уже проиграли, даже не начав писать код. И не потому, что не знают sync.Once, а потому что не умеют задавать вопросы и уточнять требования. Ведь корректность реализации примитива синхронизации, прежде всего, зависит от его контракта. Смотрим, что дальше

Наивная реализация выглядит так:

if o.done.CompareAndSwap(0, 1) {
 f()
}

Заходим в исходники Go и видим:

// Note: Here is an incorrect implementation of Do:
//
// if o.done.CompareAndSwap(0, 1) {
//  f()
// }

Почему так? Потому что изначально контракт sync.Once предполагает, что:

In the terminology of the "Go memory model", the return from f "synchronizes before" the return from any call of once.Do(f).

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

Корректная реализация выглядит так:

...
if !o.done.Load() {
    o.doSlow(f)
}
...

func (o *Once) doSlow(f func()) {
    o.m.Lock()
    defer o.m.Unlock()
    if !o.done.Load() {
        defer o.done.Store(true)
        f()
    }
}

Этим тонкостям на канале посвящено отдельное видео, там в том числе разбирается реализация sync.Once с примерами возникающих проблем. Более того, стала доступна запись выступления на GolangConf-X-2025, где подробно рассказывается про модель памяти.

Если же у тебя есть желание повысить свою компетентность, чтобы не попасть в те самые 97%, второй поток 🍀 The Nature of Concurrency начнётся уже на следующей неделе, успевай, пока ещё остались места

🍀 Время это иллюзия?

🙄🙄 Что же такое время? Мы часто оперируем этим понятием в наших приложениях, но откуда вообще наш компьютер знает точное время?

Всё началось ещё давно, когда морякам необходимо было знать точное время, чтобы определить точное местоположение корабля в океане. Это связано с принципом долготы — одной из двух координат на Земле. В 1731 году изобрели хронометр, который надолго стал золотым стандартом на море. В современном мире используют спутниковые системы (GPS).

Но как же наши компьютеры понимают, сколько сейчас время? В каждом компьютере есть маленький чип — Real-Time Clock (RTC). Он работает даже тогда, когда устройство выключено. Но есть проблема в том, что RTC не очень точный, за минуту дрейф может составлять миллисекунды, а за дни и недели — уже секунды и больше.

Для решения этой проблемы был придуман Network Time Protocol (NTP). Операционная система почти всегда периодически синхронизирует время через интернет. Но откуда те, с кем мы синхронизируемся, знают точное время, как они его считают?

Существует международное атомное время (TAI - International Atomic Time). Оно равняется средневзвешенному времени цезиевых часов из разных лабораторий, с поправками на локальную разницу гравитации. Через GPS атомные часы калибруются по отдельности через положение GPS-спутников. Сами атомные часы завязаны на факт, что одна секунда равна времени, за которое атом цезия-133 совершает 9_192_631_770 переходов между энергетическими состояниями, там всё неочевидно, оставим эти вопросы физикам)

Но где же здесь всем знакомый UTC (Coordinated Universal Time)? На самом деле UTC — это шкала, которая идёт почти как TAI, но периодически в неё вставляют високосные секунды, чтобы не убегать от астрономического времени. Поскольку Земля со временем вращается медленнее, «солнечные сутки» постепенно расходятся с атомным временем. Поэтому международная служба времени (каких служб только не придумают) вставляет лишнюю секунду, чтобы синхронизировать шкалы. Таким образом, можно было увидеть время:

23:59:60 <- вставленная секунда 😎😎

Так делали 27 раз, начиная с 1972 года. Високосная секунда кажется мелочью — всего одна лишняя секунда. Но на практике 30 июня 2012 года она вызвала крупные сбои по всему миру: в интернете, авиакомпаниях, дата-центрах, базах данных, Linux-серверах и даже в платежных системах. В частности, в ядре Linux был баг в обработке таймеров, и при вставке секунды некоторые таймеры начинали бесконечно перезапускаться, загружая CPU на 100%.

Эта секунда так всех достала, что в ноябре 2022 года на 27-й Генеральной конференции по мерам и весам было принято решение отказаться от дополнительных секунд к 2035 году или ранее))

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

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

Но что делать, если нам нужно точное время между разными компьютерами? Например, базам данных критично получать точное время для выбора меток при реализации распределённых транзакций с уровнем изоляции snapshot isolation (MVCC).

Эту проблему решают специальными чипами с атомными часами, например, Chip-Scale Atomic Clock (CSAC), который можно купить за +- 5.000$. Далее такую аппаратную поддержку используют в time server'ах, с помощью которых приложение может получить "интервал доверия" для текущего времени — диапазон, в котором оно почти наверняка находится. Сами серверы бывают разные (master, slave), соответственно, с разной точностью.

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

🙄🙄 Есть ли смысл в CPU-bound сoncurrency?

Мы все видели таких коллег 😎😎 — только что изучили горутины, и сразу решили «распараллелить всё!» Особенно так любят делать новички:

«Оо, я недавно изучил пакет unsafe и concurrency, сейчас распараллелю вычисления в этом запросе и уберу лишние копии».

В лучшем случае код становится менее читаемым.
В худшем — станет медленнее 🫡🫡

Как однажды сказал Дональд Кнут — один из отцов информатики:

«Преждевременная оптимизация — корень всех зол»

Особенно наглядно это работает для CPU-bound задач — например, сложение матриц, хэширование, кодирование. Интуитивно кажется, что «больше горутин = быстрее», но это ловушка.

Закон Амдала отлично иллюстрирует, насколько сложно получить ускорение в этом случае. Например, при 60% параллельного кода разницы между 100 и 1000 ядрами практически нет 💔. В задаче из поста выше ответ по формуле 5.263.

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

BenchmarkAdd/par/w=1-12        168
BenchmarkAdd/par/w=10-12       776

При этом важно понимать, что с IO-bound задачами всё иначе — там другие принципы и прирост может быть на порядки выше.

Кстати, как раз сегодня на канале вышло видео про устройство атомиков и распараллеливание CPU-bound задач.

Если же хочется разобраться в этих принципах глубже, 25 ноября стартует 2 поток курса The Nature of Concurrency. Это системное погружение в базу многопоточности: от устройства атомиков, мьютексов до модели памяти, устройства race detector'a и lock-free алгоритмов.

Курс закрывает 100% вопросов про Concurrency на собеседованиях, видеоотзывы можно посмотреть на сайте. В честь распродажи 11.11 до конца недели действует скидка на PREMIUM тариф, на нём есть возможность поработать со мной 1 на 1, осталось всего 2 места.

00:00 Канал Igoroutine Speech, зачем он появился
02:15 Нейросети, правда ли, что нейросети всех заменят
03:50 Правда ли, что наличие доступа к информации даёт преимущество?
07:00 Есть ли смысл учиться что-то, если скоро AI всех заменит?
10:20 Что спрашивают на собеседованиях про AI
11:55 Что будет, если заменят программистов?
14:25 AI усиляет высокую компетентность и ослабляет низкую
17:50 Самая выигрышная стратегия с нейросетями
19:20 Базовые принципы позволяют быстрее осозновать факты c помощью AI

@igoroutine_speech