LINUX.ORG.RU

Zig 0.8

 , ,


1

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

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

Подход да, нестандартный, но во многих случаях он подходит даже лучше С++/Джавы.

Как именно ООП-формошлёпство на Rust’е будет удобнее и лучше, чем на C++/C#/Java?

Но для этого нужен принципиально новый взгляд на привычные вещи.

Если этот «новый взгляд» не предлагает никаких значительных удобств, а лишь напротив, всё усложняет, значит рынком он никогда не будет воспринят. Think different без киллер-фич а просто с другим «видом сбоку» довольно слабый аргумент для перехода.

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

Что ещё мне забавного расскажешь?

Так по твоей ссылке как раз подтверждение тому что выше говорил что gtk как gui тулкит не используется, из него берутся только низкоуровневые и общесистемные вещи, вся отрисовка gui делается без gtk компонентов, там же рядом все тоже самое для офтопика https://github.com/mozilla/gecko-dev/tree/master/widget/windows тот же низкий уровень из winapi.

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

Qt я называл, игрострой тоже, поддержка легаси не в счёт

Ещё можешь вписать GCC, llvm/clang/и_всю_эту_обвязку. Можно ещё интереса ради так глянуть - неоспоримо, что имеется корреляция между долей языка для разработки и упоминанием его в описании пакетов в репах дистра, посмотрим:

# C
$ pacman -Ss | egrep -i '[ .,]c[ .,]' | wc
    188
# C++
$ pacman -Ss | egrep -i '[ .,]c\+\+[ .,]' | wc
    175
# C++ + Qt
$ pacman -Ss | egrep -i '[ .,]c\+\+[ .,]' | grep -i '[ ,.]qt[ ,.]' | wc
      7
# Самое вкусное - убийца всего и вся - Rust
$ pacman -Ss | egrep -i '[ .,]rust[ .,]' | wc
     11

Ставить что-то на Qt вообще считаю зашкварными, прибегаю к этому лишь если альтернатив вообще нет.

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

Эта ссылка отличное подтверждение твоей некомпетентности.

вся отрисовка gui делается без gtk компонентов

Окно Firefox, использующее GtkHeaderBar и встаиваемые в него виджеты, практически все popup-меню в UI браузера, адресная строка реагирующая на чисто-GTK’шную комбинацию |Ctrl+Shift+U => a9, Enter| и отрисовка <textarea> в который ты сейчас пыхтя пытаешься написать оправдание своей некомпетентности, всё это и много чего ещё делается через виджеты GTK+.

https://github.com/mozilla/gecko-dev/blob/0080b2b390d920f3721793053644ec6cec17377b/widget/gtk/gtkdrawing.h#L143-L351

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

Серверные приложения

тут доминируют Java и С# без вариантов, да даже Python и JavaScript занимают больший процент, чем плюсы

финансовая/биржевая сфера

там зоопарк платформ, конечный код для которых пишется на скриптоте

embedded

он там благодаря Qt как раз продвигается, потому что некутешный embedded гуй я вообще толком не припомню

high performance computing

тут - да, но его пишут 2,5 анонимуса в гугле да амазоне

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

Угу. А ещё смешнее то, что в результатах всего два приложухи, и обе - калька с нормальных языков ):

TCP connection hijacker, rust rewrite of shijack

Cross-platform Rust rewrite of the GNU coreutils

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

ЗЫ: это не все растопакеты, не все попадает под поисковый шаблон, но всё же )

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

Доминирование не в доле других языков, а в доле C++.

Другими словами серверных/финансовых/embedded/hpc приложений на C++ в промышленном обороте гораздо больше чем формошлёп-приложений на Qt/C++.

И кстати не стоит манипулировать статистикой и объединять Qt c GameDev, где Qt не используется, а C++ очень активно используется.

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

Совершенно верно. Просто тот кто занимается формошлёпаньем на С++/QT, тот и видит вокруг только себе подобных. А то что GameDev, базы данных, компиляторы и куча другого специализированного софта пишется на С++ без QT ими просто игнорируется.

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

В Arduino нет C++. Там свой язык с похожим синтаксисом.

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

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

Просто тот кто занимается формошлёпаньем на С++/QT, тот и видит вокруг только себе подобных

