Маркетинг в опен-сурс, который мы заслужили

github.com/mark3labs/mcp-go

Команда Go разрабатывает новый алгоритм сборки мусора — Green Tea 🍵, который радикально меняет подход к разметке памяти. Вместо обработки отдельных объектов он работает с целыми блоками по 8 КБ, но только для маленьких объектов (≤512 байт). Уже есть экспериментальная реализация, и в Go 1.25 её можно будет протестировать.

Сейчас Go использует классический алгоритм трёхцветной разметки, который:

- Не учитывает расположение объектов в памяти, сканирует указатели вразнобой
- Тратит 85% времени на цикл сканирования, из которых 35% CPU-циклов уходят просто на чтение памяти (из-за плохой локальности)
- Плохо масштабируется на системах с десятками ядер и сложной топологией памяти (NUMA, HBM)

Вместо работы с отдельными объектами, Green Tea оперирует целыми 8 КБ (для уменьшения промахов L1/L2) блоками называемыми интервалами, но только для маленьких объектов. Такой фокус на маленьких объектах обусловлен тем, что сборка их новым алгоритмом дает наибольший выигрыш:

- Дешевле сканировать блоками, чем по одному
- Они чаще создают фрагментацию и нагрузку на GC

Крупные объекты обрабатываются старым алгоритмом, чтобы не усложнять логику. Новый алгоритм Green Tea работает следующим образом:

- Каждый 8 КБ интервал хранит битовую маску (серый/чёрный биты) для своих объектов
- Если в блоке появляется новый указатель, он помечается серым, а весь блок ставится в очередь на сканирование
- Когда блок извлекается из очереди, все помеченные объекты в нём сканируются разом

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

Бенчи в целом хорошие:

- CPU-затраты GC снизились на 10–50% в CPU-bound сценариях
- В 2 раза меньше промахов кэша (L1/L2)
- Тесты компилятора Go показывают незначительный регресс (~0.5%)

Oригинал

На мой взгляд, одна из самых красивых идей в программировании — соответствие Карри-Ховарда. Это концепция, которая связывает программирование с логикой, показывая, что программы можно рассматривать как доказательства логических утверждений.

Обычно мы думаем о программах как о способах обработки данных: чисел, списков, функций. Но что, если взглянуть на это с другой стороны? Что, если программа — это доказательство того, что ее тип обитаем? То есть, если программа компилируется, она доказывает, что ее тип не пуст.

Например, рассмотрим простую функцию, которая создает пару:

let pair x y = (x, y)

Тип этой функции:

val pair : 'a -> 'b -> 'a * 'b

Теперь давайте переведем это на язык логики. Тип 'a * 'b соответствует логической формуле A /\ B, где /\ — это конъюнкция (логическое "и"). Таким образом, функция pair доказывает, что если у нас есть доказательства для A и B, мы можем создать доказательство для A /\ B.

Процесс вычисления программы можно рассматривать как упрощение доказательства. Например, рассмотрим функцию, которая меняет местами элементы пары:

let swap (x, y) = (y, x)

Тип этой функции:

val swap : 'a * 'b -> 'b * 'a

В логике это соответствует доказательству того, что если у нас есть доказательство для A /\ B, мы можем получить доказательство для B /\ A. Процесс вычисления функции swap можно рассматривать как упрощение этого доказательства.

Если тема показалось интересной, то в одном из блоков курса cs3110 ждут упражнения на OCaml 🐫

Недавно я наткнулся на интересную поделку — Dockerfile Kotlin DSL. Да, вы не ослышались, это DSL на Kotlin для написания Dockerfile. Сомнительно, но представьте, как это удобно: вместо того чтобы писать Dockerfile в текстовом формате, вы можете использовать Kotlin для создания Dockerfile прямо в вашем Gradle-конфигурационном файле. Вот как выглядит простенький DSL для JVM-приложения:

dockerfile {
    from("openjdk:21-jdk-slim")
    workdir("/app")

    +"Копируем JAR-файл в Docker-образ"
    copy {
        source = "app.jar"
        destination = "/app/app.jar"
    }

    cmd("java", "-jar", "app.jar")
}

