Одна команда из 10 человек поддерживает SDK сразу для 7 языков, и именно это стало главным аргументом в пользу архитектуры с общим core на Rust. В докладе на QCon San Francisco руководитель SDK-команды Temporal Спенсер Джадж объяснил, почему Rust для SDK оказался не модой на системное программирование, а способом не утонуть в дублировании логики, багах на границах FFI и расхождении поведения между языками.
По данным InfoQ, речь идет не о косметической оптимизации, а о вполне приземленной инженерной экономике. Один только механизм local activity у Temporal упирается в сложную state machine примерно на 800 строк кода, а весь набор таких машин занимает около 7000 строк. В более широком репозитории это уже порядка 70 тысяч строк логики, которую нельзя просто вынести на сервер: она должна жить в клиентских SDK, потому что именно на стороне библиотеки обеспечиваются гарантии durable execution.
Для Temporal это не академическая задача. Продукт продает разработчикам возможность писать обычный код на привычном языке и получать поверх него устойчивое исполнение: повторные запуски, восстановление после сбоев, предсказуемое выполнение долгих процессов. Если такой механизм реализовывать отдельно на каждом языке, компания получает сразу несколько проблем. Первая и главная — надежность. По словам Джаджа, любая ошибка в SDK быстро бьет по доверию пользователей. Вторая — консистентность: если SDK на разных языках начинают вести себя чуть по-разному, продукт фактически распадается на несколько несовместимых версий. Третья — поддерживаемость. Когда несколько инженеров одновременно тянут стек из семи языков, писать одну и ту же сложную логику семь раз уже не героизм, а организационная ошибка.
Отсюда и выбор: общий core на Rust, а сверху тонкие языковые слои с идиоматичным API. Это важный момент, потому что речь не о навязывании пользователям чужой модели программирования. Джадж отдельно подчеркивает, что хороший polyglot SDK не должен выглядеть как грубая прокладка над системной библиотекой. Разработчик на конкретном языке ожидает свои привычные абстракции, свой способ работы с async, ошибками, памятью и объектной моделью. Поэтому общий Rust-core решает тяжелую инфраструктурную часть, а внешний слой адаптирует ее под нормы конкретной экосистемы. Для бизнеса такой подход снижает стоимость расхождения платформ, а для разработчиков означает более предсказуемые библиотеки без ощущения, что им подсунули чужой runtime в родном языке.
Почему именно Rust, а не C или, скажем, Zig? Здесь ответ довольно прямой. Rust дает скорость, переносимость и, главное, память под контролем без традиционного набора ловушек, который несет ручное управление ресурсами. Для Temporal это важно еще и потому, что пользователи запускают SDK на Linux, macOS и Windows, на ARM и x64. Но в докладе есть и менее очевидная деталь: Rust удобен не потому, что умеет магически общаться со всеми языками напрямую, а потому, что достаточно хорошо вписывается в существующую реальность C FFI. У самого Rust нет стабильного ABI, поэтому экспорт функций все равно идет через совместимый с C слой. Иными словами, Rust для SDK не отменяет сложность межъязыкового взаимодействия, а делает внутреннюю часть безопаснее и выразительнее, пока внешний мир по-прежнему держится на старом добром FFI.
И вот здесь начинается самое интересное для практиков. Главная боль polyglot-архитектуры — не просто вызвать функцию из другой среды, а аккуратно пройти через границы моделей исполнения. У каждого языка свое представление об асинхронности, конкурентности и владении памятью. Если на входе у вас Rust future, а на выходе JavaScript Promise, Python coroutine или другой нативный примитив, склейка почти всегда получается хрупкой. Джадж говорит об этом без романтики: FFI-границы приходится проектировать очень осторожно, иначе перенос общей логики быстро превращается в перенос общей боли. Отсюда его скепсис к нативным расширениям как универсальному рецепту. Они помогают переиспользовать код, но создают дополнительную поверхность для проблем с типами, жизненным циклом объектов и отладкой.
Отдельный сигнал из доклада — интерес к WebAssembly как к более аккуратному способу строить кросс-языковую архитектуру. Джадж не продает WASM как готовую серебряную пулю, но фиксирует тренд: по сравнению с классическими native extensions у WebAssembly есть шанс упростить изоляцию, переносимость и взаимодействие между средами. Для рынка SDK это важная оговорка. Много лет схема была довольно бинарной: либо переписываешь одну и ту же бизнес-логику на каждом языке, либо тащишь нативную библиотеку через FFI и миришься с шероховатостями. Если WASM действительно станет удобным промежуточным слоем, часть нынешних компромиссов можно будет снять. Но пока речь скорее о направлении развития, чем о готовом стандарте для всех.
Для русскоязычной аудитории здесь есть вполне прикладной вывод. Если компания делает продукт с клиентскими библиотеками для нескольких языков, разговор о выборе стека надо вести не в жанре нравится ли нам Rust, а в жанре сколько раз мы готовы реализовать одну и ту же сложную логику и как будем удерживать одинаковое поведение SDK. История Temporal показывает, что общий core имеет смысл там, где на клиенте много состояния, много гарантий и дорогая цена расхождения между реализациями. Если же библиотека тонкая и почти вся логика живет на сервере, добавление Rust-слоя может оказаться избыточным. Иными словами, Rust для SDK — это не универсальная религия, а архитектурный выбор, который окупается только при достаточно тяжелой клиентской логике.
Открытый вопрос теперь в другом: станет ли следующей нормой не просто общий core на Rust, а более нейтральный runtime-слой поверх FFI, который избавит команды от ручной сборки мостов между async-моделями, памятью и типами. Для компаний, которые хотят быстро расти в несколько языков сразу, именно эта часть стека, похоже, и станет следующим полем конкуренции.