Все листинги есть в GitHub Issues, и их довольно много. "Навскидку" я их не приведу, они мне попадались случайно.Одна из заявленных главных целей - быть быстрее С. Поэтому performance на втором месте.
Например, все значения по умолчанию константы - это позволяет производить дополнительные оптимизации.
Параметры функции могут быть значениями или ссылками - это выбирает оптимизирующий компилятор компилятор.
@Vector для SIMD, а если SIMD не поддерживаются то будет fallback на обычный вектор, т.е. поэлементное сравнение.
inline for, calling conventions можно выбирать для каждой функции.
Там куча всего есть, что делает его именно системным низкоуровневым, чего С и в помине не может.
Про то что SIMD что-то там увеличивает...это конечно требует серьезных пруфов. Жду.
Но никто не заставляет их использовать. Не хочешь - не используй.
И нет, конструкции языка переводятся в инструкции процессору. Если у процессора есть SIMD, который может делать до 8х ускорения, а язык программирования не знает об этом без хаков, для конкретного компилятора... скажем мягко...нет, это не преимущество.
Архитектур которые поддерживает Zig куча. Спасибо LLVM. И нет, это не делает язык более "системным", как вы сказали.
Может для какого-то embedded, и плат нужны отдельные подархитектуры и компиляторы, которых нет в LLVM. Возможно, не знаю. Я не железячник.
Но это либо совсем никому не нужно, либо вопросы к вендору. Архитектуру в LLVM можно добавить, и это делали не раз.
Про то что Rust не имеет якобы костов в runtime из-за якобы крутых проверок - я хотел бы увидеть доказательства. Например, как он делает проверки выхода за границы массива? Вы опять это пишите, а доказательства где?
Rust проверяет корректность некоторых конструкций, довольно ограниченную. Просто из "у Rust такая крутая система типов, что он теоретически МОЖЕТ делать более продвинутые оптимизации" это превратилось на просторах интернета в факт, бездоказательный.
Или Rust умеет проверять переполнение float?
