A Brief History of Bjarne Stroustrup, the Creator of C++ (Рубрика #Engineering)

Интересная история Бьярне Страуструпа, датского учёного в области информатики, автор языка программирования C++. Вся история снята в городке Орхус (Дания), где он родился в 1950 году и учился в университете Орхуса, там же получил магистерскую степень. Дальше он защитил PhD в Кембридже, а затем работал в Bell Labs рядом с Керниганом, Ритчи, Моррисом и др.

Ниже интересные моменты про его биографию, не все из которых я знал
- В программирование Бьярне попал "случайно": выбрал направление "математика с датологией", не понимая, что "datologi" - это компьютерные науки
- На него сильно повлиял Кристен Нюгорд (Kristen Nygaard), создатель Simula и концепции объектно‑ориентированного программирования; идеи структурирования кода в Simula до сих пор для него опорные.
- В Bell Labs Бьярне интересовался операционными системами и архитектурой машин и, не найдя подходящего языка, решил "сделать свой".
- Первый вариант языка назывался "C with Classes" - фактически C с классами в стиле Simula; затем название сменили на C++ (оператор инкремента в C), потому что это было "милое и необычное" имя.

Не забыли они обсудить и сам C++, его предназначение и историю развития
- В какой‑то момент Бьярне знал около 24 языков программирования (Snowball, Algol 68, PL/I, PL/360 и др.) - правда, он говорит, что раньше языки было проще изучать, т.к. у них не было огромного "багажа" и экосистемы.
- Бьярне описывает философию C++ метафорой: "я должен был вырастить сорняк, а не розу", т.е. язык, который выживает и растёт без постоянного "полива" автором.
- Особенно гордится тем, что у C++ не было маркетинговой кампании и "спонсора" - язык распространялся органично, через пользу и сообщество.
- Через 10 лет после появления у C++ было уже около миллиона пользователей, а сейчас оценивается порядка 7 миллионов инженеров, использующих язык.

В итоге, я себе отметил моменты
1. Роль случая - это про вход в профессию и что серьёзные карьерные траектории в ИТ часто начинаются не с продуманного плана, а с любопытства и случайного выбора.
2. Сила хороших идей и наставников - это про встречу с Нюгордом и знакомство с Simula и что один сильный ментор и одна сильная идея (ООП в Simula) могут задать направление целому поколению технологий.
3. Создание инструмента "для себя", а не для рынка - это про то, что фокус на реальной инженерной боли, а не на маркетинге, может дать шанс, что инструмент станет стандартом де‑факто.
4. Устойчивость важнее "идеальности" - тут метаформа сорняка говорит о том, что проектирование для реального мира, а не идеальной академической конструкции приводит к тому, что выживает тот, кто успешно работает в проде, а не на бумаге
5. Рост без маркетинга - это про то, что для инфраструктурных технологий органическое принятие и решённые задачи ценнее пиара.
6. Отношение к работе и мотивация - Бьярне продолжает учить, выступать и писать код, потому что ему "просто интересно видеть, как это используется, и приятно общаться с людьми". В итоге, долгосрочная мотивация строится на удовольствии от процесса и ответственности за последствия своей работы.

#Engineering #Software #Management #Leadership #Architecture

The Rise and Rise of FastAPI (Рубрика #API)

Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг

Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически

2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints

3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций

4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.

5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".

Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"

2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне

3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99

4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью

На сайте system-design.space есть чуть более подробный разбор.

#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture