По сути язык zig лишился одного из своих единорогов - bun. На мой взгляд, это звоночек, но язык может стать лучше, если воспримет это очень серьезно.

Да, zig делает все аллокации памяти явными, и это жирный плюс для низкоуровневого программирования, когда важна каждая наносекунда. К тому же при аллокации сейчас удобно сразу же выставить отложенное уничтожение через defer.

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

Что ждет zig? Если введут defer в язык C (а это уже рассматривают), введут динамические коллекции (массивы, хэшсет, хештаблицы) и добавят режим, который отключит неявные преобразования, а также добавят возможность добавления методов к структурам (без наследования как в zig), модульную систему, и выполнение в compiletime, то zig уже будет не интересен. Сейчас zig от C отличает именно это.

Язык C развивается очень медленно, и время медленного развития уходит в прошлое: развивайся или будешь на задворках legacy и забыт. У языка C может наступить ренессанс, если они возьмут все лучшее у zig, но при этом не допустят их ошибок. Swift показал, что менять язык больно, но не страшно.

А у zig тоже есть будущее, если они будут смотреть на разработку не только с точки зрения теории, но и с потребностей бизнеса - быстро находить и править ошибки (желательно до runtime). По сути - это сейчас главная проблема. Но если язык C реализует все то, что за что любят zig, то это пагубит последний, т к C является королём интеграции с другими системами и языками.