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 ()

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

И еще добавлю. Вот пример, что позволяет сделать comptime в Zig - MultiArrayList(S) тип из стандартной библиотеки https://github.com/ziglang/zig/blob/master/lib/std/multi_array_list.zig

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

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

У тебя во время написания комментария компилятор ЧСВ не завис? :-D

Читай невидимое ПМСМ в начале каждой фразы. Это же форум. Утверждения на нём по определению отражают лишь точку зрения пишущего.

И поэтому авторы не сравнивают его с Си, вместо этого сравнивая с D, Rust и C++. Очень логично.

Так они сравнивают только в областях, где их можно заменить на Си. Потому что в остальных областях считать преимуществом отсутствие «лишних» возможностей сложно.

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

Потому что в остальных областях считать преимуществом отсутствие «лишних» возможностей сложно.

Это да.
Область разработки программ весьма обширна и в ней бывает, что

«лишние» возможности

уместны и vs.

Микроскоп уместен для того, чтобы увидеть

Пять звездочек

а молоток

Для ... ?
anonymous ()
Ответ на: комментарий от monk

То есть по факту стандартная библиотека есть, но своя самописная. Ладно, убедил в возможности применения C++.

Ещё можно просто собирать С++ код с помощью gcc, clang или zig cc. (Вместо g++, clang++, zig c++)

Тогда будет ошибка линковки если будет использована какая-то фича, которая требует рантайма плюсов. Но если таких фич нет, то сборка пройдёт успешно.

$ cat main.cpp
#include <stdlib.h>

class string_view {
  [[maybe_unused]]const char* buf;
  size_t len;
   
public:
  string_view(const char* s) noexcept
     : buf(s)
     , len(0)
  {
      if (s != nullptr) {
         while(s[len] != '\0') {
           ++len;      
         }
      }
  }
  size_t size() const noexcept {
     return len;
  }
};


int main(int, char** argv)
{
        return [=]() {
            string_view sv = argv[0];
            if (sv.size() == 2u) {
               return 1;
            } else {
               return 0;
            }
        }();
}
$ zig cc -Os -std=c++20 -Weverything -Wno-c++98-compat main.cpp -fno-exceptions -fno-rtti   -static -o test.c++ -target x86_64-linux
$ strip test.c++
$ ls -l test.c++
-rw-r--r-- 1 fsb4000 fsb4000 3264 июн  6 16:35 test.c++
$ file test.c++
test.c++: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped

И если какая-то фича нужна, то можно посмотреть ошибку линковки и создать свою функцию реализующую эту фичу.

А так: классы(на стеке), шаблоны, constexpr, концепты, модули, лямбды, неймспейсы не требуют рантайма плюсов…

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

Регулярно слушаю. Он говорит, что на С++ написано миллионы строк кода, и что почти все из того, что сейчас крутится имеет в себе большую долю С++ (ос, базовые библиотеки, компиляторы). Поэтому так просто взять и сломать нельзя. И это было одно из основных «скреп» языка. И то, что за 40 лет язык сумел развиться - это большое достижение и достаточно уникальный случай (тот же С фактически не развился, были примеры ядра windows 1.0 из музея и современного ядра Linux - выглядят очень похоже).

Я не согласен с твоей тактовой / переводом zero overhead abstractions и pay only for what you use principle. Это не то же самое, что «скорость скомпилированного кода».

anonymous ()

Респект автору Zig.

Это не на форумах «теоретизировать» …

PS: Впрочем обсуждение уместно если оппоненты в «теме».

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

Читай/слушай внимательно про изначальную мотивацию создания C++, а не то, к чему развитие ЯП пришло через 25-30 лет. Современные интервью даются в современном контексте, а в 80х вообще не было ясно, что ЯП взлетит. «zero overhead abstractions и pay only for what you use principle» больше относится к тому времени, когда в C++ уже появились шаблоны, и он начал взлетать. А изначальный C++ - это сишка с классами, т.е. структуры с наследованием и динамическим полиморфизмом. И, конечно, за динамический полиморфизм таки надо платить, но это был компромисс между миром сишки и ООП, на который Страуструп пошел, потому что очень хотел быстрое в рантайме ООП. А «zero overhead abstr…» стало более актуально когда уже появились шаблоны, и диссер (работа над которым и сподвигла на создание C++) Страуструп защитил. Про кучу написанного кода, и отраслей - этого не было в 80х. В том C++ 1985г.в. мало что можно было сломать, т.к. фич было мало, но когда требовались изменения, они вводились, без оглядки на обратную совместимость.

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