Синтаксис выглядит очень похоже на привычный Dockerfile. Это удивительно, как можно минимизировать семантический разрыв между, казалось бы, совершенно разными языками.

Главная мотивация автора — избежать дублирования Dockerfile для разных сред (staging/production). Вместо того чтобы создавать отдельные Dockerfile для каждой среды, вы можете использовать один DSL-файл, который будет генерировать Dockerfile в зависимости от переменных окружения. Например, под разные окружения можно загрузить разные артефакты в образ:

+"Загружаем активы"
val assetPath =
 when (System.getenv("MODE")) {
  "local" -> "/first_100_assets.zip"
  "staging" -> "/compressed_assets.zip"
  else -> "/full_assets.zip"
 }

Это может быть полезно, если вы не хотите засорять ваше приложение if-условиями и фича-флагами, и уже используете Gradle для сборки. Хотя на моей практике был всегда противоположный подоход через if-условия и фича-флаги.

Для меня, Dockerfile Kotlin DSL — это еще один пример того, насколько мощным может быть Kotlin для создания DSL. Он позволяет писать Dockerfile как код, что делает его более гибким и удобным для управления. И это не единственный пример. Есть ещё Exposed — ORM для Kotlin от JetBrains. В ней также удалось минимизировать семантический разрыв между DSL и SQL. Сравните SQL-запрос:

select * from user
where vibe = 'cheel'
 and status = 'active'

с его аналогом на Exposed DSL:

User  
.select { (User.vibe eq "cheel")  
 and (User.status eq "active") }

И это потрясающе. Восхищаюсь командой разработки языка, потому что до этого мир видел подобные DSL на динамически типизированных языках, как Ruby и Groovy. Но чтобы на статически типизированном и без необходимости получать PhD по теории категорий, это впервые 🔥

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

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

Основные компоненты PostgreSQL, затронутые изменениями:

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

- Bitmap Heap Scans: Этот метод поиска данных стал более эффективным благодаря параллельному доступу к индексированным данным.

- Vacuum Operations: Очистка таблиц от устаревших записей также получила ускорение благодаря возможности параллельного исполнения операций удаления.

Эти улучшения были достигнуты именно за счёт внедрения асинхронного механизма, основанного на io_uring. Тестирование показало впечатляющие результаты: улучшение производительности вплоть до 2–3 раз 🔥

Главная причина прироста производительности заключается в устранении задержки при операциях ввода-вывода. Когда PostgreSQL отправляет запрос на чтение файла, процесс блокируется до завершения операции. Но с использованием io_uring база данных продолжает обрабатывать другие запросы, пока идёт операция ввода-вывода. Это значит, что даже самые тяжелые нагрузки на базу данных обрабатываются эффективнее.

Release notes

Friendly error message наше всё. Да, JetBrain?

На днях наткнулся на апрельский маркетинговый ролик от JetBrains, где собрали максимум хайпа: MCP, AI Coding Assistant, IoT приправленный Kotlin, только RAG не хватало. В видео автор вместе со зрителями пишет наык для Алисы MCP-сервер для управления лампочкой через LLM. Понятно, что ролик рекламный, но есть пара моментов, которые меня зацепили, о которых расскажу ниже.

Похоже, JetBrains первыми среди разработчиков IDE догадались сделать интерактивную работу ассистента: LLM сам пишет код, пытается его запустить, пока тесты не станут зелёными. Насладиться можно на отрывке видео.

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

MCP только набирает популярность, а в JVM-экосистеме уже всё готово:

- Официальные SDK для MCP, в отличие от модных Rust и Go, для которых ещё нет SDK.
- Spring AI — для упрощения работы со всем циклом разработки LLM-приложений.
- Официальный плагин MCP в IntelliJ для обеспечения связи между LLM и средой разработки.

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

Админ спустился с дерева

Разбирая реализации MCP-серверов в разных экосистемах, я был впечатлён разницей в объёме кода при схожих характеристиках (статическая типизация, асинхронность, GC). Go-версия занимает 400+ строк, тогда как Kotlin-решение укладывается в 100 строк— и всё благодаря выразительности языка и богатой стандартной библиотеке Kotlin.

