Если список литературы по Go на лето уже прочитан, пора переходить от теории к живым кейсам. 23 июля собираемся в Москве и онлайн на встрече Go-сообщества от YADRO и Postgres Professional. Начинаем в 19:00 — подключайтесь к трансляции и слушайте тех, кто работает с Go каждый день.
Игра «Жизнь», придуманная Джоном Конвеем в 1970 году, до сих пор не теряет популярности. В 1984 году американский математик Билл Госпер опубликовал статью с алгоритмом, позже названным HashLife, ускоряющим симуляцию в триллионы и больше раз. Описание алгоритма и его реализации довольно сложны для понимания и отладки. Я хочу вам представить его версию, реализация которой на питоне влезает на один экран, а суть умещается в 40 строк кода. Если вам это интересно, а также то, как HashLife связан с динамическим программированием, персистентными структурами и системой контроля версий Git, добро пожаловать под кат.
Go часто называют простым языком. Но простота синтаксиса не отменяет конкурентности, рантайма, сборщика мусора, интерфейсов, особенностей памяти и реального production-опыта.
Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Владимиром Балуном — разработчиком на C++ и Go, автором YouTube-канала «Владимир Балун» о программировании и основателем школы программирования.
В этом выпуске мы разбираем, почему Go стал таким востребованным, кому он подходит, как на него переходить, а также сильные и слабые стороны языка. Обсуждаем реальные проекты, особенности конкурентности, память, сборку мусора и production-опыт.
Работая в IT и общаясь с разными специалистами, я заметил интересную вещь: собеседования часто воспринимаются как объективная проверка знаний, хотя на практике ими управляет множество человеческих факторов.
Эта статья - попытка показать другую сторону процесса найма и объяснить, почему результат собеседования не всегда является показателем уровня разработчика.
Императивные эффекты (direct-style effects), также известные как «алгебраические эффекты» и «обработчики эффектов», — это следующий шаг в развитии языков программирования. Сначала мы обсудим проблему и связанные с нею ограничения. Затем рассмотрим простую реализацию на Scala 3 и опишем языковую особенность, которая её обеспечивает — контекстные функции. Далее мы увидим некоторые недостатки этой реализации и посмотрим, как их можно решить с помощью двух языковых особенностей: одной хорошо известной (ограниченные продолжения) и одной, находящейся в разработке (нововведения в системе типов).
Меня заинтересовал новый плагин DB Client, который идёт в составе OpenIDE. Давайте посмотрим, может ли он уже на текущий момент стать достойной альтернативой платному DataGrip? Я не предъявляю каких-то узкоспециальных требований к таким инструментам. В основном требуется писать и оптимизировать sql-запросы, просматривать структуру таблиц и диаграмму связей между ними, просматривать актуальный DDL, выполнять мелкие правки данных “на лету”, а также делать импорт и экспорт данных в различных форматах. Давайте по этим пунктам и пройдёмся.
PostgreSQL 19 добавляет SQL/PGQ (Property Graph Queries, запросы к графам свойств) на основе стандарта SQL:2023. Графовые структуры можно определить поверх уже существующих реляционных таблиц и запрашивать их синтаксисом сопоставления с образцом. Не нужны новый движок хранения, расширения или миграция данных.
Эта история началась не с продуктовой сессии, не с исследования рынка и даже не с запроса заказчиков. Отправной точкой стала встреча с коммерческой командой.
Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией MULTISTATUS — сервиса геораспределённого мониторинга доступности веб-ресурсов.
В результате появился инструмент, который сначала помогал демонстрировать продукт заказчикам, а затем оказался полезен и для задач информационной безопасности. Рассказываем, как это произошло и как в этом помогла бот-ферма одного из разработчиков.
Иногда бывает так, что день проходит спокойно. Ни тебе без дедлайнов, ни горящих сроков, ни суеты. Работу поработал, никто не дергал, может, даже получилось пораньше закрыть ноутбук. И вот кажется, что сейчас хорошенько отдохну. Но тут подключается бытовуха. Надо что-то приготовить как минимум. А для этого сперва надо понять, есть ли нужные продукты. А еще закинуть стирку, поотвечать на сообщения в личке, разобраться со всякими домашними мелочами, которые уже сто лет откладываются и откладываются на потом. И вот ты вроде ничего сложного не делал, но силы почему-то кончились.
Домашние задачи – они такие обманчивые. Выглядят ведь пустяковыми, по сути. Ну вот, например, приготовить ужин - звучит как одно действие. А в реальности это может быть десяток шагов. Вспомнить, что есть дома из съедобного, сравнить варианты, определиться наконец, что все-таки готовить, решить, надо ли идти ли в магазин и докупать, оценить время, начать готовить, параллельно с этим ты еще что-то прибираешь, отмываешь, а потом еще с посудой разобраться. И ты часто недооцениваешь всю эту нагрузку. Точно так же, как бывает и с рабочими задачами, пока не углубился в них и не столкнулся с деталями.
Почти каждое бытовое действие - это набор маленьких решений. Что надеть, что приготовить, когда стирать, сделать сейчас или отложить. Встречалось мне в психологической литературе такое понятие - усталость от принятия решений (Рой Баумайстер). Смысл в том, что ресурс на принятие решений ограничен, как у батарейки, и по мере его расходования нам становится сложнее выбирать и держать фокус. На уровне повседневных задач, как мне кажется, он проявляется довольно ярко. К вечеру даже простой выбор из двух вариантов начинает раздражать.
Открой свой Spring-проект, которому больше двух лет. Найди пакет common, core или framework — а он там есть, я почти уверен. Загляни внутрь.
Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.
Поздравляю: ты написал фреймворк. Свой, внутренний, недокументированный (себя-то не обманывай), поддерживаемый одним человеком (который уже собеседуется в другую компанию). И построил ты его ровно для того, чтобы не брать «тяжёлый и навязчивый» opinionated-фреймворк — ты сделал это «ради контроля».
Давай честно поговорим про этот контроль.
Несколько лет назад в закон «Об информации...» (149-ФЗ) добавили требования к способам авторизации пользователей.
Многие тогда обратили внимание на новость, но практических последствий почти не было — ответственности за нарушение не существовало. Если не штрафуют, значит скорость +19,9 км/ч разрешена ;)
Теперь ситуация изменилась - с июля 2026 года появилась административная ответственность, а штраф для юридических лиц 700 000 рублей.
Почитал новости, комментарии, пообщался с коллегами - оказалось, что не все до сих пор разобрались.
Например мы обсуждали:
Привет, Хабр!
#[derive(Serialize, Deserialize)] это какая-то одна строка в коде. На холодной сборке за ней прячется двадцать с лишним секунд компиляции, даже если в проекте больше ничего нет. Откройте cargo build --timings на любом не самом маленьком проекте с serde, и serde_derive почти наверняка окажется в первой тройке самых медленных крейтов. При том что в самом serde_derive всего несколько тысяч строк.
Между этой строкой и этими секундами лежит вся инфраструктура процедурных макросов: TokenStream, syn, quote, proc-macro2, watt. Пройдёмся по ней в этой статье.
Типичная умная колонка с Алисой — это скромное железо и совсем немного оперативной памяти: у младших моделей её всего 256 МБ на всё устройство сразу. И за каждый мегабайт идёт настоящая борьба между множеством команд и компонентов: бизнес‑логикой, обработкой звука, локальными нейросетями.
Ежедневно мы собираем и анализируем memory‑дампы с миллионов колонок — нам важно понимать, куда уходят эти драгоценные мегабайты.
Меня зовут Сергей, я работаю в команде, которая пишет прикладной код на C/C++ для умных устройств с Алисой (например, колонок, телевизоров и автомобилей). Под катом расскажу, как мы построили и используем инструмент для анализа потребления памяти в проде на нашем флоте Linux‑колонок.
В предыдущем посте мы спроектировали CPU. Я определился с набором команд, написал ассемблер, проверил каждый опкод и создал процессор, работающий в кремнии (или, точнее, в FPGA Altera Cyclone II EP2C5T144C8, что тоже довольно близко). Но у нас пока нет осмысленного ПО (микрокода калькулятора) для запуска на «железе».
В этой части проекта оправдали себя все эксперименты с прототипами на C++, описанные в частях 2 и 3.
Когда я начал писать addsub.asm (самую первую команду, которую я портировал), то не смотрел на пустую страницу, задаваясь вопросом, как работает BCD-сложение. У меня уже имелась эталонная реализация на C++ (addsub.cpp в проекте Proto), верифицированная на тысячах тестовых векторов. Алгоритм был известен, пограничные случаи найдены и охарактеризованы. Я проработал поведение защитного разряда и бита фиксации. Оставалось лишь транслировать это всё на язык ассемблера; задача всё равно сложная, но совершенно иного уровня сложности, нежели изобретение алгоритма в процессе его написания.
Я хотел бы сделать упор на этот двухэтапный процесс, потому что может показаться, что без него можно обойтись. Написание кода прототипа на C++ с последующей ручной трансляцией на язык ассемблера кажется избыточной и долгой работой. Однако она перестанет казаться избыточной к моменту, когда вы будете отлаживать неочевидный пограничный случай округления в 16-ниббловом BCD-вычитании. Наличие золотого эталона, с которым можно выполнять сравнения, не избыточно: это единственное, что стоит между вами и неделями кропотливого труда или даже провалом проекта.
Недавно, 11 июля, в Питере, проходила летняя конференция ProIt Fest 2026. Ожидания не были оправданы, но в этом случае даже лучше: особых ожиданий не было, а получилось гораздо насыщеннее и интереснее.
Помимо повода сменить обстановку на выходных была возможность пообщаться с интересными людьми и немного прокачаться в архитектуре.
Вызов LLM легко принять за обычную функцию — пока код не сталкивается с квотами, тайм‑аутами, повторными списаниями и плавающими результатами.
В статье разбираем пять типичных ошибок в Python‑коде вокруг языковых моделей и показываем, какие инженерные привычки помогают пережить реальную нагрузку без сюрпризов в продакшене.
Уважаемые читатели, в этой статье я хочу рассказать про поиск по строке и представить свои выводы. Началось с оптимизации: сравнил поиск символа циклом со string.IndexOf — и получил разницу в разы. Заодно выяснилось, что серверный Xeon с AVX-512 в этой задаче медленнее игрового десктопа с AVX2. Ниже разбор обоих фактов с дизасмом и замерами.
Будет четыре истории, и в каждой — вопрос, на который я искал ответ:
Rust-компилятор не просто превращает код в машинные инструкции — он проверяет безопасность программы ещё до запуска. Разбираем, как устроен конвейер компиляции, зачем Rust использует сразу несколько промежуточных представлений (HIR, THIR, MIR) и какую роль во всём этом играет LLVM.
Мы продолжаем праздновать 30-летие PostgreSQL и публикуем перевод второй фундаментальной статьи о СУБД. Перевод первого манифеста можно прочесть в этом посте.
Есть опыт, который не купишь и не прочитаешь. Его можно только пережить. Три недели алгоритмов с нуля, публичный мок в Яндекс Практикуме перед живой аудиторией — и один краевой случай, который расставил всё по местам. Алгоритмы — не основа разработки, но важная её часть. И три недели — не тот срок, за который они становятся частью тебя. Это проявилось на публике, перед аудиторией, когда права на паузу не было.