Что-то написано в «Design and Evolution of C++», что-то в старых интервью.

seiken ★★★★★ ()

А есть какой-то трекер всех этих новых языков? Pony, V, Nim, Odin, теперь вот zig - тысячи их, я про них периодически узнаю и интересно почитать, что придумали великие умы, может есть какой-нибудь сайт, который следит за появлением новых яп?

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

Тогда было так

Windows к тому же ещё и является очень прожорливой к памяти программой.  
Согласно написанному на купленной копии, она требует минимум 256 КБайт оперативной памяти. 
anonymous ()

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

Но стремление пообсуждать чужое ненужное и продемонстрировать свое ненужное - понятно. Куда проще онанировать на «ещеодинсуперпуперезыгтакойжекаксинокруче», чем вести реальный продуктмвный r&d в области исследования езыгов и кимпиляторов.

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

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

Формат обсуждения в форуме просто губит на корню любую тему.
Ладно бы профессионалы высказывали свои суждения …
Не к тому об этом сказал, что на форуме профессионалов нет, но

Нельзя объять необъятное

ИМХО не позволяю себе «судачить» на темы темы в которых

Не в теме
anonymous ()

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

Напишите им там кто-нибудь, что программы пишутся не только для машин, а еще для других людей. Может что-нибудь когда-нибудь получится.

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

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

А зачем рантайм -static`ом туда воткнули? Или из-за того, что в zig нет рантайма?

faust@archlinux ~/П/C/РАзная всячина> cat empty.cpp
int main()
{
        return 1;
}⏎                                                                                                                                                                                                                  faust@archlinux ~/П/C/РАзная всячина> g++ empty.cpp
faust@archlinux ~/П/C/РАзная всячина> strip a.out
faust@archlinux ~/П/C/РАзная всячина> stat -c %s a.out
14264
faust@archlinux ~/П/C/РАзная всячина> uname -ar
Linux archlinux 5.12.9-arch1-1 #1 SMP PREEMPT Thu, 03 Jun 2021 11:36:13 +0000 x86_64 GNU/Linux
faust@archlinux ~/П/C/РАзная всячина> 

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

А зачем рантайм -static`ом туда воткнули? Или из-за того, что в zig нет рантайма?

Именно из-за этого. Для C++ приходится или рантайм класть рядом с программой и распространять с ней или надеяться, что в системе уже есть рантайм нужной версии (попробуйте запустить бинарник, собранный g++ 4 версии на современном линуксе).

На zig почти весь coreutils можно пересобрать статически и при этом его размер почти не изменится.

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

Т.е. Код компилится сразу в системные вызовы нужной платформы?

Это конечно не плохо. Хотя чем-то начинает напоминать C- -….

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

чем это лучше clang’а?

Тем что работает из коробки?

Изкоробочный clang на Manjaro не может собрать…

$ cat main.cpp
#include <iostream>
int main() {
    std::cout << "Hello World!\n";
    return 0;
}
$ clang++ -o test main.cpp -target riscv64-linux
main.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
         ^~~~~~~~~~
1 error generated.
$ clang++ -v
clang version 11.1.0
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/10.2.0
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/10.2.0
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

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

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

попробуйте запустить бинарник, собранный g++ 4 версии на современном линуксе

Делал так - работает, даже ставил gcc4 в NixOS, чтобы воспроизвести билд

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

Тем что работает из коробки?

Так он с собой просто все тащит. Можно так же тарбол с клангом собрать, где будут хидеры и либы под разные платформы. Но нужны ли мне хидеры и либы под все платформы в системе?

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

Можно так же тарбол с клангом собрать, где будут хидеры и либы под разные платформы

Да, если собрать хидеры и либы под разные платформы, и не забывать добавлять -Iпуть -Lпуть в зависимости от target, то разницы не будет.

