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

API можно использовать для работы с отдельными объектами в memory, объектными базами данных в виде файлов, …

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

По моему опыту, технология динамической компиляции работает «с замечаниями» и это хорошо видно на примере GraalVM. У того же джаваскрипта там слишком большое время разогрева, даже относительно ванильного nodejs. Причем компилятор беззастенчива отжирает два ядра под себя. Т.е. технология совсем не микросервисная. Это же касается и десктопа: запустил и еще условные полчаса всё очень медленно.

Но у Graal есть native-image, AOT-компилятор. Который в некоторых случаях может перегнать в натив и запустить над минималистичной SubstrateVM. Его используют для разработки тех самых микросервисов на Java. Т.е. сам стек довольно универсальный, почему я его и порекомендовал.

Что же касается БД для метаданных, то тут мы уже сталкиваемся с проблемами проектирования самих БД. БД для метаданных должна быть (а) мультимодельной и (б) очень быстрой. А у тебя еще и (в) — динамической. Обычно приходится выбирать 2 из 3, если ты не собираешься писать свой движок вместе с API.

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

У того же джаваскрипта там слишком большое время разогрева, даже относительно ванильного nodejs. Причем компилятор беззастенчива отжирает два ядра под себя.

Монстра не будет!
Пока все ok и забегать вперед не буду …

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

Что же касается БД для метаданных, то тут мы уже сталкиваемся с проблемами проектирования самих БД. БД для метаданных должна быть (а) мультимодельной и (б) очень быстрой.

Это да.
Но пока задаче не в создании универсальной СУБД.
Хотя ведь любая СУБД, ведь то же в какой-то мере «динамическая».
Конечно можно будет объектную базу использовать к примеру как а-ля 1С …

А почему бы и нет?

Да много где можно будет использовать …

(read/write, а не только для чтения), так?

Конечно.

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

Еще раз акцентирую на то, что ни какую революцию не создают.
Некий вариант того, о чем все «знают», но

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

Хотя ведь любая СУБД, ведь то же в какой-то мере «динамическая».

Не любая. БД может быть иммутабельной, что сильно упрощает её внутреннюю структуру. Для иммутабельных БД проблема пробрасывания мультимодельных данных в рантам решается довольно просто. Какой-нибудь бинарный O(1) zero-serialization формат графа просто mmap-пится в процесс. И такие данные можно запихнуть в byte[] и прилинковать к самому бинарнику. Всё будет хорошо.

А вот если эти данные могут меняться в рантайме, всё становится значительно сложнее. Так как появляются многопоточность и дурабельность. Структуры данных значительно усложняются и замедяются на 1-2 порядка. Уже не граф на связных списках, а b-tree (над которым тот граф еще нужно построить), и т.п.

Динамизм не бесплатен. И проблема в том, что часто он слишком дорог (его бенефиты не опкупаются).

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

Структуры данных значительно усложняются и замедяются на 1-2 порядка.

Нет.
В основном пока API много упрощает разработку а-ля СУБД, а-ля 1С, reporting, GUI, графические форматы данных, документы, книги, … … … Можно заточить и для число дробилки.
Серебряной пули, как известно - нет.

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

И проблема в том, что часто он слишком дорог (его бенефиты не опкупаются).

Все зависит от того, для чего использовать.
Если правильно использовать, то окупится, да еще прибыль принесет …

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

Динамизм не бесплатен. И проблема в том, что часто он слишком дорог (его бенефиты не опкупаются).

Если нет API, умеющего эффективно их использовать, то тогда да …

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

Динамизм не бесплатен. И проблема в том, что часто он слишком дорог (его бенефиты не опкупаются).

Мифов на эту тему МНОГО, а эффективного API - МАЛО.

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

Если нет API, умеющего эффективно их использовать, то тогда да …

