Разбирая реализации 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тыдно, очень стыдно

Диалоги Платона ATDD

На дворе почти 26 год, а агент от ЖБ отказывается работать с одним из языков ООН