LINUX.ORG.RU

Zig 0.8

 , ,


2

5

После 7 месяцев работы и 2711 коммитов вышла новая версия Zig: 0.8

Zig это:

  • Современный компилятор С

  • Современный компилятор С++

  • Компилятор языка Zig

  • Сборочная система для C, C++, языка Zig

  • (Планируется) Пакетный менеджер для С, C++, языка Zig

Zig разрабатывается под лицензией MIT: https://github.com/ziglang/zig/blob/master/LICENSE

Язык Zig – это язык общего назначения, который старается быть простым. Нет макросов, скрытых аллокаций, скрытого потока управления.

Небольшая заметка, которая пытается объяснить зачем нужен Zig, когда уже есть C++, D, и Rust: https://ziglang.org/learn/why_zig_rust_d_cpp/

Даже если вам не интересен язык Zig, возможно вам будет интересен Zig как кросскомпилятор С или С++.

#include <iostream>
int main() {
    std::cout << "Hello World!\n";
    return 0;
}
$ zig c++ -o hello hello.cpp -target riscv64-linux
$ qemu-riscv64 ./hello
Hello World!

Ещё про использование zig как кросскомпилятора: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

В новой версии:

  1. Обновление LLVM до LLVM 12.

  2. Поддержка arm64 macOS (aka the Apple Silicon) и также поддержка кросскомпиляции C, C++, и Zig в arm64 и x86_64 macOS.

  3. Zig также разрушает миф, что вам нужен Mac и Xcode для компиляции кода для Mac OS. Заголовочные С файлы Apple выложены под Apple Public Source License которая разрешительная.

Так что вы можете собирать бинарники для Apple из-под Linux/Windows/FreeBSD без XCode:

#include <iostream>

int main() {
   std::cout << "Hello World!\n";
}
$ zig c++ main.cpp -o test -target x86_64-macos
$ file test
test: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

Подробнее: https://ziglang.org/download/0.8.0/release-notes.html#macOS-Support

и

https://github.com/ziglang/fetch-them-macos-headers

  1. Добавлена поддержка WASI libc

  2. Начальная поддержка Haiku

  3. Изменения в языке: https://ziglang.org/download/0.8.0/release-notes.html#Language-Changes

  4. Изменения в стандартной библиотеке: https://ziglang.org/download/0.8.0/release-notes.html#Standard-Library

  5. Zig поддерживает Position Independent Executables, даже когда компилируются статические бинарники

  6. Изменения в сборочной системе: https://ziglang.org/download/0.8.0/release-notes.html#Zig-Build-System

  7. Обновление musl до 1.2.2, mingw-w64 до 9.0.0, возможность нацеливания glibc 2.33

Полный список изменений: https://ziglang.org/download/0.8.0/release-notes.html

>>> Официальный сайт

★★★★★

Проверено: Satori ()
Последнее исправление: xaizek (всего исправлений: 6)
Ответ на: комментарий от aist1

Хочется попробовать на практике — pet project. Взлетело — ты уже специалист по Rust и можешь учить молодежь

ага, так вот откуда все эти эксперты по расту берутся (в т.ч. и на ЛОРе)

Lrrr ★★★★★
()
Ответ на: комментарий от fsb4000

он там был, раньше чем появился Rust.

Без модулей и нормальной системы сборки, эта штука как выше писали:

нужно рантайм напильником хреначить.

anonymous
()
Ответ на: комментарий от Lrrr

А то! Это называется: «сделал в гараже». Многие вещи именно так и начинались. Так что если кто верит в Zig и его философию, пусть берется за дело. Нужна хорошая задача, которая бы показывала преимущества расширенного метапрограммирования. В основном это сейчас — software construction и design space exploration. Оно активно используется в проектирование цифровых интегральных схем.

aist1 ★★★
()
Ответ на: комментарий от aist1

Нужна хорошая задача, которая бы показывала преимущества расширенного метапрограммирования.

Есть еще такое понятие - метаданные.
О них любят многие порассуждать, но мало кто понимает, какая от них польза и как их создать/использовать.

anonymous
()
Ответ на: комментарий от anonymous

Ну или в более общем случае — база данных времени выполнения. В мире Java мы различные метаданные очень активно используем.

aist1 ★★★
()
Ответ на: комментарий от aist1

В мире Java мы различные метаданные очень активно используем.

Речь о метаданных и объектах о которых компилятор ни чего не знает …

СУБД умеют не много, но умеют.

anonymous
()
Ответ на: комментарий от anonymous

Тсссс! А то придет с новым проектом …

Он уже студентов в свою секту «Графическэ прогрумовання» завлек ..

anonymous
()
Ответ на: комментарий от hatred

