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)
Ответ на: комментарий от monk

Потому что стандарт C++ требует наличия кучи функций, работы с исключениями и RTTI.

Не обязательно реализовывать всю библиотеку C++. Моя мини-ОС (скриншоты: раз, два) на C++ работает вообще без стандартной библиотеки.

Работает:

  1. RAII.
  2. Классы.
  3. new/delete.
  4. dynamic_cast.
X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от monk

Достаточно ограничить себя в использовании фич C++. Никто же не возмущается, что в коде ядер некоторых ОС, написанных на C, нельзя использовать FPU; из-за невозможности использовать язык полностью (или, наоборот, как в Linux, используя расширения конкретного компилятора) обычно всё равно говорят «ядро ОС написана на языке C».

Так и на C++ можно писать под embedded, и ядра ОС на нём реализовывать, используя или не используя динамическую память, исключения и RTTI, учитывая возможности своего runtime и ограничения платформы. Совсем не обязательно придумывать какой-то новый стандарт «Embedded C++», чтобы язык C++ был полезен для embedded-применений.

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

работает вообще без стандартной библиотеки. … new/delete, dynamic_cast.

Это как? operator new() прямо в коде компилятора инлайнится? А компилятор тогда тоже свой?

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

operator new() прямо в коде компилятора инлайнится?

operator new() – это вызов функции с названием _Znwm. У меня это обёртки над malloc/free, а malloc/free у меня самописные. Реализация dynamic_cast тоже самописная. Пока всё линкуется статически в один RAW бинарник.

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

А компилятор тоже самописный?

Компилятор – clang 12. Никаких библиотек от компилятора не линкуется, весь код свой.

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

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

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

Вот не надо инсинуаций - в arduino вполне себе подмножество C++, причём использовать неописанные конструкции C++ никто не мешает, всё равно в итоге компилируется gcc.

Из отличий от C++ там разве что неявная фунция main(), которую слегка заменяет loop() и отсутствие некоторых инклюдов в основном файле проекта. На новый язык - не тянет, точно так же как не тянет на новый язык #define BEGIN {

anonymous
()

Zig eto ne rasta :(

anonymous
()

>/tmp/hc.nim(5, 1) Error: tabs are not allowed, use spaces instead

ненужно!

paran0id ★★★★★
()

очередная ненужная llvm шляпа

anonymous
()

Тыкал его 1 раз. Так и не смог понять, зачем он нужен.

SprainBrains
()

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

Первый раз слышу про него

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

А вот это интересно. Тогда вопрос как выпилить Zig из Zig компилятора =)

anonymous
()

новодельный Zig

const std = @import("std");

pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, {s}!\n", .{"world"});
}
против С
#include <stdio.h>
void main() {
    printf("Hello %s\n","word");
}
собственно всё что о нём достаточно знать.

ф топку

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

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

Нет никаких причин предпочитать С++ Расту, кроме идеологических ;)

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

Неконсистентность синтаксического месива.

Чуть читабельнее чем поделка местного утырка с трансятором в C++, но без киллерфич это просто никому не нужный петпрожект.

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

Нет никаких причин предпочитать С++ Расту, кроме идеологических ;)

Есть: программы на Rust собираются намного медленнее и в стандартной библиотеке беда с обработкой ошибок. Бинарники получаются жирнее.

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

Нет никаких причин предпочитать С++ Расту, кроме идеологических ;)

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

EXL ★★★★★
()

Zig также разрушает миф, что вам нужен Mac и Xcode для компиляции кода для Mac OS

А вот про это поподробнее. Т.е. я могу собирать всякую гуйню для макоси без всяких костылей под линуксом? Хедеры они выложили. А где брать либы для процесса линковки?

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

Так что или C или что-то типа Zig.

Сейчас это скорее или rust, все остальное слишком не популярно, а так forth или какой из вариантов паскаля ничем ни хуже для микроконтролеров.

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

программы на Rust собираются намного медленнее

Не медленее чем C++, если конечно не писать на C++ как на улучшеном си. Вообще на расте тоже можно писать в процедурном стиле не используя вывод типов, обобщенные функции и макросы, интересно было бы замерить скорость компиляции для такого кода.

