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

Тот же Circle.

Да, интересно. При том, Вы видите тут удобное метапрограммирование, а я вижу внесение в C++ моих любимых питоновских конструкций.

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

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

Как дела у раста с Qt ?

Ох, ну вот это прямо убийственный аргумент😆 А если я отвечу, что всё плохо, это будет говорить о всратости С++, который не может без костыльного фреймворка с хитрожопым препроцессором и самобытной системой сборки, или о всратости Раста, который не умеет в биндинги к фреймворкам главного конкурента?😏

Биндинги к Культям имеются, можете пользовать, разрешаю.

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

Тут так: если мне нужен GUI, кроме Qt просто нет невырвиглазных вариантов. Либо жирный электрон, но в него раст тоже не умеет.

«Биндинги к Культям имеются, можете пользовать, разрешаю.»

а вы сами-то их использовали?

«Supported Qt versions: from 5.9 to 5.14.» Ну… такое

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

Хорошо, давай уж переведём наш срач в конструктивное русло. Какие библиотеки для C++ ты считаешь «невырвиглазными»? Чистую Сишечку не считаем, её и из Раста можно юзать почти так же просто, как и из ЦПП.

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

Хорошо, давай уж переведём наш срач в конструктивное русло. Какие библиотеки для C++ ты считаешь «невырвиглазными»?

Вы не поняли, невырвиглазный Гуй, а не библиотеки. Необязательно под С++. Его кроме Qt и жирноэлектрона, кроссплатформенных, практически нет. Для любых языков.

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

На моей системе, во всяком случае, примерно 90% ПО, написанного на плюсах - кутешное. Чистый С не считая.

ОС - С, дрова - С, утилиты - С, гуй - Qt + C++, что там остаётся?

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

Ну ещё забыл про Unreal Engine. Но у раста с ним как-то тоже не очень.

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

GTK хотя бы. Да, обычно для кроссплатформы используют Кьют, Электрон или нативку, но ГТК вполне хорош для разработки и на Винде, и на Маке.

Касательно «вырвиглазности», это дело вкуса, конечно, но биндинги к тому же Электронк для Раст есть, а ещё есть Таури, который суть тот же Электрон, но ест в разы меньше при тех же возможностях. Ну и мелочь всякая вроде fltk и wxwidgets.

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

Ага, и много ли у вас написанных на С++ приложений? Попробую угадать: 90% из них будут игры, про которые я уже писал. А если и их нет, то наверное С++ приложений, штук 10 наберётся.

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

На C++ написаны два самых популярных в десктопном Linux приложения – Firefox и Chrom{e,ium}.

Ни один из этих браузеров не использует Qt, а использует GTK+.

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

но биндинги к тому же Электронк для Раст есть, а ещё есть Таури, который суть тот же Электрон, но ест в разы меньше при тех же возможностях.

такого же качества, как для Qt?

Ну и мелочь всякая вроде fltk и wxwidgets.

От последних, например, vlc отказался в пользу Qt, ибо проще код писать

GTK хотя бы.

А вы на нём пробовали писать?

  1. На нём скорость разработки приложения раза в 2 ниже, чем на куте.

  2. GTK == C, а значит, unsafe

  3. GTK не поддерживает андроид

  4. С Embeded у GTK вообще всё плохо

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

На моей системе, во всяком случае, примерно 90% ПО, написанного на плюсах - кутешное

А я удаляю Qt если вдруг устанавливается по умолчанию :)

Qt вырвиглазный. Не вырвиглазный это дефолтный тулкит системы.

Gtk+(2,3,4) на Linux

Comctl или WPF или WinUI на Windows.

На других системах тоже есть дефолтные тулкиты.

Qt- глючное жирное ненужно. Нужное лишь PVS-Studio чтобы показывать как много багов в С++.

https://pvs-studio.com/en/blog/posts/cpp/0801/

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от EXL
  1. Это ровно 2 приложения. Да, жирных, но ровно 2.

  2. а использует GTK+

Только под некоторые ОС и в основном интерфейс у них на JavaScript.

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

Не вырвиглазный это дефолтный тулкит системы.

не кроссплатформенный, я же писал. Кстати, что там у раст с WPF и Сосоа?

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

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

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

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

Ну это нерелевантно, у меня, например, на Qt два приложения.

Полноценно пользоваться Linux-десктопом вообще без Qt – возможно, хоть и будет жутко неудобно, ибо имеется куча програм на Qt, которые более богаты функциональностью и более удобны в сравнении с их GTK-аналогами.

А вот полноценно пользоваться Linux-десктопом без GTK+ – не получится. Ибо сразу отпадает тот софт, в котором линуксоиды проводят 90%+ своего времени – современные браузеры, всякие IDE на Electron/Java/Mono и др.

В любом случае, Qt – не священная корова, к мычанию которой должны все прислушиваться, как представляет твой оппонент. А Rust, по моему скромному мнению, хреново подходит для написания GUI как раз из-за своих нестандартных ООП-подходов. Поэтому ожидать чего-то уровня Qt или даже Swing/AWT на Rust можно будет целую вечность.

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

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

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

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

От последних, например, vlc отказался в пользу Qt, ибо проще код писать

А ты никогда не думал, почему VLC для macOS использует не Qt, а нативные CocoaAPI?

https://github.com/videolan/vlc/tree/master/modules/gui