Тут не в API дело. Тут на уровне самих структур данных. Статические структуры данных быстрее динамических. Cравни обычный массив и динамический массив над b-tree. В первом случае у тебя O(1) или один поиск в RAM в худшем случае. А во стором случае у тебя 3-5 таких же поисков в RAM в лучшем случае. Другое дело, что какая скорость твоим юзкейсам нужна. Т.е. на сколько быстрый доступ к метаданным будет критическим. Если ты в нишу Пайтона метишь, то, наверное, уровнь SQLite тебе за глаза хватит. Если ты делаешь высоконагруженное приложение, которое на каждый запрос будет к метаданным ходить, то, наверное, не хватит. Если тебе метаданные нужны только во время развертывания приложения, то скорость доступа к ним не критична.

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

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

Эк вы хватили.
Это уже

Огородами, огородами и Котовскому

У вас опыт проектирования такого рода данных имеется?
Скорее всего - нет …
То о чем вы говорите важно и учитывается при разработке архитектуры объектов.
Пока все ok!

Не спешите делать поспешные выводы …

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

У вас опыт проектирования такого рода данных имеется?

Более чем :) Я кастомные движки БД делаю, заточенные под задачи.

Не спешите делать поспешные выводы …

Так я и выясняю, какую практическую задачу ты решаешь :)

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

Так я и выясняю, какую практическую задачу ты решаешь :)

Уже многократно ответил.

Что касаемо прикладных разработок, то пока ведется разработка rapid системы, позволяющей вести разработку проектов, использующих:

  • графику;
  • мультимедию;
  • систем данных;
anonymous ()
Ответ на: комментарий от anonymous

ведется разработка rapid системы,

Ну вот. Т.е. тебе метаданные нужны во время разработки, а не во время выполнения?

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

Ну вот. Т.е. тебе метаданные нужны во время разработки, а не во время выполнения?

Это уже не смешно …
Мои предыдущие посты читали?

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

Мои предыдущие посты читали?

Читал, но ты так абстрактно отвечаешь, что я вынужден додумывать. И тут уж как моя фантазия ляжет.

Я понимаю, что ты хочешь иметь rapid app dev, встраиваемый в приложения. Чтобы «нажал кнопочку, и перешел в редактор форм». Мой вопрос в том, ты изначально предполагаешь, что к метаданным объектов должен быть быстрый доступ во время выполнения кода, или он нужен только во время сессии дизайна?

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

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

В чем здесь трудно понимаемая абстракция?
API обеспечивает возможность создания/изменения/сохранения … динамических объектов на основании метаданных.

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

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

Конечно быстрым.
Но работы еще МНОГО.
Пока все ok!

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

В чем здесь трудно понимаемая абстракция?

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

API обеспечивает возможность создания/изменения/сохранения … динамических объектов на основании метаданных.

Звучит, как ORM.

Ты аналогичную задачу решаешь?

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

Звучит, как ORM. Ты аналогичную задачу решаешь?

И близко нет …

Хорошо приведу такой пример.
У вас имеется хендлы, содержащие сотни структур, которые используются для работы некоего API.
Как это обычно решается?
Используем компилятор и линкер для создания некоего приложения.

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

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

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

Работы еще МНООООООООГО …

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

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

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

Имеются тонны алгоритмов, которые разработаны для работы с какими-то данными о которых не компилятор не линкер ни чего не знают.

Т.е. у тебя есть некая объектная модель и ты хочешь её сделать персистентной (в смылсе, сохраняемой). Только у тебы свой движок персистентности, а не ORM. Ближайшая площадка для применения — RAD.

Так?)

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

К теме это всё же косвенно относится, так как тут, согласен, огромная площадка для метапрограммирования.

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

Да, согласен. Я более-менее прояснил для себя. Спасибо!

И вам спасибо!
Хоть раз нормальный диалог был без переходов на «ты дурак».

Тема ОБШИРНЕЙШАЯ и не претендую на создание «серебряной пули».
Но пока все ok!

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

Ну, если что, мои наилучшие пожелания успехов! Может еще пересечемся на этой почве)

Вы меня похвалили, а я вас.
Теперь мы