стандартной библиотеке беда с обработкой ошибок

Можно примеры?

Бинарники получаются жирнее.

При статической линковке размеры одного порядка.

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

если конечно не писать на C++ как на улучшеном си

Как будто что-то плохое. C++ изначально задумывался как улучшенный Си.

Можно примеры?

Паники повсюду без возможности обработать: Линус Торвальдс раскритиковал Rust в ядре.

При статической линковке размеры одного порядка.

Динамическую библиотеку Раста вроде бы пока не завезли. Статическая линковка в обычной (не встраиваемой) системе не нужна. librsvg расжирнел в несколько раз после перехода на Rust.

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

А где брать либы для процесса линковки?

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

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

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

Как раз он более последовательный чем все эти ваши си. @function - встроенная функция компилятора, в отличии от того же С, где вызов параметризованного макроса, функции и встроенной в компилятор функции вообще ничем не отличаются, хотя это совсем разные вещи. Киллерфича - возможность исполнения произвольного кода во время компиляции и использовать результат во время выполнения, ну и во время компиляции доступны вещи, которые во время выполнения нельзя использовать, например целые числа произвольного размера, типы как параметры функций или как возвращаемые значения. За счет этого реализованы дженерики (просто функция возвращающая тип), импорт (встроенная функция @import просто заворачивает все содержимое импортируемого файла в структуру, а структуры без полей можно использовать как пространства имен), compile-time рефлексия (например можно использовать для сериализации/десериализации, типобезопасного printf), условная компиляция (Zig просто не компилирует код, который не используется) и еще много чего. При этом язык очень простой.

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

встроенная функция @import просто заворачивает все содержимое импортируемого файла в структуру

То есть нормальной модульности нет. Тот же сишный #include, только с сахаром.

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

Чуть читабельнее чем поделка местного утырка с трансятором в C++

Может быть, но в данном конкретном примере нет. Ибо в «поделке» будет лаконичнее:

def main
    @print* "Hello " "world"

Собачка показывает, что здесь функция, а звёздочка, то что print принимает по одному звену цепочки. В принципе, работает и без неё:

def main
    @print "Hello "; "world"

В Си printf содержит хитрую макросную магию и форматирующую перлятину. В «поделке» же что-то типа чейнинга. Что используют в Zig я пока не понял.

это просто никому не нужный петпрожект

Хорошо бы если так. Но боюсь, что скоро всех заставят переписывать код с C++ на Rust, а затем с Rust на Zig путём прекращения поддержки компиляторов.

Кстати, Zig сейчас выглядит вполне привлекательно. Рано критиковать. Посмотрим во что он превратится лет через 10.

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

Вот ты гонишь. В Ардуине чистый С++ (gcc-avr), только компилируется не скетч, а шаблон с преамбулой хедеров и мейном, в который делается #include «sketch.uno».

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

Даже не близко. #include как и весь сишный препроцессор с текстом работает. Можно много раз вызывать @import('std') без проблем (результат функций выполняющихся во время компиляции запоминается) и так как это просто функция возвращающая тип - её можно использовать где угодно, например, в примере выше можно убрать const std = @import('std'); и заменить другую строчку на const stdout = @import('std').io.getStdOut().writer();.

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

Кстати, Zig сейчас выглядит вполне привлекательно.

Зря разработчик выложил исходный код.
Среди итишников поехавших ОКЕАН.

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

Раз уж ты такой пурист, то давай примеры равноценные: или embedded C++ без io (которого в контроллерах все равно нет) или пример на зиге с локализацией и динамическим созданием строк. Типа «hello, , your weight is 87.4kg» (и чтобы запятая на русском была).

Потому что #include тянет locale и много других вещей.

И не надо вопить про «раздутость» библиотеки: уже сказали, что при динамической линковке нагрузки от этого нет, в на контроллерах (где нужен «минимализм») io нет. Просто потому что выводить некуда.

А так да, отличная замена ассемблеру для написания hello world.

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