$ zig cc -v
clang version 12.0.1 (https://github.com/llvm/llvm-project 328a6ec955327c6d56b6bc3478c723dd3cd468ef)
Target: x86_64-pc-windows-msvc
Thread model: posix

https://github.com/ziglang/zig/blob/master/CMakeLists.txt

...
find_package(clang)
...
target_link_libraries(zigcpp LINK_PUBLIC
    ${CLANG_LIBRARIES}
    ....
)
...

fsb4000 ★★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)

DYLDLINK

DYLD

MacOS

Good joke 👍

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

Ну тут палка о двух концах. У динамики свои плюсы, у статики свои.

Спорить, что лучше можно долго и упорно… Я, лично, за динамику с фиксированным API, к сожалению последний пункт (API) страдает из-за хотелок/багов дейзинга.

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

Динамика плохо дружит с маленькими программами и с оптимизацией путём частичной специализации.

А фиксированное API почти невозможно. Микрософт очень пытался. В результате там уйма хаков для того, чтобы работало ПО, написанное для старых версий.

В linux’е пытаются это обойти версионированием символов, но там свои грабли.

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

А фиксированное API почти невозможно. Микрософт очень пытался. В результате там уйма хаков для того, чтобы работало ПО, написанное для старых версий.

Ээээээээ, на их официальной страничке рассказывалось как в Windows обеспечивается работа программ с предыдущих версий ОС.

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

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

Ну тут палка о двух концах. У динамики свои плюсы, у статики свои.

Проблема много глубже чем вопросы, когда хорошо связывание в статике или динамики.
Это лишь вершина айсберга проблем.
Да, как-то там решили …

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

Инерция мышления, сэр.

В IT так часто бывает.

Чем нынешние технологии разработки компиляторов отличаются от пятидесятилетней давности.
Да ничем.

А почему?

Нервы, засорение атмосферы, водофемов ...
anonymous ()
Ответ на: комментарий от fsb4000

Почитал про ссылке.

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

Да, такое действительно даст минимальный размер хеллоуворлда.

Но вот интересно было бы на гуёвое что-то посмотреть. Там без динамической линковки тяжелее.

Более того, то, что они gcc_s заменяют может иметь неприятные последствия: например, исключения и rtti не будут правильно работать в разных либах.

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

Инерция мышления, сэр.

Не могу разрешить одну штуку. Если фанаты Раста не переходят на Зиг, то у них инерция мышления. Если переходят, то какие тогда они фанаты Раста?

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

Инерция мышления и лень не являются идеологическими причинами выбора C++ вместо Rust.

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

Есть. В C++ имеется привычный для рынка ООП как в Java и C#.

В С++ еще есть библиотеки. Много их годных. Каждый раз, когда я пытался примерить Rust на себя, накопленная кодовая база на С++ решала против.

Rust по факту конкурирует за нишу не с С++, как таковым, а с Go. Причем ного людей выбирают последний, так как GC сильно проще в работе, чем линейные типы при такой же или даже лучшей защите памяти. А с тех пор, как в Go завезли мономорфные дженерики, язык этот идет к тому, чтобы стать де-факто платформой для инфраструктурных проектов и баз данных средней степени сложности. А Go, в свою очередь, замещает из этой области С++ и Java для новых проектов.

Тем, кто уже хорошо сидит на С++, лучше браться не за Rust, а вкладывать усилия в различную автоматизацию над С++. Оно куда полезнее будет.

Вот было бы интересно такое метопрограммирование, как в Zig – да в С++ заиметь. TMP – это не масштабируемо (трясина Тьюринга), а constexpr – это даже не смешно.

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

Rust по факту конкурирует за нишу не с С++, как таковым, а с Go.

Я бы поставил на нишу C в первую очередь. Go, как мне кажется, больше подходит для Web’ни и микросервисов чем тот же Rust как раз за счёт уже зрелой кодовой базы и кучи накопленных фреймворков + поддержке огромного Google.

У Rust’а пока ещё до сих пор малое количество библиотек, которые поддерживают не энтузиасты-одиночки, а корпорации. Пока ситуация не изменится, enterprise любой кровавости будет выбирать Rust лишь в качестве игрушки.

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

