WASI 0.3 — асинхронность стала нативной в WebAssembly Components

WASI 0.3.0 официально опубликован, и асинхронные операции теперь реализованы напрямую в WebAssembly Component Model. Это упрощает код, делает его более читаемым и избавляет от «трюков», которые требовались в версии 0.2.

Как изменилось ввод‑вывод?

В 0.2 ввод‑вывод реализовывался через ресурсы input-stream и output-stream. Для записи требовался императивный поток, а чтение — отдельный запрос poll. В 0.3 функции read-via-stream и write-via-stream возвращают кортеж из stream<u8> и future<result<_, error-code>>. Запись теперь передаётся как поток данных, а завершение операции сообщает future. Это меняет направление потока вывода: вместо получения output‑stream вы передаёте поток и ждёте завершения.

Что стало с сетевыми возможностями?

В 0.2 сеть представлялась ресурсом network, который передавался в каждую функцию bind, connect и т.п. В 0.3 ресурс исчез; доступ к сети предоставляется через импортируемый мир. Все операции (bind, connect, listen, accept) теперь объявлены как async func, а промежуточные состояния (bind‑in‑progress и др.) удалены. Возврат TCP‑пары из finish‑connect заменён обычным result‑значением, а ввод‑вывод работает через методы потока самого сокета. UDP получил аналогичный упрощённый набор функций async send и async receive.

Как выглядит новый HTTP‑интерфейс?

Раньше WASI 0.2 определял восемь ресурсов для запросов, ответов, тел и трейлеров. В 0.3 их сократили до двух: request и response. Тела запросов и ответов теперь просто stream<u8>, а трейлеры — future<result<option<trailers>, error-code>>. Обработчик стал асинхронной функцией handle : async func(request) -> result<response, error-code>. Клиентская сторона использует аналогичный send : async func(request) -> result<response, error-code>. Появились новые миры service и middleware, позволяющие подключать обработчики как отдельные компоненты.

Какие изменения в файловой системе?

Чтение и запись файлов переключились на «stream‑plus‑future» форму. read-via-stream теперь возвращает кортеж stream<u8> и future, а write-via-stream принимает поток данных и тоже возвращает future. Итерация каталогов заменена на поток stream<directory-entry> с завершающим future, что упрощает асинхронный обход.

Что изменилось в типах и названиях?

Небольшие, но заметные переименования: wall-clock → system-clock, datetime → instant. Добавлен общий тип duration = u64. monotonic-clock отказался от subscribe‑instant и subscribe‑duration в пользу ожидания таймера через future. Эти правки в основном касаются согласованности с POSIX и другими экосистемами.

Что это значит для бизнеса?

Благодаря нативной асинхронности разработчики могут писать более лаконичный код, а компоненты быстрее стартуют и требуют меньше ресурсов. Упрощённый сетевой и HTTP‑интерфейсы ускоряют создание микросервисов на WebAssembly, а новые типы снижают риск ошибок при переносе между платформами.