Ну а что делать если с тулингом в c++ до сих пор плохо, все новые языки включая и например zig который тут как бы обсуждается имеют хорошие системы сборки и пакетные менеджеры, а в c++ ладно как система сборки есть страшный становящийся стандартом дефакто cmake, но ведь нужен еще реально стандартный пакетный менеджер.

anonymous
()
Ответ на: комментарий от aist1

В мире Java мы различные метаданные очень активно используем.

Мир Java ОГОГОООООООООООООО!

anonymous
()
Ответ на: комментарий от anonymous
Слышишь друг,

Речь о метаданных и объектах о которых компилятор ни чего не знает …

а в ответ - тишина ...
anonymous
()
Ответ на: комментарий от anonymous

И эшо.

Здесь https://forum.mista.ru/topic.php?id=868785&page=1 тупоконечники с остроконечниками вечно рыдают …

а-ля 1С не буду делать так, как не 1С-нутый …
Разрабатываю программную rapid систему в которой будет возможность использования:

  • мультимедии;
  • графики;
  • управления данными;

При этом многим тетям и дядям не придется тратить года жизни на изучение МЕГАТОННОЙ МУТИ разного API.

anonymous
()
Ответ на: комментарий от anonymous
  1. ставишь зависимости пакетным менеджером твоего дистрибутива
  2. если их там нет, опакечиваешь, и далее см. п. 1

А вся эта куча «стандартных пакетных менеджеров» - по факту аналоги арчевского AUR, только еще хуже.

Lrrr ★★★★★
()
Ответ на: комментарий от anonymous

а в c++ ладно как система сборки есть страшный становящийся стандартом дефакто cmake

Хороший пример «передовой технологии» наших дней …

anonymous
()
Ответ на: комментарий от anonymous

Хороший пример «передовой технологии» наших дней …

Корпорации ни чего хорошего не создадут.
У них задача проста и типична

Бананы в тренде?  
Продаем бананы ...
anonymous
()
Ответ на: комментарий от anonymous

Корпорации ни чего хорошего не создадут.

Хороший пример тому - flutter.
Все как обычно.
Сделаем что-то там из

говна и палок
anonymous
()
Ответ на: комментарий от anonymous

Хороший пример «передовой технологии» наших дней …

Передовой технологии двадцатилетней давности.

anonymous
()
Ответ на: комментарий от Lrrr

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

anonymous
()
Ответ на: комментарий от anonymous

зачем так делать? Ты что, ими всеми пользуешься?

Lrrr ★★★★★
()
Ответ на: комментарий от anonymous

Ну во-первых пакетные менеджеры есть (тот же конан), но не об этом. А почему плюсы должны тянуть под своим именем и только для себя ещё одну поделку? А почему бы не стандартизировать пакетный менеджер для ОС, pacman, например? И если я захочу одну либу на Z–, другую на M++, и прилинковать это всё к плюсовому проекту, то я должен обломаться, видимо? Может вопрос несколько шире, чем пакетный менеджер раста/шмаста/…?

anonymous
()
Ответ на: комментарий от anonymous

Он уже студентов в свою секту «Графическэ прогрумовання» завлек …

Sorry
Правильно так

Графiчной медiдацii
anonymous
()
Ответ на: комментарий от anonymous

гугел переводит так

графічна медитація

anonymous
()
Ответ на: комментарий от anonymous

А почему бы не стандартизировать пакетный менеджер для ОС, pacman, например?

Было бы неплохо, но для разработки такие менеджеры подходит намного хуже чем специально написанные для этого, типа того же cargo для rust, так как создавались совсем для других целей. Но даже если аналог pacman стандартизировать для всех систем то было бы конечно хорошо. Но в реальности это чистая утопия.

И если я захочу одну либу на Z–, другую на M++, и прилинковать это всё к плюсовому проекту, то я должен обломаться, видимо? Может вопрос несколько шире, чем пакетный менеджер раста/шмаста/…?

Нужно же учитывать и языковые особенности и особенности сборки, хотя для достаточно близких языков вполне наверно реально, например для zig/rust/c/c++ в одном флаконе, но тут в c++ даже для самих себя еще не договорились.

anonymous
()
Ответ на: комментарий от anonymous

Было бы неплохо, но для разработки такие менеджеры подходит намного хуже чем специально написанные для этого, типа того же cargo для rust, так как создавались совсем для других целей.

Ты всё о каких-то костылях под конкретный язычек, это ущербный подход. Для разработки лучше взять - git с субмодулями, и нет никакой привязки к языку и всё уже есть и работает.

Но даже если аналог pacman стандартизировать для всех систем то было бы конечно хорошо. Но в реальности это чистая утопия.

Было бы желание, можно стандартизировать некий общий интерфейс + универсальное имя пакета (для обхода всего этого маразма с дроблением пакета на сотню компонентов). Каждый менеджер сможет запилить этот универсальный интерфейс. На крайняк и всякие флатпаки есть (если зависимости - экзотика).

