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)

хм

Выглядит так-то не плохо, +

qbbr ★★★★★
()

заметка, которая пытается объяснить зачем нужен Zig

У него не получилось. Очередная попытка изобразить недо-С, которую сравнивают с С++ вместо других недо-С. Выглядит малоосмысленно.

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

Он вообще не замена C++ в приложениях общего пользования. Он скорее для замены ассемблера (и Си): крошечные бинарники, работа без стандартной библиотеки.

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

У плюсОв стандартная библиотека тоже на кастомных аллокаторах может работать.

С корутинами поинт вообще странный: там или кастомный аллокатор, или вообще стек используется.

Уже давно гораздо удобнее и безопаснее под embedded на плюсах, чем на сях писать.

Вот приделают value exceptions и try statement нее будет проблем и со скрытым control flow.

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

Уже давно гораздо удобнее и безопаснее под embedded на плюсах, чем на сях писать.

Разве? Вроде даже драйвера в ядро линукса на нём проблематично писать. Или он уже может работать без динамической линковки и огромных бинарников?

monk ★★★★★
()

expected LLVM 12.x but found 11.1.0 using /usr/sbin/llvm-config

Ну и куда они так спешат? Даже в Арчик ещё не завезли 12.

dnb ★★★★
()

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

Несколько странная мотивация для использования zig. Чем этот вчера появившийся ноунейм лучше gcc, clang, msvc?

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

Чем этот вчера появившийся ноунейм лучше gcc, clang, msvc?

Может компилировать под многие таргеты, например под FreeBSD находясь под Windows.

gcc, clang из MSYS2 или MSVC не может собирать под FreeBSD, а zig скаченный отсюда может: https://ziglang.org/download/0.8.0/zig-windows-x86_64-0.8.0.zip

Я удалил у себя clang, и вместо него оставил zig.