А причина кроется как раз в том, что «невырвиглазный GUI» у Qt это рекламный лозунг его бесплатных евангелистов. А в реальности дела обстоят несколько сложнее.

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

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

Моя позиция в другом. Я изначально говорил о том, что С++ давно на 90% уехал в Qt и игрострой. И лишь на 10% он применяется как замена сишечке.

А все языки-«убийцы С++» всё время пытаются занять его место в системном программировании, хотя, это по факту, означает лечь в его могилу.

@meliafaro

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

Gtk как замена CocoaAPI ещё хуже. Электрон - тоже. Там вообще на native lookup забили, итак сойдёт.

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

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

Браузеры стали важнейшими программами нашей жизни и серьёзно подкосили популярность и безальтернативность десктопных приложений. Если раньше условные пользователи KDE слушали музыку в Amarok, просматривали PDF’ки в Okular, смотрели аниме и пони-мультики в Kaffeine, и чатились в Kopete, то сегодня для всех этих дел они используют Firefox или Chrom{e,ium}.

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

Я изначально говорил о том, что С++ давно на 90% уехал в Qt

Это не так. Монополия Qt вкупе с C++ охватывает лишь небольшую часть использования C++, в основном там, где имеется формошлёпство.

Gtk как замена CocoaAPI ещё хуже. Электрон - тоже. Там вообще на native lookup забили, итак сойдёт.

В любых кроссплатформенных тулкитах UX/UI будет хуже, чем в системных. Кроссплатформенность это всегда компромиссы, мириться с которыми многие не хотят. Именно потому на Qt и тем более на GTK+ под macOS и Windows довольно небольшое количество популярного ПО.

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

Кстати, что там у раст с WPF и Сосоа?

WPF только для net и уже устарел, теперь WinUI вместо него. Он пока вроде не поддерживает раст, но судя по https://github.com/microsoft/windows-rs то будет прямая автоматическая подержка как и для winrt.

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

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

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

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

лишь небольшую часть использования C++

а где ещё он доминирует?

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

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

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

А то, если по виртуальным машинам типичного юзера считать, то java-машина таки победит, ибо андроид.

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

А то, если по виртуальным машинам типичного юзера считать, то java-машина таки победит, ибо андроид.

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

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

Честно говоря, не владею такой статистикой, лень лазать по десяткам репозиториям с исходниками и проверять, на чём они написаны. В основном мой ходовой софт на GTK или WinAPI, это видно без вгрызания в сорцы.

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

Кады всякие, проф софт инженерный и не только, кишки научных вычислений и иногда (часто) сам научный софт, если там не у всех питон головного мозга. Это всё цпп и это огромный пласт.

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

такого же качества, как для Qt?

Думаю, сравнивать можно с Электроном, а не с Кутями.

GTK == C, а значит, unsafe

Если мы говорим о Раст, то биндинги к С++ тоже unsafe)

GTK не поддерживает андроид

И иОС тоже. Вот только просто так скомпилировать Кьют-приложение под Андроид тоже не получится, нужна куча условной компиляции. Ну и про Embeded то же самое.

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

Думаю, сравнивать можно с Электроном, а не с Кутями.

я в плане качества биндингов, их работоспособности

Если мы говорим о Раст, то биндинги к С++ тоже unsafe)

Таки да

Вот только просто так скомпилировать Кьют-приложение под Андроид тоже не получится, нужна куча условной компиляции. Ну и про Embeded то же самое.

Странно, как у меня получается и даже по arm. Колдовство, не иначе

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

Полноценно пользоваться Linux-десктопом вообще без Qt – возможно, хоть и будет жутко неудобно, ибо имеется куча програм на Qt, которые более богаты функциональностью и более удобны в сравнении с их GTK-аналогами.

Не страдаю тулкитофобией, пусть хоть ГТК, будет, хоть Кьют, хоть Электрон, лишь бы не зоопарк из 10 тулкитов.

А Rust, по моему скромному мнению, хреново подходит для написания GUI как раз из-за своих нестандартных ООП-подходов. Поэтому ожидать чего-то уровня Qt или даже Swing/AWT на Rust можно будет целую вечность.

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

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

Я изначально говорил о том, что С++ давно на 90% уехал в Qt и игрострой

Ну пусть там и остаётся. А 90% - это от чего считается? Создаётся впечатление, что имеется в виду вся ниша компилируемых языков.

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

А 90% - это от чего считается?

от общего числа применения С++

Ну пусть там и остаётся.

а что ж вы тогда на него накинулись?

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

Нет, не меньше. Если ты его не видишь, а игры видишь, то дело в тебе. Гуй пишется на C# в основном, никому там Qt не уперся. В любом случае внутренности это плюсы.

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

я в плане качества биндингов, их работоспособности

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

Странно, как у меня получается и даже по arm. Колдовство, не иначе

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

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

И опять же, он включает в себя GUI.

Доля этого гуя это проценты от общего количества кода более менее сложного приложения.

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

Если ты его не видишь, а игры видишь, то дело в тебе.

Ох уж эти видеокарты, которые выпускают не ради майнинга и игр, а ради CAD-ов. Хотя нет, погодите-ка

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

«Вот только просто так скомпилировать Кьют-приложение под Андроид тоже не получится»

«Просто код достаточно тривиальный для обеих платформ»

Вы уж там определитесь.

«У тебя есть действительно сопоставимый опыт разработки и на том, и на другом?»

я вас спрашиваю

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

то java-машина таки победит, ибо андроид.

В Android нет JVM.

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