программы пишутся не только для машин, а еще для других людей

Для людей без синдрома утенка, сишный синтаксис не лучший вариант. Тот же нимовский или улучшеный синтаксис ML языков точно лучше.

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

Именно из-за этого. Для C++ приходится или рантайм класть рядом с программой

И чем тогда zig лучше, если у него тупо нет рантайма, чем взять c++ или тот же rust без рантайма.

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

Тем, кто уже хорошо сидит на С++, лучше браться не за Rust, а вкладывать усилия в различную автоматизацию над С++. Оно куда полезнее будет.

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

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

Я бы поставил на нишу C в первую очередь

Ниша С для Rust очень узкая, так как потеснить первый там будет мешать то же самое — существующие наработки. Т.е. как бы да, у Rust могут быть хорошие шансы в IoT, который неплохо так развивается и где линейные типы и более-мене способное к чему-то метопрограммирование взлетит. Но масштаба этой ниши точно не хватит, чтобы вывести Rust на тот же уровень, где сейчас С++. В Web Rust себя нашел через WASM-модули для html5-приложений.

У Rust’а пока ещё до сих пор малое количество библиотек

Как это бывает, можно посмотреть на примере Java. Там не стали делать нормальный интерфейс с нативным кодом в расчете на то, что программисты всё перепишут на Java в конце-концов. Расчет этот не оправдался по многим причинам. Главная их которых — возможность легко оборачивать С/С++ный код в Python, и оттуда его использовать. Намеренно или нет, но в CPython сделали ARC для управления памятью, а это позволяет легко управлять временем жизни нативных ресурсов, связанных с питоновскими объектами. Т.е. существующий код на С и C++ продолжил развиваться, а Java окуклилась в безразмерной нише Web + по мелочам разного. BigData — отдельный и своеобразный феномен, и она с Java тоже активно съезжает.

Делать сейчас язык с претензией на top10, который будет несовместим с С++ не имеет смысла из-за огромной иннерции накопленной кодовой базы. Я до сих пор удивляюсь, почему Rust-оманы пошли по пути создания совершенно другого языка, вместо того, чтобы сделать диалект С++ с линейными типами, макросами и встроенным пакетным менеджером. Учитывая то, сколько они сил и средств вложили в свой Rust, уже бы завоевывали индустрию.

Вот, кстати, такая попытка запилить полноценное метапрограммирование времени компиляции в С++: Circle.

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

И чем тогда zig лучше, если у него тупо нет рантайма, чем взять c++ или тот же rust без рантайма.

У него есть тот рантайм, который используется.

Например,

const std = @import("std");
const io = std.io;

pub fn main() !void {
    const stdout = io.getStdOut().writer();
    const stdin = io.getStdIn();
    var line_buf: [100]u8 = undefined;
    try stdout.print("Enter your name: ", .{});
    _ = try stdin.read(&line_buf);
    try stdout.print("Hello, {s}!\n", .{line_buf});
}

компилируется в 5 килобайт.

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

Можно какие-то конкретные примеры по автоматизации?

Можно, конечно. Тот же Circle. Или попробовать вот так. Кодовая база Clang вполне себе гибкая и реюзабельная, чтобы на её основе сделать инструмент автоматизации кодовых трансформаций/верефикаций/etc. Да, это будет форк clang (если семантики плагина окажется недостаточно). Но это совсем не так страшно, как может показаться.

Я такой себе делаю, так как этот язык я люблю и много труда в такой код вложил. Код, кстати, сейчас становится новыми данными. Так что и инструментов требует соответствующих.

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

В Web Rust себя нашел через WASM-модули для html5-приложений.

Только для тех кому плевать на производительность. Rust очень жирный для WASM. С или Zig гораздо лучше для WASM, на порядки лучше.

Но большинству плевать на производительность, поэтому WASM пишут даже на C# и Go…

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

Только для тех кому плевать на производительность.

Только не на производительность, а не время загрузки сайта. Да, есть такая беда. Суть в том, что аналогичный код на JS будет, скорее всего, и больше, и меленнее. Ну и аудитория веб-программирования не сможет в ручное управление памятью а-ля C. Так что Rust здесь – очень даже компромисный вариант.

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