Похоже на правду. Я и сам застрял глубоко в java crud и вылезти уже не получается…

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

Какие удобства, какой «Think different»? Какая-то игра абстрактными понятиями. Раст в целом логичнее и стройнее выглядит, чем «традиционная» ООП-лапша «паблик статик файнал эксплисит инт мэйн» и вот это всё. Раст многое заимствует из функциональщины, и после Жавы и сородичей это выглядит просто глотком свежего воздуха и здравого смысла.

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

Про некомпетентность ненужно, ты сейчас ее сам демонстрируешь, в файле на который ты дал ссылку (gtkdrawing.h) на самом верху написано:

 * gtkdrawing.h: GTK widget rendering utilities
 *
 * gtkdrawing provides an API for rendering GTK widgets in the
 * current theme to a pixmap or window, without requiring an actual
 * widget instantiation, similar to the Macintosh Appearance Manager
 * or Windows XP's DrawThemeBackground() API.

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

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

GUI система не используется, функции из GTK используются только для рендеринга элементов

Красиво переобулся в воздухе. А начинал-то как, «используют чтобы тупо получить окно», вот это всё.

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

Ну так можно договориться что например Qt на офтопике просто оберка над WinAPI он же точно также как лисичка под Gtk рисует контролы через WinApi. Но вообще цели ругаться у меня нет, я только пытаюсь донести мысль что браузеры не используют Gtk как GUI библиотеку.

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

Спасибо. Как-то всё скомкано. Вроде оно может работать без llvm, но версия компилятора без llvm почему-то долго выдавала ошибки при компилировании хелловордов. Зачем-то демонстрировал использование встроенного ассемблера. Ещё вот эту книжку советовал для ужатия данных в структурах: https://dataorienteddesign.com/dodbook/

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

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

Потому что self-hosted compiler еще в процессе разработки, он сейчас запланирован на версию 0.9.0. Хотя он уже сейчас частично используется в некоторых местах.

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

Но вообще это всё шаткие системы. Если автор Circle забросит проект, то весь наш хитроумный код превратится в тыкву.

Аргумент годный. Что касается Circle, то там исходники закрыты, то есть да. В — тыкву. Что касается Zig, то он открытый и кто вдруг начнет критически от него зависеть, могут подхватить разработку. Такое регулярно случается со старыми версиями фреймворков, от которых сообщество отказывается.

Но, в целом, есть проблема востребованности метапрограммирования вообще. Я сильно удивлен, что оно в С++ вообще хоть как-то дышит и даже работает, принимая во внимание то, на сколько оно там ущербное по сравнению с тем, как его можно было бы сделать (Zig), если бы не костыли (TMP) и костыли к костылям (constexpr) и необходимость тянуть всё это сквозь время и пространство.

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

С (а) все относительно просто, такие есть: обработка и хранение данных, веб-фреймворки и интеграция (DSL).

C (б) все сильно сложнее, особенно учитывая печальное положение с инструментами в С++ вообще (мы застряли в 80-х, ну чуть-чуть в 90-х). Тут нужно поднимать систему сборки до уровня распределенной дата-платформы (language server на стероидах и веществах), чего ни в Rust, ни в Zig, ни в Circle нет. Оно немного есть в Scala.

Т.е. совсем не сложно сделать, например, расширение компилятора Clang для С++, позволяющее вызывать через JIT скомпилированные функции (метафункции) во время компиляции и дать им доступ к AST. Можно даже компилировать текст во время компиляции, если работа с AST кажется слишком громоздкой (а она - да). Но чтобы вывести всё это на практический уровень, нужна автоматизируемая платформа, изначально заточенная на метапрограммирование. И тогда всё будет хорошо :)

anonymous ()

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

Перед самой пандемией меня пробовал хайрить Bloomberg для переписывания какой-то там их системы с древнего С++ на современный.

Просто вокруг С++ уже давно нет хайпа, поэтому он не «звучит» в медиа.

anonymous ()

Херня ваша Зига! Почитал «зачем нужен Zig» и не нашёл ВООБЩЕ НИЧЕГО путного, с какого бы рожна бросать тот же D ради этого фюрерского ушлёпища.

«скрытые вызовы функций»? Ну да, ЗАТЕМ ОНИ И ПРИДУМАНЫ!! Пример на D:

a = b.c


Здесь b.c запросто может быть вызовом b.c() (это getter от проперти), но в этом и бенефит кода, что его НЕ НАДО ИЗМЕНЯТЬ, если ты вдруг решил, что вместо поля тебе нужно проперти - вызов вкоде будет идентичен! Другими словами, это зигующие долбоклюи борятся с.... синтаксическим сахаром! С теми самыми улучшалками, которые экономят ЧАСЫ на написание кода. Ну-ну... успехов задротам!

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

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

Очень похожее по сложности языка, имелось в виду?

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

Что касается линейных типов в Rust, то в будущем C++ будут lifetimes, что не то же самое, но то же хорошо.

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

вот тут целый час автор zig объясняет чем его язык лучше C

ха-ха!!!! :))) ЧАС, Карл! Не многовато для одного недоязычка?
Чтобы объяснить, чем крут язык, достаточно в течении 5 минут назвать все киллер-фичи. Кто фичи понимает, тот оценит (включая их полезность для личных бизнес-задач).

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

Чтобы объяснить, чем крут язык, достаточно в течении 5 минут назвать все киллер-фичи

ну можешь посмотреть пять минут. Там с первых секунд он начинает приводить примеры. Я специально поставил в ссылке 336 секунду.

https://www.youtube.com/watch?v=Gv2I7qTux7g&t=336s

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

Circle предлагали добавить в стандарт С++. Но вроде как не поддержали в комитете такой идеи…

Тут начинает работать психология. Constexpr сразу надо было делать таким, чтобы поддерживалось полное множество языка во время компиляции. Но пошли по другому пути, на котором ограничения снимают «по копейке» каждые три года. А тут бац - и сразу вводим @meta. И встает логичный, но очень неудобный для всех вопрос, а что мы до этого 10 лет делали?

В целом, полноценное метапрограммирование времени компиляции (с необходимой операционной обвязкой) в С++ будет, по крайней мере как расширение Clang. Как появятся приложения, использующие его, так это попадет и в стандарт в конце-концов.

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

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

В целом, полноценное метапрограммирование времени компиляции (с необходимой операционной обвязкой) в С++ будет, по крайней мере как расширение Clang. Как появятся приложения, использующие его, так это попадет и в стандарт в конце-концов.

У меня все не так, но попытаюсь говорить в стиле треда.

Еще AST нужен с хорошим API и документацией и возможность добавления в исходники ссылку на parent node, содержащий метаданные требуемого объекта и чтобы в run-time можно было извлекать эти данные …

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

«Nothing better than C»

Это справедливо только при текущем уровне автоматизации программирования в С и С++. Да, «проверять в уме» С-шный код гораздо проще, чем С++ный. И кое-где это решает. Но эта простота не всегда достижима.

Путь господин Торвальдс покажет, как можно делать мономорфизируемое обобщенное программирование на С, а без него в структурах данных далеко не уедешь. Если ему в ядре оно не надо, то не ядром единым. А если вдруг встанет потребность проверить глазками выхлоп кодогенератора с DSL на C для момноморфных дженериков...

В общем, на дворе уже третья декада 21-го века всё же. Пароход уже далеко ушел в плане запросов к языку.

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

Еще AST нужен с хорошим API и документацией и возможность добавления в исходники ссылку на parent node, содержащий метаданные требуемого объекта и чтобы в run-time можно было извлекать эти данные …

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

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

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

Судя по вашему посту вы в этих вопросах НИЧЕГО не понимаете.
Зачем флудите?

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

Судя по вашему посту вы в этих вопросах НИЧЕГО не понимаете. Зачем флудите?

Ну если кто-то понимает ВСЁ, может бросить в меня камень (нет). Если кто-то понимает ЧТО-ТО, это отлично. Если кто-то понимает в этом вопросе больше, чем я, пусть изложит своё видение. Я, может быть, что-то новое узнаю :)

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

Ну если кто-то понимает ВСЁ, может бросить в меня камень (нет). Если кто-то понимает ЧТО-ТО, это отлично. Если кто-то понимает в этом вопросе больше, чем я, пусть изложит своё видение. Я, может быть, что-то новое узнаю :)

