Николай Тузов

🎓 Тестовый собес с Go Senior из Гамбурга, ex-Yandex и ex-Uzum

Когда: четверг, 8 октября, 19:00 МСК, онлайн.

Интервьюер — Маруф Караев, Senior Software Engineer в Гамбурге. До этого работал в Yandex и Uzum.

Как это будет:

- Маруф задаст разработчику-добровольцу вопросы и задачи со своих реальных интервью. Заранее их никто не знает

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

- В конце можно задать Маруфу любой вопрос

Эфир проходит в рамках менторской программы ШОРТКАТ для Go-разработчиков, которые хотят сменить работу и вырасти в грейде и зарплате.

Регистрация через бота @shortcut_go_bot. После неё пришлют файл с ответами на 50 вопросов с Go-собесов.

#промо #текст_прислан

😐 Ультимативный разбор... Go 1.27?

Честно, не знаю зачем я это сделал, но я сделал.. Ну почти.

https://golang.guide/go-1-27/

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

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

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

- Дженерик-методы, которые десять лет обещали не добавлять
- Новый движок JSON v2
- Пакет uuid наконец-то в стандартной библиотеке
- Детектор утечек горутин, который переиспользует сборщик мусора — на мой взгляд, самое красивое, что есть в этом релизе

Во вторую половину войдут: постквантовые подписи, рантайм, net/http, SIMD и тулинг. Это я дописываю прямо сейчас, оно появится в той же статье.

Все код-сниппеты запускаются прямо из статьи на актуальном go1.27. Каждый из них можно редактировать и экспериментировать — не нужно открывать отдельный плэйграунд. А ещё я подготовил для вас наглядный виджет с демонстрацией механики работы детектора утечки горутин.

Я потратил на эту статью ОЧЕНЬ много времени. Возможно, стоило потратить на более фундаментальный гайд — тот же GC, над которым я также сейчас работаю. Но надеюсь, вам всё же понравится ❤️
Стоит ли писать подобные обзоры про новые релизы?

————

А ещё я прикрутил к сайту email-рассылку (и письмо про Go 1.27 туда ушло сильно раньше этого поста) и комментарии к статьям. Если вдруг заметите какие-то баги, пишите в комментариях, постараюсь оперативно поправить.

И не хулиганьте в комментариях на сайте! 👍

#article #go1_27

В последние дни работаю чуть ли не по 16 часов над этим проектом — мой перфекционизм не даёт мне покоя. Делаю одну правку, и тут же ещё десяток идей возникает в голове.

Сейчас мне всё более-менее нравится, второстепенное отложил на потом.

Планирую сделать релиз завтра в первой половине дня. Ну, я надеюсь на это 😩

🏔Большая Алматинская Кругосветка — собираем группу

Я планирую ещё раз сходить в поход по горам Алматы, по тому же маршруту (подробнее здесь). В этот раз пойдём группой из одних только гоферов 🔨 (не считая гида). Группа практически собрана, осталось 2-3 свободных места.

🟢Если хотите присоединиться, оставьте заявку здесь

Когда: ориентировочно начало или середина августа. Точные даты согласуем вместе, когда группа полностью соберётся.

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

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

Экипировку придётся покупать / искать самостоятельно, но мы с этим поможем — будет общий чат, плюс перед выходом вместе сходим в туристический магазин в Алматы и купим все необходимое. Из дорогого — палатка, хороший рюкзак и спальный мешок. Что-то из этого можно будет взять в аренду у гида, будем смотреть по ситуации.

Особенно будем рады местным алматинцам, которые тоже хорошо знают этот маршрут ❤️

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

————

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

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

По мотивам 'https://t.me/ntuzov/898?comment=23329' rel='nofollow'>комментариев

🖥 Виртуальная vs Физическая память

Продолжаем говорить про память. В прошлых постах мы спроектировали Stack и Heap. Но то была картина изнутри программы. Теперь поднимемся на уровень выше и посмотрим, как всё это выглядит со стороны ОС.

————

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

Попытка 1: Нарезаем RAM — прямой доступ

Самое простое решение — поделить физическую RAM на кусочки: программе A отдадим адреса 0x0000–0x1000, программе B — 0x1000–0x2000, и так далее.

На первый взгляд, всё работает, но... Сразу же вылезает огромный букет проблем.

1. Безопасность: Что мешает Программе А обратиться к адресу программы Б и прочитать пароли из её памяти? Ничего. А если она туда что-то запишет, то Программа Б просто сломается.

2. Изоляция и адресация: Компилятору нужно заранее знать, по каким адресам будут лежать переменные, чтобы скомпилировать код. Но мы не можем заранее знать, какие физические адреса будут свободны в момент запуска программы 🗿

🟢Очевидно, что напрямую пускать процессы к железу нельзя. Думаем дальше.

Попытка 2: Иллюзия одиночества — базовый адрес и граница

Что ж, забираем у программы прямой доступ к адресам. Мы всё ещё будем присваивать ей какую-то область, но адресуем сами. То есть, каждая программа будет думать, что ей доступна вся доступная память: от 0x0000 до capacity. К примеру, [0x0000, 0x1000]. Мы же просто добавляем соответствующее смещение и следим, чтобы программа не вылезала за свои пределы.

Допустим мы выдали программе диапазон [0x3000, 0x4000]. Сама она при этом работает с адресами [0x0000, 0x1000]. Когда программа обращается к ячейке 0x0050, мы просто добавляем к ней смещение +0x3000 и получаем адрес: 0x3050. А если она просит больше, чем ей доступно, выдаём ошибку.

Это уже лучше! Но вылезает ещё более коварная проблема — фрагментация.

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

Далее мы закрываем половину этих программ, чтобы освободить место для одной тяжёлой программы. И вот проблема: мы освободили 250 кусочков по 2мб, но они разбросаны рандомно по всему пространству! И у нас нет ни одного свободного промежутка хотя бы в 100мб:

[== Физическая память 1 ГБ ==]

1. Память забита (по 2 МБ):
|█|█|█|█|█|█|█|█|█|█|█|█|█|█|█|

2. Закрыли половину (ДЫРЫ):
|█| |█| | |█|█| |█| |█| | |█|█|
^ ^ ^ ^ ^ ^ ^
2мб 2мб 4мб 2мб 2мб 4мб 2мб

(Суммарно места много, но оно
разбито на мелкие куски)

3. Нужен цельный кусок 100 МБ:
Требуется: |██████████|
Результат: ОШИБКА! Не влезает...

Попытка 3: Страничная организация (Paging)

Очевидно, нам нужно уметь из мелких кусочков собирать большие. Давайте будем нарезать память на одинаковые мелкие кусочки — страницы (обычно по 4 КБ), а затем маппить запрошенные программой адреса с реальными через специальную таблицу (Page Table).

То есть, ОС будет вести полный учёт — кому какая страница принадлежит и правильно сопоставлять адреса с помощью таблицы

Программа же не догадывается об этой машинерии — она всё так же работает в своём виртуальном диапазоне, [0x0000,0x2000]. Например:

1. Программа пишет по адресу 0x1050

2. ОС смотрит в таблицу и сопоставляет: виртуальный адрес 0x1050 с физическим 0x8A3050

Что это нам даёт?

Безопасность: у каждой программы своя таблица страниц — свой изолированный мир. До чужой памяти физически не дотянуться, а попытка вылезти за пределы своего пространства — ошибка. Привет, Segmentation fault! 👍

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

Готово?! Да, концептуально оно работает, но есть нюанс.. 👀

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

#guide #memory