В Zig print первый параметр имеет comptime тип и должен быть известен во время компиляции, внутри используется compile-time рефлексия + форматная строка парсится во время компиляции. Для всего этого не нужен какой-то отдельный синтаксис, все пишется как почти как обычный код, но в рантайме если это скомпилируется (то есть все типы корректны и передано корректное кол-во параметров и форматная строка корректная) ничего лишнего выполняться не будет.

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

А ты уверен, что это быстрее в рантайме? Тут или код будет бухгуть => induction cache pollution или ещё какая-то странная фигня. Форматирование по шаблону это почти memcopy.

Может будет какой-то выигрыш, если программа только текст трансформирует (рендеринг шаблонов на веб-сервере). Есть бенчмарки в сравнении, например, с fmt на С++?

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

Я про скорость ничего не говорил, только про то, что все это отвалится во время компиляции если не правильные параметры передать.

А скорость будет зависеть от ситуции. Очевидно что в абсолютном большинстве случаев такой подход должен быть быстрее, а там где нет - можно просто использовать что-то другое, никто не запрещает тот же printf вызвать.

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

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

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

Как будто что-то плохое. C++ изначально задумывался как улучшенный Си.

Всё таки Бьярн хотел в высокоуровневость и ООП. При том, что все уродства С оставил. Назвать это просто «улучшенный С» было бы пепедергиванием фактов. От С ему нужна была скорость компилированного кода и совместимость, но проблемы С он не собирался исправлять.

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

От С ему нужна была скорость компилированного кода и совместимость, но проблемы С он не собирался исправлять.

Скорее всего для него это были вовсе не проблемы, а фичи языка …

Вот к примеру если летом буду ходить в шапке ушанке, то скажут …
Потому что они не понимают, что это ФИЧА!

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

Вот к примеру если летом буду ходить в шапке ушанке, то скажут … Потому что они не понимают, что это ФИЧА!

А в многих языках программирования летом ходят не в шапках ушанках, а в

 - шубе;  
 - шапке ушанке;
 - и валенках

И всем рассказывают как это хорошо.

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

Чем додумывать, послушайте его интервью и почитайте, что он пишет в книгах.

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

Не понимаю, откуда берется этот миф про «скорость скомпилированного кода». Скорость скомпилированного кода во многом зависит от качества исходного кода, которое, в свою очередь, сильно зависит от пряморукости разработчика. Зависит от задачи ещё. Можно написать программу на питоне, которая будет вычислять быстрее, чем на С, если в первом jit, а во втором рукожопость расставила «слипов» по коду.

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

И всем рассказывают как это хорошо.

Например

 ++Шуба--

КРАСОТИЩЕ ЖЕ!

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

Он скорее для замены ассемблера (и Си)

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

Хотя, конечно, есть ещё вариант что ты лучше знаешь для чего предназначен язык, чем авторы этого языка.

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

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

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

Интересный язык программирования - ОДНОЗНАЧНО!
Хорошо, что автор языка не «прибивает гвоздями» язык к ШУБАМ.
То бишь придерживается архитектуре раннего Си.
API должно быть в библиотеках, а не в синтаксисе языка …

Пока все же использую C/C++ без ушанок, которых в них МНОГО.

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

Чем додумывать, послушайте его интервью и почитайте, что он пишет в книгах.

Вот именно, что почитай и послушай. Там он говорит о том, что хотел разрабатывать на чем-то типа Smalltalk, но то, что пробовал было медленно, а ему нужна была производительность скомпилированного кода на C. Киллер-фичи C++ типа шаблонов появились лет через 6 после первой официальной и специфицированной версии C++. А первым делом он работал над ООП.

Можно написать программу на питоне, которая будет вычислять быстрее, чем на С, если в первом jit, а во втором рукожопость расставила «слипов» по коду.

У кого что болит? Какой в попу Питон, какой джит в начале 80х? Вот Страуструп дурак, да? Всял бы Java, взял бы Python, и не парился бы с созданием C++…

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

API должно быть в библиотеках, а не в синтаксисе языка …

Сказанное касается лишь языков «заточенных» для системного программирования …

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