Нужно же учитывать и языковые особенности и особенности сборки, хотя для достаточно близких языков вполне наверно реально, например для zig/rust/c/c++ в одном флаконе, но тут в c++ даже для самих себя еще не договорились.

Любой приличный язык должен уметь extern «C», иначе на свалку.

anonymous
()
Ответ на: комментарий от anonymous

Нужно же учитывать и языковые особенности и особенности сборки, хотя для достаточно близких языков вполне наверно реально, например для zig/rust/c/c++ в одном флаконе, но тут в c++ даже для самих себя еще не договорились.

Да нет с этим ни каких проблем.
Имеются несколько формат объектных файлов, которых должны придерживать все компиляторы.

Вот «ad dll» в Linux не разрулили, а в Windows решили эту проблему.

Вот в чем вопрос
anonymous
()

Пакетный менеджер языка программирования и операционной системы преследуют разные цели. Первый ориентирован на сборку библиотек в различных окружениях, а второй — на деплоймент исполнимых актефактов в конкретно заданном окружении. Если пользовать сторонний пакетный менеджер под систему сборки, то будет конфликт применимости с командой, разрабатывающей этот пакетный менеджер: «нам эти фичи в в системе не нужны, мы их тянуть не собираемся».

В С++ проблем с пакетными менеджерами сейчас нет. Я сам использую Vcpkg и полностью им доволен. Он, конечно, очень простой и не умеет в версионирование. Но своеё дело по минимуму делает прекрасно. Проблема есть с адаптацией модулей в повседневном использовании. Так как модули привязаны к С++20, а мы (кодовая база в целом) еще на 14-м сидим и о 17-м только думаем. Т.е. есть нехилая инертность прагматики, которая непонятно когда будет преодолена. Хорошо, если к 2025-му году. Всё будет зависеть от того, как будет идти «модуляризация» имеющейся кодовой базы.

Проблема в том, что вот эти вот пакетные менеджеры, которые сейчас для С++ есть, они не соответствуют требованиям завтрашнего дня. Т.е. мы всё еще пытаемся запрыгнуть в вагон поезда, оставшегося в прошлом. Как минимум, нужна возможность глубокой автоматизации того, что пакетный менеджер делает. И нужна нативная интеграция с облаком (kubernetes и т.п. технологии).

aist1 ★★★
()
Ответ на: комментарий от anonymous

Вот «ad dll» в Linux не разрулили, а в Windows решили эту проблему.

У моря хорошей погоды ждать не буду.
Скорее всего создам свой формат объектного файла /с учетом конечно особенностей существующих/ + linker подработаю.

Ранее приходилось решать подобные вопросы.
Все выше сказанное вполне реально сделать и нужно сделать.

Ну а теоретики как обычно …

Всех учат
anonymous
()
Ответ на: комментарий от anonymous

Скорее всего создам свой формат объектного файла /с учетом конечно особенностей существующих/ + linker подработаю.

Свой формат потому, что ссылок реллокации … маловато.
Лет этак сорок назад еще куда не шло …

anonymous
()
Ответ на: комментарий от anonymous

Скорее всего создам свой формат объектного файла /с учетом конечно особенностей существующих/ + linker подработаю.

Готовый API для этого уже есть /и не только для этого/.

anonymous
()
Ответ на: комментарий от anonymous

Готовый API для этого уже есть /и не только для этого/.

Респект разработчикам!

git clone git://sourceware.org/git/elfutils.git

22 мая новая версия вышла однако …

anonymous
()
Ответ на: комментарий от anonymous

Все выше сказанное вполне реально сделать и нужно сделать.

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

Проблемы С++ сейчас не технические, а социальные. C++ стареет, и основная масса разработчиков — 35+. В этом возрасте уже не хочется ничего менять, образовательные кредиты выплачены, ипотека, скорее всего, тоже. Можно расслабиться. Или, по крайней мере, не напрягаться. Работодателям тоже ничего такого не надо.

С++ не хайповый и зарплаты на нем ниже и Java и, уж тем более, Python. А программировать сильно сложнее во всех отношениях. Причем непонятно, что в плане job security. Медленно идти на дно вместе с коболизирующимся языком? В фаанги на работу на C++ длинная очередь, а остальные плохо платят.

С++ должен стать привлекательным для молодежи. Причем сам язык вряд ли можно «вытянуть» (да и не нужно), нужно уприрать на автоматизируемые инструменты разработки и развертывания и сопровождения кода.

aist1 ★★★
()
Ответ на: комментарий от aist1

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

Так я не Дон Кихот.
Порешаю проблемы в рамках своего API.
Свой формат объектных файлов.
Здесь речь не о проблемах, а добавлении новых фич для API, обеспечивающего возможность создания и использовании динамических объектов о которых компилятор ни чего не знает.

