🧙 Меня разоблачили!

https://habr.com/ru/articles/888384/

Шучу, конечно. Антон Зиновьев не поверил в мою гипотезу по поводу количества тредов (которые, якобы, создаются заранее на всякий случай) и провёл целое расследование, которое лишило его сна 😩

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

————

p.s. Если уж интернет дискуссии, то только такие, пожалуйста — вежливо, этично, профессионально. Антону большое спасибо за то, что закрыл этот пробел в моём повествовании. ❤️

🧙 Трейдофы в проектировании систем — почему не бывает бесплатных оптимизаций

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

Обложка к этому посту сама по себе тоже отличный пример трейдофа 👍

В проектировании любых систем не бывает бесплатных оптимизаций — это почти всегда трейдофы. Что это значит? Когда мы улучшаем одну характеристику системы, мы неизбежно жертвуем чем-то другим. Это как закон сохранения энергии, только для инженерных решений.

Вот вам несколько примеров:

1. CPU vs Память

- Оптимизируем работу CPU, кэшируя результаты в памяти → растёт потребление RAM
- Экономим память, перевычисляя значения вместо хранения → растёт нагрузка на CPU

2. Скорость vs Надёжность

- Ускоряем работу, убирая проверки и валидации → снижаем отказоустойчивость
- Повышаем надёжность через репликацию и различные проверки → замедляем систему

3. Латентность vs Пропускная способность

- Уменьшаем время ответа отдельного запроса → теряем в общем количестве обработанных запросов
- Оптимизируем для обработки большого числа запросов → отдельные запросы могут ждать дольше

4. Простота vs Гибкость — моё любимое ❤️

- Делаем систему максимально простой → теряем возможность подстраиваться под разные случаи
- Добавляем гибкие настройки и возможности → усложняем систему и её поддержку

5. Масштабируемость vs Сложность

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

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

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

Попробуйте каждый раз задавать себе вопрос — "Что я теряю, добавляя это улучшение?". Если ответ "ничего" — скорее всего, вы что-то упускаете.

————

Полезные материалы:

- Статья Microservice Trade-Offs Мартина Фаулера
- Книга "Designing Data-Intensive Applications" (наш любимый "Кабанчик") — конечно же, там очень рассказано на эту тему
- CAP-теорема — классический пример трейдофа в распределённых системах. Если вы с ней не знакомы, поищите хорошие материалы и ознакомьтесь — поверьте, оно того стоит (кстати, давно думаю сделать о ней ролик и/или статью)
- Ну и классическое — No such thing as a free lunch

#guide

🤓 Гайд по планировщику — теперь и в текстовом формате

https://habr.com/ru/articles/891426/

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

Хотелось, чтобы всё получилось идеально — каждая формулировка, каждая картинка 😩

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

Я не шучу, основная мотивация для написания такой статьи и публикация её в открытом доступе — она должна хорошо зайти на Хабре. Иначе усилия не будут оправданными.

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

Мы побеждаем, но сдаваться рано! Статья в топ-5, но она ещё не №1

И пока даже не побит рекорд предыдущей статьи 🔨

🦄 Все вместе популяризируем Go, получается? Когда ещё на хабре нишевая статья по Go была №1 в рейтинге?

Но это пока только рейтинг "за сутки". В рейтинге "за неделю" ставки уже выше. Так что, отдыхать пока рано!

В любом случае, всем спасибо за поддержку, усилия оправдались!
❤️❤️❤️

👴 О, оказывается моя статья стала 2-й по популярности по Go тематике за всё время.

Думаю, ещё есть шансы попасть на 1-е место и навсегда остаться в истории, ведь прошло всего 3 дня из 30-ти (голосовать за посты можно только в течение 30 суток после публикации, после этого рейтинг фиксируется).

UPD: а вот и Топ-1 за неделю взят (по всем категориям)

Я, конечно, верил в неё, но не думал, что настолько хорошо зайдёт

А вы всё ещё не верите, что ИИ захватит мир?

Этот стикер — пара минут работы с новой фичей ChatGPT

🦄 А тут ещё немного поигрался, результаты просто огонь!

👩‍💻 Ладно, придётся объяснить слишком сложную шутку

Если кратко: на картинке изображён слон, безуспешно лепящий наследование из struct’ов и embedding'ов — когда нет ООП, но очень хочется

Это сюжет про людей, которые переходят в Go из PHP, но ещё не отвыкли от ООП и пытаются готовить Go как привыкли. Это абсолютно нормально, у меня самого путь был такой: <всякое разное> -> Java -> PHP, так что мне тоже было больно ломать в голове эти парадигмы, но оно того стоило.

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

Я и сам таким грешил в самом начале, и часто видел потом на код-ревью.

Конечно, со временем всё это выветривается и прививаются хорошие правильные подходы, но только при условии качественного код-ревью в команде. Иначе есть риск и дальше плодить "франкенштейнов".

Если хотите, я могу написать более подробный пост про "Композицию VS Наследование".

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

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

Эту надо объяснять? 😩

Обсуждаем с моим другом Растиславом важные изменения в языке ❤️