Sorry.
Мне эта тема близка и многое уже наработано.
Но вовсе не так как вы предлагаете.
Пожалуй послушаю об иных подходах …
Sorry.

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

Я, может быть, что-то новое узнаю :)

ООП в виде а-ля class это всего лишь один из способов представления объектов.
Так вот с использованием Си /очень удобного языка для системного программирования/ можно реализовать любую архитектуру представления объектов и любой сложности.
Можно для этого использовать и иные языки программирования конечно, но у меня ИМХНО ни разу не возникло такого желания.

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

но в этом и бенефит кода, что его НЕ НАДО ИЗМЕНЯТЬ, если ты вдруг решил, что вместо поля тебе нужно проперти

С таким же успехом можно в Makefile запихнуть перед компиляцией обработку исходников sed’ом.

Проблема в том, что при чтении такого кода ты не можешь сказать, меняет ли он что-то ещё, кроме a, форматирует ли диск, читает ли поле из b или возвращает погоду на Марсе.

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

Ну окей. Хотя я в итоге ничего не понял (pun intended).

Много постил на эту тему, но видимо эта тема мало кого интересует …
Послушаю лучше других.

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

можно реализовать любую архитектуру представления объектов и любой сложности

Это не совсем так. Реализовать-то можно, но потребуется вводить новый язык поверх этой объектной модели, чтобы её можно было «удобно» использовать. Пример: явные ref/unref в GTK, так как С не может в автоматические деструкторы.

Что с моей точки зрения могло-бы «вылечить» С в этом отношении, это нормальный макропроцессор уровня AST, который позволял бы удобно оборачивать собственные объектные надстройки и control flow. Zig именно в этом плане видится очень интересным экспериментом.

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

Но на практике все эти надстройки можено делать и над С++, и даже лучше, потому что к нашим услугам еще и полный по Тьюригнгу мономорфизатор обобщенного кода. Уже одно это – особый разговор.

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

Пример: явные ref/unref в GTK, так как С не может в автоматические деструкторы.

Это один из частных, но важных вопросов.
Хороший allocator много упростит работу с memory.
ИМХО это не проблема, а всего лишь подсистема работы с памятью.

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

Он не поддерживается языком, но вот [url=https://www.nmichaels.org/zig/interfaces.html ]так например можно использовать[/url]. Используется в стандартной библиотеке для аллокаторов, например. Все функции динамически выделяющие память принимают *std.mem.Allocator в качестве аргумента.

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

Динамический полиморфизм поддерживается или будет?

https://ru.wikipedia.org/wiki/Полиморфизм_(информатика)

Полиморфизм в языках программирования и теории типов — способность функции обрабатывать данные разных типов

Пока нет.
Обеспечена возможность динамического создания /без участия компилятора/ и работы с объектами любой сложности.

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

Собственно КАК разработать понятно.
Осталось за малым - РАЗРАБОТАТЬ.

Не знаю сколько времени на это уйдет /какая-то часть языка будет разработана скорее всего за несколько месяцев/.

Но в этой ТЕМЕ - не новичек.

Это будет не а-ля скриптовый язык однозначно.

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

ИМХО это не проблема, а всего лишь подсистема работы с памятью.

Это просто демонстрация того, что далеко не любая семантика DSL хорошо «ляжет» на семантику хост-языка. Другой пример – мономорфные дженерики. Тут уже аргументом «а давайте тут будем использовать сборщик мусора» не отделаться. Как какой-то анонимус говорил выше (я перефразирую смысл), что с какого-то момента такие собственные надстройки над С становятся на столько громоздкими, что проще сразу использовать С++ и не мучить мозг.

Тут дело следующее. Есть теория Колмогоровской сложности и соответствущие теоремы. Описательную сложность нельзя существенно уменьшить конечными трансформациями. Сложная программа будет сложна (громоздка с точки зрения человека) на любом языке. Какого-то упрощения можно добиться только подключением вычислтельных бюджетов для «оффлоадига сложности» с программиста на машину (автоматизацию). Сборщик мусора – пример такого размена, за который приходится платить в рантайме.

Интерес сейчас представляют языки, которые позволяли бы этот принцип поставить на поток. И обычный С точно не из их числа. По причине слабого тулинга. А вот Zig – интересный эксперимент в этом направлении (метапрограммрование).

anonymous ()