anonymous
()
Ответ на: комментарий от anonymous

Здесь речь не о проблемах, а добавлении новых фич для API, обеспечивающего возможность создания и использовании динамических объектов о которых компилятор ни чего не знает.

Можешь раскрыть тему? :)

aist1 ★★★
()
Ответ на: комментарий от aist1

Можешь раскрыть тему? :)

1001 раз об одном и том же не хочу писать.
Да и что не понятно из сказанного?

anonymous
()
Ответ на: комментарий от anonymous

1001 раз об одном и том же не хочу писать.

Ты извини, но анонимусы тут как элеткроны. Отличаются только позицией в ленте, даже если подписываются. Человек без сверхспособностей будет быстро теряться в том, кто что говорил и в который раз :)

Просто, если я правльно понимаю, о каких объектах ты говоришь, то тебе нужен динамический компилятор. Раз в статике о них ничего не известно. Ну то есть, продвинутый JIT. Я, кстати, юзал в одном проекте GraalVM, очень понравилось. Могу рекомендовать.

aist1 ★★★
()
Ответ на: комментарий от aist1

то тебе нужен динамический компилятор

Не компилятор, а парсер + AST.
Буду употреблять термин далее «компилятор» …
Собственно суть в том, чтобы другие программы могли использовать
API, предоставляющее возможность работы с обобщенными алгоритмами.

Динамические объекты как раз для этого прекрасно подходят …

Собственно как сделать и что нужно, ясно.
Проблема за малым

Нужно сделать!
anonymous
()
Ответ на: комментарий от anonymous

Не компилятор, а парсер + AST.

Ну посмотри Truffle. Возможно, оно тебе поможет быстро запрототипировать твой стек. Оно может и в native.

aist1 ★★★
()
Ответ на: комментарий от anonymous

Все!

Сегодня отдохнул.
Завтра за работу …

anonymous
()
Ответ на: комментарий от aist1

Ну посмотри Truffle. Возможно, оно тебе поможет быстро запрототипировать твой стек. Оно может и в native.

Спасибо конечно!
Но в этом проблемы нет.

anonymous
()
Ответ на: комментарий от anonymous

Но в этом проблемы нет.

Я к тому, что что-то похожее (если я правильно тебя понимаю) не просто есть, а используется. И даже площадка для внедрения уже создана.

aist1 ★★★
()
Ответ на: комментарий от aist1

Я к тому, что что-то похожее (если я правильно тебя понимаю) не просто есть, а используется.

Да может и так.
API создано и проверено на практике.
У кого-то другое …

Если тему продолжить, то любой скриптовый язык программирования имеет: парсер, …
И даже более того, некоторые позволяют на лету даже расширять API классов, …
Но вот, обеспечения возможности создания/сохранения/использования … метаданных не встречал.
Нечто похожее это COM от Microsoft, но там многое просто не реализовано.
Не потому конечно, что они не смогли это сделать.
Да и COM у них из серии

Америка Европе подарила параход.  
И ужасно и ужасно и ужасно тихий ход

Да и пригодно лишь для Windows …

anonymous
()
Ответ на: комментарий от anonymous

Но вот, обеспечения возможности создания/сохранения/использования … метаданных не встречал.

А что ты тут понимаешь под метаданными?

aist1 ★★★
()
Ответ на: комментарий от anonymous

И эшо.

Пишу не голословно.
Что такое COM, DCOM, ActiveX, … и с чем их едят знаю не по наслышке …

anonymous
()
Ответ на: комментарий от aist1

А что ты тут понимаешь под метаданными?

Метаданные содержат информацию о любой сложности динамических объектах или коде.

То бишь объект можно создать/сохранить/передать … динамически и на основании метаданных его использовать.

Все как обычно!

anonymous
()
Ответ на: комментарий от anonymous

Метаданные содержат информацию о любой сложности динамических объектах или коде.

Ну то есть ты хочешь иметь мультимодельную встроенную базу данных времени выполнения, причем динамическую (read/write, а не только для чтения), так?

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

Ну то есть ты хочешь иметь мультимодельную встроенную базу данных времени выполнения, причем динамическую, так?

API можно использовать для работы с отдельными объектами в memory, объектными базами данных в виде файлов, …

Фишка не в том, что это API нужно для любой программы, а в том что с его использованием можно много разного tools разработать …

Шутка

Например 1С 10.0

Для вэб кстати то же подойдет …
Но на вэб тратить время не буду.
Это

Отстой
anonymous
()
Ответ на: комментарий от anonymous

API можно использовать для работы с отдельными объектами в memory, объектными базами данных в виде файлов, …

Собственно все «новое», это забытое «старое».
Считаю, что веду разработку тривиального API, которое кто-то должен разработать …
Здесь главная проблема в разработке хорошей архитектуры.
А API «дело наживное».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.