УВАЖАЕМЫЕ ЛЮДИ
anonymous ()
Ответ на: комментарий от aist1

Теперь «сраться» на форуме будет как-то уже не с руки!)))

Собственно обсудили лишь хоть «о чем речь».
Это всего лишь самое острие айсберга вопросов …
Все о чем говорил ранее в постах о линкере, компиляторе, … это не плод фантазии хвастуна, а реальная работа.
Часть из работ уже ведется, другая еще и не начата.
Работы МНОГО!

В какой-то мере это разновидность OLE.

Но архитектура и возможности совершенно не такие как у Microsoft.  
Скорее можно говорить лишь о том "Какая от него польза?".

Что касается Zig, то у него работа с метаданными в compil-time.
То о чем было сказано в постах у него нет.

Ныне очень популярна тема метапрограммирования в compil-time.
Что могу сказать?

Интересная игрушка

Почему игрушка?
Потому что мы еще не обсудили вопросы, связанные с синтаксисом и фичами языка, обеспечивающего возможность разработки обобщеннных алгоритмов.
Здесь ГРОМАДНЫЙ пласт вопросов.
Разработаю, тогда и обсудим …

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

Форум то разработчиков …
Вот потому то и критикую треды в которых

мЕгают светодиодом
anonymous ()
Ответ на: комментарий от aist1

Я так понимаю, это всё пока что не публично?)

Да, пока так.
Публично и бесплатно будет raid система.
Что до публикации исходников, то рановато эшо - ОДНОЗНАЧНО.

PS: GUI еще и не начинал разрабатывать, но core уже близко к тому, что его можно будет использовать и для GUI.
GUI то будет обеспечивать возможность использования динамических объектов …

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

Это нормально. Как говорят художники, «половину работы не показывают».

Эскизы, это еще не картина …

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

Как говорят художники, «половину работы не показывают».

Если не секрет, то какие разработки ведете?

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

Не секрет. У меня три «долгих» проекта: Раз, два и три.

Мемория — как раз хорошая задача для полноценного метапрограммирования. Я уперся в ограничения TMP и решил хакнуть Clang. Но на современном уровне.

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

Гы, а бывает половина эскиза)))

У меня пока лишь API обеспечивает возможность использования динамических объектов на основании метаданных.
Это всего лишь штрихи к экскизу …
Разработка OLE трудоемка …

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

Как говорят художники, «половину работы не показывают».

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

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

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

Может быть и нет. А может не хватает смелости себе в этом признаться. Можно попробовать это выяснить с помощью ответов на вопросы.

  1. Представьте, что проект завершен. Не пугает такая перспектива? Что дальше будете делать? Что мешает заниматься этим сейчас?
  2. Есть какой-то срок, после которого Вы прекратите разработку, если проект будет далёк от завершения? Можете назвать дату?
  3. Какая мотивация у разработки? Кто-то платит за неё? Она помогает другой работе, досугу?
Kogrom ()
Ответ на: комментарий от anonymous

Ответь за меня сам

Хорошо
  1. Вот есть складной зонт, а есть складной велосипед. Идея на поверхности. Надо создать складной зонт-велосипед. В качестве дополнительных функций это может быть ещё и нож с телефоном.
  2. Я уже сделал из картона прототип. Он пока двухмерный и масштаб не тот, но от дождя спрятаться под ним уже можно.
  3. Думаю, что швейцарский нож - просто интересная игрушка. Обсудим это когда я создам свой складной нож-зонт-велосипед. А пока работы МНОГО.
Шутка

Дядя Вова.

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

Думаю, что швейцарский нож - просто интересная игрушка.

Наверное вы обижаетесь …
Почитайте посты диалога с @aist1 в них ни какой напыщенности и все по делу.
А вы какой-то гадости по напридумывали и стараетесь всеми силами «уколоть».
Как вы думаете как мне относиться к вашим постам?