zig c++ -v
clang version 12.0.1 (https://github.com/llvm/llvm-project 328a6ec955327c6d56b6bc3478c723dd3cd468ef)
Target: x86_64-pc-windows-msvc
Thread model: posix
fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от zabbal

Согласен. Не надо объяснять, чем оно лучше C++ (ха! как будто много языков, которые хуже), пусть объяснят, чем оно лучше C.

Miguel ★★★★★
()

Я вижу костры из книг,
Я слышу овчарок лай.
Если один скажет «Зиг» —
Миллионы ответят «Ставь!».

perl5_guy ★★★★★
()

Любопытное обсуждение.
Толком не понимают «для чего» и «когда полезно» применение такого рода компиляторов, но поругать НУЖНО ВСЕГДА.

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

вот тут целый час автор zig объясняет

Пусть сам этот час и смотрит.

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

Вроде даже драйвера в ядро линукса на нём проблематично писать.

Нет никаких проблем использовать C++ в ядре кроме идеологических.

Или он уже может работать без динамической линковки и огромных бинарников?

C++ может и давно.

X512 ★★★★★
()

Звучит интересно. Будем попробовать.

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

Ну и куда они так спешат? Даже в Арчик ещё не завезли 12.

А в Haiku завезли. Ваши Линуксы какие-то отсталые.

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

То есть идеологические. Компилятор, которым собирается Линукс всё равно overcomplicated и поддерживает C++.

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

Нет никаких проблем использовать C++ в ядре кроме идеологическ

Кроме увеличение размера ядра в несколько раз и мешанины в коде на двух языках.

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

C++ может и давно.

А как?

$ cat test.c++
int main()
{
        return 1;
}
$ g++ -O3 -static test.c++
$ strip a.out
$ stat -c %s a.out
682696

Для сравнения

$ cat test.zig
pub fn main() u8 { return 1; }
$ ./zig build-exe test.zig --strip --single-threaded -O ReleaseSmall
$ stat -c %s test
5576

Разница в 100 раз.

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

Компилятор, которым собирается Линукс всё равно overcomplicated

сложность компилятора == сложность того, что он компилирует?

походу ты просто погорячился.

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

мешанины в коде на двух языках.

кресты это не один язык. это мешанина из условно совместимых языков. именно поэтому более-менее крупные крестовые проекты без набора внешних ( по отношению к ЯП) правил и гайдов просто не живут.

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

Вот ещё:

> cat Test.cpp
#include <iostream>

int main()
{
        std::cout << "This is a test." << std::endl;
        return 0;
}
> g++ Test.cpp -o Test
> stat -c %s Test
6200
> Test
This is a test.
X512 ★★★★★
()
Ответ на: комментарий от dnb

-static

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

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

Вывод: в Линуксе не умеют готовить C++.

ldd покажи. А то в Линуксе выглядит так:

$ g++ test.c++ -o test
$ ldd test
        linux-vdso.so.1 (0x00007ffd893d1000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdd925cd000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdd9244a000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdd92430000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd9226f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd92779000)

$ stat -c %s /lib/x86_64-linux-gnu/libstdc++.so.6.0.25
1570256

Или ключ static добавь при компиляции.

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

Ненужновцы не нужны. Хороший язык, действительно претендует на замену C, хотя пока на нем рано писать серьезно из-за ломающих изменений. Ну и на момент когда я смотрел его в последний раз была проблема с очень медленным выполнением comptime кода (должно быть решено со стабильным self-hosted компилятором) и некоторые баги генерации кода LLVM со вклюенной оптимизацией (например, некоторые операции с целыми числами некоторых размеров не кратных 8 бит).

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

Вряд ли дело в C++.

Достаточно добавить в программу

#include <asm/unistd.h>

extern "C"
void __attribute__((noreturn)) _start()
{
        __asm__ __volatile__ ("syscall" : : "a"(__NR_exit), "D"(main()) : "rcx", "r11", "memory");
        __builtin_unreachable();
}

и скомпилировать с -nostdlib. У меня получается выходной файл размером в 8800 байт.

kmeaw ★★★
()
Ответ на: комментарий от monk
> lddtree Test
Test => ./Test (interpreter => none)
    libstdc++.so.6 => not found
    libgcc_s.so.1 => not found
    libroot.so => /boot/system/lib/libroot.so
> stat -c %s /boot/system/lib/x86/libstdc++.so.6.0.25 
1856100
> stat -c %s /boot/system/lib/x86/libgcc_s.so.1
109920
> stat -c %s /boot/system/lib/x86/libroot.so
1157763
X512 ★★★★★
()
Ответ на: комментарий от kmeaw

У меня получается выходной файл размером в 8800 байт.

Во-первых, всё равно больше, чем на Zig. Во-вторых, программировать на Zig гораздо приятнее, чем на ассемблере с подчеркиваниями и скобками. Если писать на ассемблере, то лучше брать не g++, а сразу nasm.

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

Ну вот. Минимальная программа потащит за собой несколько мегабайтов кода. А для zig – несколько килобайтов. Для системного программирования и встроенных систем разница существенная.

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

5576

У меня теже 5576 если компилировать для Linux. Но в zig видимо strip не до конца сделан, потому что потом запустив strip размер ещё уменьшается…

И file говорит, что можно сделать strip:

$ zig build-exe main.zig --strip --single-threaded -O ReleaseSmall -target x86_64-linux
$ file main
main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от monk

Минимальная программа потащит за собой несколько мегабайтов кода.

Этот код один на всю систему, не вижу в нём проблем. Причём он входит в базовую ABI системы. libroot.so для загрузки обязательна, она будет загружена даже если не импортировать, нет, это относится только к runtime_loader.

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

Минимальная программа, собранная компилятором с настройками по-умолчанию. Вряд ли для системного программиста будет проблемой один раз написать минимальный runtime для C++ под свою платформу.

Для Arduino ведь решили эту проблему, а у ATmega328P всего 32КиБ флеша под код.

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

минимальный runtime для C++ под свою платформу

Он больше, чем общий объём памяти для некоторых платформ. Потому что стандарт C++ требует наличия кучи функций, работы с исключениями и RTTI. А статическая компиляция, которая позволила бы включать в бинарник только необходимые функции, в современном C++ сломана.

P.S. Была попытка придумать Embedded C++, но как-то умерла. Так что или C или что-то типа Zig. Или свои велосипеды, как на Arduino.

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

sstrip даёт 1168 байт на выходе. Находится пакете elfkickers.

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

У меня на реальном железе работает. Работает даже там, где Линукс не работает.

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