zig build-exe -target wasm32-wasi, аллокатор std.heap.wasm_allocator, если что

Я честно говоря так и не понял какие у zig киллер фичи по сравнению с Rust, D и тем же Nim:
https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Already-CPP,-D,-and-Rust%3F

То есть нету свойств, перегрузки операторов, автоматической работы с памятью и все это подается как преимущество?

для Rust уже сейчас при работе с wasm и передаче туда-сюда данных мы пишем mem.forget, чтобы Rust не удалял переданные в js данные. А потом у wasm GC собирался появляться? Придется хитрые договоры писать между полуавтоочисткой памяти Rust и GC wasm. А с Zig можно просто взять и одной командой оттяпать себе кусок памяти. Вообще Rust популярен во многом из-за неправильного восприятия слова "safe", которое преподносится как его рекламная фишка.

Для кросс-компиляции Rust со своего linux в aarch64 (на телефон) придется ставить тулчейн Rust и кросс-компилятор C соответствующей архитектуры. Для кросс-компиляции zig достаточно поставить zig, он кросс-компилируется без зависимостей, к тому же может компилировать Си и содержит в себе для удобства кросс-компиляции Си много libc для разных архитектур.

Ну и вообще zig не конкурирует с Rust или Nim, он конкурирует с Си. По сути он и есть Си, но с решениями некоторых определенных проблем, с которыми сталкиваются разработчики на Си. Не надо учить язык макросов, язык может выполняться в compile-time (в качестве замены макросов), если нужна система сборки - она тоже представляет собой программу на Zig (как build.rs в расте), впрочем, мне пока и без нее хорошо

ну и мое любимое преищество относительно Rust - у Rust папка проекта с билд-артефактами весит гигабайты, io мучается. Такой проблемы у zig нет, да и у других языков тоже

В C++ уже тоже можно обходиться без макросов используя constexpr. Но макросы это не только compile-time вычисления. Ок Rust может быть тяжеловестным, но он намого больше умеет чем Zig и намного матерее. С Nim так и не увидел сравнения. А вот эта фича что можно определить int любой размерности например i3, i1234 и т д это вообще не вяжется с философией делать все явно и без лишних эмуляци-аллокаций. Более того, это может привести к ошибкам, например ты просто возьмешь и опишешься где то, вместо i32 напишешь i23 при быстром наборе. Очеь сомнительная фича

инты произвольного размера это вроде нативная фишка ллвм

а можешь показать код с mem.forget? возможно есть альтернативы

в С++ в каждом проекте свой subset берут и пытаются без чего-то обходиться, но все равно роясь в случайных проектах, постоянно приходится разбираться и читать все фичи языка, которые в нем реализованы. Сравнивать c Nim какой смысл? на Nim операционные системы не пишут, память в нем чистится GC. Nim с питоном надо сравнивать. int любой размерности - это по-моему просто взяли из llvm и дали программисту пользоваться, да и очень удобно, когда хранишь состояние в виде набора бит 0x01001 и можно это состояние задать i5

альтернативы есть, упаковывать и распаковывать Box, это safe, хотя unsafe-ный mem.forget там под капотом вызывается.

а, еще глав разраб у Zig коммитит что-нибудь постоянно, как ни загляну в github - последнее изменение в кодовой Zig несколько часов назад. Несколько лет почти каждый день что-то коммитит... Прям завидую его энтузиазму и стабильности

B LLVM на это есть причины, это существенно упрощает range checking и последующие оптимизации. Тем не менее llvm это промежуточный код и там могут использоваться любые вспомогательные абстракции, это еще не значит что их нужно тянуть во фронт

я имел в виду другие варианты. есть пример кода?

нету, забросил Rust давно, все поудалял. Но где-нибудь должно быть, это же не только webassembly, у него с разработкой любых ffi-библиотек так

в целом да, такое используется, но больше при работе с коллбеками когда например подписываемся на онклик из раста. а если нужно вернуть массив и не хочется делать forget, можно вызвать джс функцию и передать туда массив как аргумент. но здесь по другому как ты сделаешь?

с каких пор число - вспомогательная абстракция? Появится какая-нибудь 128-битная архитектура, и zig'овский i128 сразу будет правильно компилироваться для быстрых вычислений процессарами, которые умеют в 128битные числа? Вообще это надо в каком-нибудь другом чате обсуждать, а то уже неwebassemblyшный языковой холивар получается =)

mem::forget это safe

я не о числе, а о non-native типах. Не перекручивай пожалуйста

почему 40-битное число - это non-native тип?

потому что оно не POT и не укладывается в четное число регистров, так же как и i129 и т д. Это не эффективно (как по памяти, так и вычислениям) а так же усложняет фронтенд компилятора

оно укладывается в i64, например