Будут посты о разработке, будут и нормальные ответы.
Будут «какашки» - просто не буду отвечать.
На вас не обижаюсь вообще то и жду постов от вас по разработке.
Конечно с благодарностью приму и критику от разработчика, а не от форумчанина, который хочет просто «уколоть».

Желаете продолжить диалог?

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

Ты напрасно становишься в защитную позицию, а юзер Kogrom тебе, на самом деле, добра желает. Показывать или не показывать, рассказывать или не рассказывать — это твоё дело. Но самая частая реакция, с которой OSS-разработчик столкнется, будет полное равнодушие потенциальных юзеров и подозрения работодателей, что ты у них что-то воруешь. Последнее, кстати, составляет серьезную проблему для нас, так как закон и его исполнение целеком и полностью на их стороне (по факту). За nginx встал весь Интернет, за условного Васю с Лора не встанет даже Лор.

Так что то, что люди к тебе тут хотя бы просто не равнодушны, советы какие-то дают — считай это за благо для тебя. Нормальная (статистически) реакция на тебя — это равнодушие. Это в 90-х, когда софта было еще мало, каждый новый проект встречался овациями. А сейчас люди пресыщены впечатлениями. И надо тупо затратить много денег, чтобы хотя бы просто привлечь их внимание.

Если не веришь, прикинь, скольких авторов OSS, которым ты пользуешься и от которого ты зависишь, ты знаешь? Интересуешься ли ты чьей-то жизнью? (А ведь за каждой софтинкой стоит чья-то жизнь.) Может, ты кому-то на Патреоне даже донатишь ежемесячно? Если нет, то — плохи дела (для тебя, как будущего автора). Другие будут точно так же относиться к тебе. OSS генерирует сотни миллиардов $value в год. Но достается это всё не нам. Нам достаются равнодушие пользователей и подозрения работодателей.

И если ты решил стать на путь автора, будь ко всему этому готов. Ты на всё это уже подписался. И не обижайся тут :)

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

И если ты решил стать на путь автора, будь ко всему этому готов. Ты на всё это уже подписался. И не обижайся тут :)

На ЛОР нужно обижаться только на себя …

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

И если ты решил стать на путь автора, будь ко всему этому готов. Ты на всё это уже подписался.

Мне это пока не нужно.
Еще многое предстоит сделать …

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

Еще многое предстоит сделать …

Первым делом тебе нужно вывести свой проект из-под действия соглашения с твоим работодателем о передаче авторских прав. Это, конечно же, если ты работаешь программистом или в компании, разрабатывающей ПО. Better safe than sorry.

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

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

С этим проблем нет.

OLE весьма полезная технология.
Пока разработка ведется в Windows, но код ни на одну «.» не зависит от нее …

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

стараетесь всеми силами «уколоть»

Эти «уколы» в равной степени относятся и ко мне, и к ещё некоторым разработчикам на форуме.

Будут посты о разработке, будут и нормальные ответы.

Это и есть о разработке. Когда что-то создаёшь, то главное настроить не компьютер или среду разработки. Главное - настроить свою голову. Если я не ошибаюсь, и ты действительно Владимир, то о твоём проекте мы говорили ровно год назад и тогда по описанию он был примерно на той же ступени разработки. Что изменилось за год?

Ну вот @aist1 говорит о каких-то деньгах. Я думаю, что это не так важно. Деньги можно заработать разными способами. Здесь же более важно получать ту же радость от разработки, которая была, когда мы были студентами. Соответственно, процесс важнее результата. В данном случае, не важно, долгострой у нас или нет.

Желаете продолжить диалог?

Зависит от того, нужен ли результат или достаточно процесса. Меня за результат прямо в этой теме назвали наркоманом (если я правильно расшифровал), а тебя в какой-то другой теме местным юродивым. Разница, конечно, не сильно велика. Можно ещё эту тему почитать: Memoria - инструментарий для разработки структур данных - нужны отзывы В ней @aist1 нас таки обошёл. Всё-таки толстым школьником быть лучше, чем юродивым или наркоманом.

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