В Go-реализации все механизмы синхронизации прописаны явно:

type stdioSession struct {
    pendingRequests map[int64]chan *samplingResponse // Хэш-таблица запросов
    pendingMu       sync.RWMutex                    // Мьютекс для доступа
    requestID       atomic.Int64                    // Атомарный счётчик
}

Каждое изменение shared-состояния требует явной блокировки:

s.pendingMu.Lock()
s.pendingRequests[id] = responseChan
s.pendingMu.Unlock()

В Kotlin аналогичная функциональность достигается проще:

private val pendingRequests = ConcurrentHashMap<Long, Channel<SamplingResponse>>()
private val requestId = AtomicLong(0)

Доступ к ConcurrentHashMap автоматически потокобезопасен:

pendingRequests[id] = responseChannel // Не нужны явные блокировки

Запуск асинхронной задачи в Go с коммуникацией через канал:

go func() {
    response := s.server.HandleMessage(ctx, rawMessage)
    if err := s.writeResponse(response, writer); err != nil {
        s.errLogger.Printf("Error: %v", err)
    }
}()

Эквивалентная логика в Kotlin более лаконична:

scope.launch {
    val response = server.handleMessage(rawMessage)
    writeChannel.send(response)  // Потокобезопасная отправка
}

Исходники:

- на Kotlin
- на Go

После coq продолжаю знакомиться с чудесами Computer Science. На этот раз познакомился со статьей Checking Polynomial Time Complexity with Types за авторством Patrick Baillot, которая посвящена верификации полиномиальной временной сложности программ с помощью систем типов.

В статье используется модифицированная система типов на основе Light Affine Logic, где модальности ограничивают дублирование данных и глубину рекурсии. Это гарантирует, что типизированные программы выполняются за полиномиальное время.

Примеры модельностей:

- ! (экспоненциал) контролирует, сколько раз значение может быть использовано.
- § (мягкий экспоненциал) ограничивает глубину рекурсивных вызовов.

Например, рекурсивные функции проверяются на соответствие линейным и стратифицированным правилам, исключая неконтролируемый рост вычислений. Тип N → §N для функции означает, что каждый рекурсивный вызов уменьшает «глубину» страта, обеспечивая полиномиальную остановку.

В коде такой подход можно проиллюстрировать так:

-- Тип с модальностью §, ограничивающей рекурсию
data § a = § a

-- Функция сложения с контролем глубины
add :: §Int -> §Int -> §Int
add (§x) (§y) = §(x + y)

-- Рекурсивная функция с ограничением через типы
factorial :: Int -> §Int
factorial 0 = §1
factorial n = §(n * un§ (factorial (n-1)))  -- un§ "снимает" модальность

Здесь модальность § гарантирует, что глубина рекурсии factorial ограничена, а время выполнения остается полиномиальным.

На недавнем DDD Europe выступил с докладом Gregor Hohpe — автор книги Enterprise Integration Patterns (да, той самой!). Доклад посвящен инженерии платформ, и красной нитью в нём проходит мысль simple ≠ easy. Ниже приведены основные идеи доклада.

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

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

Ошибка Cadillac Cimarron: Компания попыталась выпустить новый автомобиль на базе существующего, лишь дополнив его несколькими функциями. Однако игнорировала необходимость построения полноценной платформы. Результат оказался провальным, так как машина не обладала уникальными характеристиками, выделявшими её среди конкурентов.

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

Названия элементов должны передавать суть, а не конкретные детали реализации. Название "автомобиль" удачно описывает сущность транспортного средства ("движется самостоятельно"), в отличие от названия "педаль газа", которое привязано к конкретной технической особенности двигателя внутреннего сгорания и несправедливо для электромобилей. Оптимальное наименование — "педаль ускорения".

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

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

Типичное арх.ревью be like

Миллениал вспомнил про мемы

Because request parameters and responses are handled inside route lambdas, the plugin cannot infer detailed request/response schemas automatically. To generate a complete and useful specification, you can use annotations.

Cтыдно, очень стыдно