Zig 0.16 переизобрёл async I/O: теперь без «раскраски» функций и лишней головной боли
Новая версия Zig избавляет async I/O от главного проклятия — функции больше не нужно красить в синий или красный, чтобы быть асинхронными.
Разработчики Zig готовят релиз 0.16, который обещает окончательно похоронить одну из самых раздражающих проблем асинхронного программирования — так называемую «раскраску функций» (function coloring). Если вы когда-нибудь писали на JavaScript или Python, то знаете этот ритуал: сначала пишешь async, потом везде await, а потом ловишь ошибку «sync function in async context». В Zig решили, что хватит — их новый механизм async I/O работает без явного разделения на синхронные и асинхронные функции.
Суть в том, что Zig 0.16 вводит концепцию «бесцветных» функций: компилятор сам определяет, нужно ли выполнять операцию асинхронно, глядя на контекст. Разработчику не нужно ставить метки — код выглядит как обычный синхронный, но при этом не блокирует поток. Это как если бы вы заказали пиццу, а курьер сам решил, ехать на машине или на велосипеде, лишь бы доставил горячей.
Под капотом всё построено на стековых корутинах и специальном планировщике, который вшит в runtime. Важно, что Zig остаётся языком без обязательного runtime — async I/O становится опциональной фичей, которую можно включить для конкретных модулей. Никаких накладных расходов, если вы пишете просто for и malloc.
Конечно, пока это только кандидат в релиз, и разработчики предупреждают: API может поменяться. Но если всё пойдёт по плану, Zig может стать первым языком системного уровня, где async — это не боль, а инструмент. Никаких больше «асинхронных» и «синхронных» функций — только код и компилятор, который разруливает.
Комментарий студии METABYTE
Как разработчики, мы знаем, что async I/O часто превращает код в клубок из колбэков и стейт-машин. Если Zig действительно сделает это прозрачным, мы первые запишемся в бета-тестеры для наших высоконагруженных проектов. Главное, чтобы компилятор не начал принимать решения за нас — а то вдруг решит, что нам не нужен await на критическом участке?