После 8 месяцев разработки опубликован выпуск языка программирования Zig 0.11.0, развиваемого при поддержке организации Zig Software Foundation. Язык Zig предлагается в качестве современной замены C, который старается сохранить его достоинства (простота и гибкость использования, предсказуемость кодогенерации, экосистема и т.д.), в то же время добавляя новшества для более эргономичной и безопасной разработки. В частности, Zig содержит:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59554
"замена <s>неоСиленного</s> ненавистного Си" здорового программиста.
Hare - лучшая замена C. К тому же у Hare автономный компилятор, не пртвязанный к LLVM.
Вместо этого привязанный к QBE) Но его все равно намного легче собирать, согласен
А вместо этого он привязан к QBE, который поддерживает всего три архитектуры.
Вроде бы здорово, но язык не production ready.
Он уже используется активно в production. В том числе в стартапах.
когда это стартапы стали показателем успеха? вот если бы его гугл, айбиэм или майкрософт использовали - вот тогда да
И когда же языки программирования в бизнесе стали показателями успеха?))А вот показателем использования в production очень даже.
Или стартапы - это уже недостаточно "production"?)
Бизнес - это и есть production. Крупный бизнес - тем более.
Стартапы на начальных этапах - это, скорее, лаборатория для тестирования идей,а не полноценный production.
Большая часть стартапов - заведомо провал, затеваемый ради проедания денег из венчурных фондов.
Я помню день, когда он только появился. Уже лет 10 прошло и, видимо, пора признать, что популярней D ему не стать. Ну, правда, ncdu тот Васян на этот язык переписал зачем-то, так что уже успешнее ржавчины в определённом смысле.>требование к ОЗУ для сборки компилятора с 10-11 ГиБ до 3-4 ГиБ
кек
Почему? 10 лет это не срок, от "появления".Автор ушёл с работы и начал заниматься языком года 2-3 назад full-time. Появилась команда. Дизайн языка очень сильно изменился.
До этого это можно было считать экспериментальным домашним (хоть и интересным) проектом.
Поэтому яркое будущее этого языка (несомненно) ещё впереди.
> кекСкорее всего это предназначено специально для data-man'а, который на ЛОРе каждый раз про это ныл.
Кек D уже давно как RIP.
Когда Ди рипнется все об этом узнают в новостях
Потому что система для работы и объявления о поездах во многих странах Европы разрабатывается компанией на Ди =)
Что-то вспомнилось про стюардессу на острове....
Что-то вспомнилось ситуация с Arian V
> Что-то вспомнилось ситуация с Arian VИ?
Там то же откопали стюардессу?
> 10 лет.Сразу видно, что ты врешь. язык появился в 2016 году лишь, где-то они сами пишут что с 2015, но врут.
> где-то они сами пишут что с 2015, но врут.Они отсчитывают от первого коммита:
https://github.com/ziglang/zig/commit/8e08cf4bec80b87a7a22a1...> From: Andrew Kelley <superjoe30@gmail.com>
Date: Wed, 5 Aug 2015 14:46:04 -0700
Subject: [PATCH] init
Задавайте вопросы, если интересно. Язык более чем Production Ready для многих сфер.
Назовите тогда для каких, хотя бы парочку?
Везде где есть подходящие библиотеки (или желание написать свои).Embedded, базы данных, языки программирования (на нём уже написано несколько виртуальных машин). И так далее.
По сути ограничения - отсутствие библиотек (и нежелание их писать). Суперкритичный performance (аллокатор не самый топ пока).
И отсутствие платформ каких-то.
А так можно прямо сейчас брать и будет работать.Критичных багов (show stopper) не встречал.
Какую базу данных на нём написали? Какую то кей валью? Как она называется?
Я сейчас пишу на ней базу данных. Это очень долгий и длительный проект.Будет написана - вы о ней услышите.
В БД Turso написали какой-то элемент (команду) на Zig и остались довольны опытом. Хотя основная кодовая база у них на Rust.
> В БД Turso написали какой-то элемент (команду) на Zig и остались довольны опытом. Хотя основная кодовая база у них на Rust.https://blog.turso.tech/zig-helped-us-move-data-to-the-edge-...
Ясное дело, что „довольны опытом”, если они просто транслировали Сишный код с zig translate-c и немного допилили выходной файл :) Мало усилий/затрат и результат приемлемый, правда конечно код слишком подробный получился (на то он и авто-транслятор). Попытался немного подчистить: https://github.com/turso-extended/pg_turso/pull/13 (в сайд-вью лучше видно)
Спасибо.
Некоторые вещи звучат немного странно. Вроде "базы данных" и при этом следующей строкой ограничений - performance. Для баз данных или виртуальных машин перформанс как раз суперкритичен.
Но аллокатор это такое, поправят когда-нибудь.А вот отсутствие библиотек... это да.
Как там в FFI? Насколько геморно использовать либы на других языках?
В этом и фишка Zig. Нет крутого аллокатора в std библиотеке.А так берёте любой супер-крутой аллокатор на С и С++ и используете его.
Я сам ещё ни разу FFI не использовал. Но бесшовная работа с С и С++ - один из главных приоритетов языка.
У него наверное самая лучшая интеграция с С и С++ из всех языков.
Стоит хотя бы сказать что вы можете собирать С и С++ проекты билд системой языка, которая поддерживает работу с хедерами из коробки, включая динамическую генерацию и т.п.
Те всё очень и очень хорошо прямо сейчас.
собирать C++ и иметь бесшовную интеграцию - две разные вещи
cImport для Си только вроде работает
Ну кстати (не бесшовная) интеграция с C++ есть в виде стороннего инструмента, который (как и Zig, пока Aro не завезут в апстрим https://github.com/Vexu/arocc) жрёт то, что там распарсил и проанализировал себе Clang:
https://github.com/lassade/c2z — сырой и багованный, но потенциал есть. Хотя у Nim и Rust с этим намного лучше история (хотя бы потому что возможности хорошо соотносятся друг к другу, в отличии от минималистичного Zig)
> Стоит хотя бы сказать что вы можете собирать С и С++ проекты
> билд системой языка, которая поддерживает работу с хедерами из коробки, включая
> динамическую генерацию и т.п.
> Те всё очень и очень хорошо прямо сейчас.К ложке меда - цистерна дегтя. Оно, как пишут, LLVM требует. Огроменный жырнолиб от полупроприерастов типа гугла и эпла. Раньше вроде без него могло? Зависеть от этой ср@ни, особенно в ситемщине - ну такое себе.
То ли дело
https://gcc.gnu.org/steering.html
GCC steering committee members
David Edelsohn (IBM)
Ian Lance Taylor (Google)
Зачем мне это писать на зиге, если для этого уже все написано на других языках?
Зачем мне это писать на <языке программирования X>, если для этого уже все написано на других языках?
Когда версия 1.0? Продакшен реди версия не может быть 0.11.0
в роадмапе из релиз записок есть:https://ziglang.org/download/0.11.0/release-notes.html#Roadmap
Here are the steps for Zig to reach 1.0:
- Stabilize the language. No more Language Changes after this.
* Complete the language specification first draft.
* Stabilize the Build System (this includes Package Management).
* Stabilize the Standard Library. That means to add any missing functionality, audit the existing functionality, curate it, re-organize everything, and fix all the bugs.
* Go one full release cycle without any breaking changes.
* Finally we can tag 1.0.Внезапно вменяемо.
Но там же нет даты =(
Это займет где-то пару лет. В 2025 ориентировочно.
Чем это лучше всего того же внутри C++? Все это уже есть в С++ (ну разве что без экзотики вроде типа на 65 тыщ бит). Зачем, если, судя по новости, производительность не ставится целью?"Современную систему типов, разработанную с учётом наработок других языков для большей безопасности, производительности и явности, чем в Си (опциональные типы вместо нулевых указателей, выравнивание по адресу как часть типа, целочисленные типы с размерностью от 0 до 65535 бит, кортежи, тип всех типов, тип-сумма и т.д.).
Ограниченную возможность выполнения кода во время компиляции (обе возможности вместе составляют основу метапрограммирования без макросов и препроцессора)."
плюсовский consteval очень сильно отстаёт от зиговского comptime по возможностям (а тот от макросов nim или даже comptime из jai, во втором можно любые программы запускать)
Можно увидеть перечень UB? Что насчёт strict aliasing, как эта проблема решена, если решена?
Их пора не перечислили, компилятор все равно в следующем коммите может поменять поведение, благо не дошли до 1.0. Для алиасинга есть несколько предложений, но пока неизвестно, как возвращение async /await повлияет на UB и этот алиасинг.
В теории UB будет доведено до минимцма по типу „integer overflow for both signed and unsigned types is undefined” (в отличии от C, здесь решили сделать симметрично, чтобы дожать производительность и программист не ломал мозг, для гарантий есть +% (wrapping) и +| (saturating) addition, тоже симметрично работающие и для знаковых, и для беззнаковых), а остальное будет так называемым detectable illegal behaviour (напр. выход за границы массива), проверки которых врубаются/вырубаются в зависимости от режима сборки, или можно переопределить в блоке/функции для всех режимов с помощью @setRuntimeSafety.
https://github.com/ziglang/zig/issues/2402 — про терминологию.
https://github.com/ziglang/zig/issues/1108 — noalias по умолчанию с возможностью разрешить алиасинг, вместо текущего mayalias по умолчанию с возможностью запретить.
https://github.com/ziglang/zig/issues/1966 — собсна и перечислить UB.
https://github.com/ziglang/zig/issues/2301 — связано с предыдущем, попытаться покрыть проверками безопасности всё оставшееся т.е. тот самый illegal behaviour.
https://github.com/ziglang/zig/issues/157 — возможность получить известный во время компиляции максимальный размер стэка для функции
https://github.com/ziglang/zig/issues/1639 — связано с предыдущем, попытка убрать stack overflow решением от предыдущего.
https://github.com/ziglang/zig/issues/7769 — закрепленные структуры (означает, что адрес к ней является его частью (в каком-то поле) и нельзя копировать эту структуру по значению).
Ну и из связанного — https://github.com/ziglang/zig/issues/6396, модель памяти Zig
> Их пора не перечислили, компилятор все равно в следующем коммите может поменять
> поведениеЗначит не production-ready и даже не вообще не ready. А в эффективность отслеживания в дебаге лично я вообще не верю. Чтобы отслеживать в дебаге, программу надо скомпилировать, а как её скомпилировать если в ней UB? И зная как тяжело и трудно разрабы Rust борятся в этом плане с LLVM я не понимаю как можно вот так вот просто взять и убрать UB.
> В теории UB будет доведено до минимцма по типу „integer overflow for
> both signed and unsigned types is undefined”Ну то-есть скоростных алгоритмов на ЭТОМ мы не увидим. Потому что например то же крипто на си штатно уповает на wraparound uint'ов заданного размера. Что экономит операции проца там где хардвар это обеспечивает сам "размером регистра" допустим.
Ну почему? Если нужен wraparound, просто использовать +%, -% и т.д., +%= и т.д. В std.crypto (основной разраб Frank Denis) с производительностью довольно неплохо https://github.com/ziglang/zig/blob/0.11.0/lib/std/crypto/ff...
> Ну почему? Если нужен wraparound, просто использовать +%, -% и т.д., +%= и т.д.А, т.е. это настраиваемо? Но вообще по дефолту UB его назвать - херь полная. Это хуже чем даже сишка по UB. UB - нежелательный элемент, потому что о нем помнить надо. И можно прострелить пятку. В сях например достаточно помнить о wrap по мудулю 2^N, это делает оценку математики и ее валидности достаточно простой.
> В std.crypto (основной разраб Frank Denis) с производительностью довольно
> неплохо https://github.com/ziglang/zig/blob/0.11.0/lib/std/crypto/ff...Они додумались еще и крипто в стдлиб засунуть? При том кодит поди еще и не криптограф, чтобы совсем збс? Или я что-то не понял? Почему это в стдлибе вообще должно быть?
Если бы ты хотел это узнать, то увидел бы на главной в документации
Релиз жирнющий, поэтому расписано только самое заманчивое, а то новость слишком длинной получалась :)
Автор новости в том числе и контрибьютер в репозиторий Zig. Так что задавайте вопросы))))
Да какой я там контрибьютор) Так, Васян
Да кто там смотреть будет коммиты, Васян ты или нет))) Зато какая строчка в резюме.Осталось подождать когда язык выстрелит)
Кстати, раз контрибьютер, не знаешь почему zig требует включения всех архитектур для LLVM? Это явно политическое решение («оно вам не надо, не устраивает — используйте бинарные билды»), но где конкретно это аргументированно разжёвывается (почему нельзя было сделать нормальную сборку под то и только то, что включено) сходу нагуглить не удалось. Буду признателен за ссылки на конкретные issue либо посты в бложике.И таки да, в последнем релизе все хвосты вынесены в codegen/llvm а сам язык максимально отвязан от кишков шланга. Но по-прежнему в сборочном скрипте проверяет наличие всех архитектур и отваливается с ошибкой.
Конкретных записок в блогах нет, но сообщения в IRC и Discord были в духе „кросс-компиляция наша фишка, не хотим, шобы её система ломала”. Ну и из связанного:
> In Zig, we push back on the system a bit and give more control to the project. This is to gain insulation from the differences in systems and make building software reliable on all platforms, including cross compilation.
Впринципе многие дистрибутивы и так полную версию собирают, различие в времени сборки и размере не такое и большое, но зато всякие Крабы и Молнии работают нормально. На Gentoo к примеру:
> Michał Górny <mgorny@gentoo.org> (2021-11-04)
> Enable all LLVM targets unconditionally. Unfortunately, disabling
> targets tend to break reverse dependencies (e.g. Rust) and we are yet
> to find a clean way of resolving that. Compared to the damage
> potential, the increase of build time is a minor problem. Users who
> really insist of building a smaller system can un-force the flags
> at their own responsibility.
> See bug #767700.https://github.com/gentoo/gentoo/blob/05a1ed21cc44210a70b488...
Ну а вообще чисто технически ничего не мешает их разделить, учитывая, что уже давно есть опции для врубания/отрубания экспериментальных платформ для LLVM (-Dllvm-has-xtensa и прочие), вопрос чисто в политике (ну и то, что остальные бэкенды хорошо продвигаются, так что на некоторых платформах в как минимум отладочном режиме сборки LLVM не понадобится)
С критики остаётся разве что то, что нет пока версии 1.0, а ведь там даже LLVM собираются заменить. Из этого следует, что если хочется писать что-то крупное, то надо принимать участие в разработке языка собственно, хотя это в чём-то плюс ведь можно оказать влияние. А так сообщество распределенное, неагрессивное. Код очень читаемый и нет особых спецсимволов, с полпинка можно скачать и изучить. Вместо полного переписывания можно потихоньку переписывать внедряя в существующий проект на Си и упрощая его сборку. Идеи распространены интересные вроде data-oriented design. Нравится.
Всё верно. Основная большая претензия - нет нормального (быстрого) аллокатора памяти (основного, написанного на Zig, без линковки с libc).И async/suspend и вот это вот всё.
> нет нормального (быстрого) аллокатора памяти (основного, написанного на Zig, без линковки с libc).Вскоре может появиться, и уже используется в [[https://github.com/zigtools/zls ZLS]]: https://github.com/ziglang/zig/pull/16402
> И async/suspend и вот это вот всё.
Ну тут да, понаделали делов...
Лучше чем ничего. Но я жду топовый аллокатор, который там понаобещали, скинув кучу ссылок на текущий state of the art.И типа там требования - чтобы он был самым быстрым среди всех известных. Многопоточный и тп.
Но пока и BinnedAllocator буду рад.
Так в Си тоже нет такого аллокатора. :) В соседних темах критикуют реализации и из musl, и из glibc.
Тоже верно))) Но к Zig, в перспективе, у меня требования повыше))
На расте можно делать какие-то лохотроны на блокчейне и получать за это деньги, а здесь как с работой?
Кому и зачем это нужно?
Системщикам нужно в основном, игроделам вполне может зайти.
Лучше уж Golang, чем этот Zig. Он многое скопировал именно с Golang!
Гошка курируется гуглом и он шпионит. Вполне себе резон отказаться от зонда, если найдется вменяемая альтернатива.
Я Zig не пробовал, но хуже голанга наверное ничего не может быть. Непродуманный, жирный, требующий кучу бойлерплейт-кода. Ну и плюс -- карманная поделка гугла. Надоест гуглу гошка, и пойдут все гошники на мороз.
> Я Zig не пробовал, но хуже голанга наверное ничего не может быть. Непродуманный, жирный, требующий кучу бойлерплейт-кода. Ну и плюс -- карманная поделка гугла. Надоест гуглу гошка, и пойдут все гошники на мороз.А что лучше всех?
Провокационный вопрос! Но ответа не будет. Потому что для разных программистов и разных задач будут разные лучшие языки.
Зачем это если уже есть rust?
Зачем нужен Rust, если уже есть C, C++, Java, С#?
авто-ошибки, которые через ! делаются, имеют 16битный енум. Это значит, что вы не можете вернуть более чем 65535 разных ошибок в одной кодовой базе. Почему-то никто не осознает насколько это проблематично, а ведь в zig нельзя эти волшебные ошибки покомпилировать в разные библиотеки и решить проблему масштабирования.
Для решения предлагается ПРИНЯТЫЙ proposal 2018 года https://github.com/ziglang/zig/issues/786
Пропосалу пять лет, компилятор переписали на самом себе с отвязкой от С++, и проблему эту перенесли. Я лично ныл у них в дискорде об этой проблеме. Всем плевать, "сначала покажите мне проект на zig, в котором будет 65к обработок ошибок". Я думаю уже не поменяют.
А что 65k ошибок это же архитектурная проблема, раздели проект на части и там ошибки будут нумероваться с нуля.
Почему? Сколько, как ты думаешь, различных ошибок ты получаешь, при простой попытке подключиться к серверам гугла? И это тупо коннект.
К гуглу не знаю, обычно десяток ошибок хватает и то если фронтендер очень хочет их зачем-то перехватывать.
Ну так покажите)) Я уверен, шо даже в проекте с миллионом try/catch/errdefer строк бОльшая часть ошибок будет какой-нить NoSpaceLeft и OutOfMemory, у которых и так уберутся дубликаты, выставив единое число. Вместо всяких Field1NotFound, Field2NotFount т.д. и так рекомендуется использовать просто NotFound и обрабатывать в соответствующем месте. Я никак не могу придумать usecase, где могут понадобиться 65к разных ошибок с разными именами И где это всё ещё можно сопровождать без ночных кошмаров :) (по такому же принципу размер .zig файла 32 бит = 4 ГБ максимум, проблемы сопровождаемости начнутся задолго до)upd: про JVM ересь написал, извините...
Какой-нибудь парсер легко может выдавать порядка 1000 разных ошибок. 70 парсеров по 1000 ошибок и приехали.
Ахахаха))) А ты забавный)Ну, когда появится такой с 70 парсерами а программе по 1000 ошибок...ито не клоун какой-нибудь, то кейс будет валидным - Я уверен это поправят.
Думаю такой рукожоп найдётся не раньше чем через лет 20.
А там и пары миллионов ошибок может не хватить)))
> вы не можете вернуть более чем 65535 разных ошибок в одной кодовой базе.попробуйте писать БЕЗ ошибок.
А как у него с безопасной работой с памятью?
Всё топово, просто владелец опеннет не форсит этот язык как безопасный. Поэтому не всем понятно что в зиге есть всё то же что форсят в другом языке.
А можно больше подробностей?
Вот именно, очень интересно по сравнению с растом. Какие есть фишки, каких нет и почему, и т. п.
Всё, нашёл: https://ziglang.org/ru/learn/why_zig_rust_d_cpp/
Тыкал в него - очень хорошее впечатление оставил. Не знаю чего там со скоростью и т.п., но на порядок удобнее сей, а читаемость кода ясная и понятная в отличии от одного распиаренного "безопастного" языка. Аффтарам удачи.
Угадайте по коду, где тут синтаксис Rust, а где Zig:
for a in 0..20 {
...
}
for (0..20) |a| {
...
}
На главной странице написано ещё про ясность языка, поэтому могу предположить, что Зиг относится ко второму (на Руби похоже, это тоже capture значения?)
Ну и уж если критиковать язык, то не за синтаксис (каждому своё), а тогда за https://github.com/ziglang/zig/issues/1530. Зачем в НИЗКОУРОВНЕВОМ языке числа размером 0 бит? Зачем вообще да типа void? Я понимаю, если бы это был Хаскель какой-нибудь, но мы про "убийцу Си" говорим.> This is going to be zig's billion dollar mistake. I thought that we were going to make a language to replace C. Instead of bikeshedding with me, we could have removed a wart on the language. I am truly saddened by this action of closing the thread.
> References to 0-bytes has always been dangerous in computer programming.
*два типа void
https://github.com/ziglang/zig/issues/1530#issuecomment-4227...> Many of you are doubting whether u0 is a valid type, and theoretically, it is valid. From a type theory's perspective, u0 is the "unit type", which is always constructible, but carries no information. void, empty tuple, empty struct, enum with a single element are all the same. u0, u1, u2, ... are closely related by "product of types": u1 = u0 * onebit, u2 = u1 * onebit, ...
> For a high-level functional language like Haskell or Ocaml, not including u0 would probably be a mistake. But now the problem is, Zig is a low-level language, and cares about machine representations and such. u0 and u1, u2, ... differs in a fundamental way that u0 has no memory representation. Including u0 in Zig breaks the assumption that all integers have a memory representation, which in turn may break things if handled carelessly.
> .
Действительно, второй пример прям в духе синтаксиса Rust. Но это всего лишь один пример на грани черрипикинга.
> Действительно, второй пример прям в духе синтаксиса Rust. Но это всего лишь
> один пример на грани черрипикинга.Это только первое впечатление, если смотреть на код и не разбираться, что в нём происходит. Синтаксис у Rust довольно минималистичен и лаконичен. Просто там, где он кажется перегруженным, там действительно используется сложная семантика. В случае простого for нет сложной семантики и очень странно, что в этом месте синтаксис Zig оказывается перегружен разными скобками.
> 1) ...
> 2) ...
> 3) ...
> 4) ...Я так понимаю, это только для самого компилятора, а прикладной софт на сабже компилится уже полученным компилятором в исходник напрямую?
Да, но C бэкэнд и там может использоваться
> в исходникТьфу, блин... "В бинарник" же.
Не стОит писать на опеннете каменты утром в субботу.
>Zig Object NotationJSON is Not Invented Here.
Причины отказа от JSON (TOML, CSV, YAML) указаны в оригинальном запросе на слияние (https://github.com/ziglang/zig/pull/14265) :
> unfortunate that trailing commas are not allowed, and comments are not allowed.
> json5 exists but a lot of tooling does not expect it. and what's the extension? .json5 or .json? either one is a bit problematic.
> what's javascript object notation doing in my zig codebase? I don't have any javascript objects to describe.
> numbers limited to 53 bits sometimes? there is some janky stuff with json.Выбор был сделан в пользу .ini формата (парсер и сейчас в std лежит), а уже затем заменили на ZON в https://github.com/ziglang/zig/pull/14523 — один парсер, поддержка zig fmt и прочих, по аналогии с build.zig не надо учить отдельное cmake-о-подобие...
Но ведь это чистой воды Nih
Те вы предлагаете включить в спецификацию языка ещё и спецификацию другого языка типа JSON? Гениально)))Это часть стандарта языка, как минимум нативно поддерживается импорт этих файлов в исходниках.
Как раз таки исправлены реальные недостатки JSON. Отсутствие trailing comma и комментариев это буквально первое, что бросается в глаза при его реальном использовании, и вопрос о них поднимался множество раз, но воз стоит и ныне там.
Он сделан на основе конструкции struct { ..., ... } языка. Те вместо того чтобы учить 100500 языков, учишь один.И также нативная поддержка в языке.
>Те вместо того чтобы использовать существующую библиотеку парсера-сериализатора для каждого языка, пишешь 100500 парсеров под 100500 языков.Ясно.
Берешь стандартную библиотеку парсера. И прокидываешь во все известные языки минимальными усилиями.И в JS, и в Python, да вообще практически везде можно вызвать ffi и дёрнуть нативную функцию.
Вот тут поляк свой язык замутил https://www.cnews.ru/news/top/2021-10-12_sozdan_universalnyj... с ещё большим количетвом других ЯП, в которые его транслируется.
Тут америкос свой язык накалякал https://odin-lang.org/ безопасТный как все любят.
вобще-то, британец. достаточно забавный, GingerBill.и odin "заточен" под программирование графики, data-oriented design, и всё такое.
и он, скорее соперник jai, который ориентирован на геймдев.
Ваша информация устарела, язык теперь называется fusion https://github.com/fusionlanguage/fut
Ничего не имею против самого языка, но инфраструктура, состав спонсоров оставляют желать лучшего. Всё перечисленное - большие риски для любого сколь-либо важного проекта.А так хотелось бы больше подробностей на тему, чем он лучше Плюсов (хотя по сравнению с ними любой, наверное, язык из этой же предметной области будет лучше), Rust (про синтаксис тут уже кто-то говорил, но меня чьи-то слабые когнитивные способности не интересуют, нужно больше деталей из возможностей языка), Golang.
На этой странице есть https://ziglang.org/ru/learn/why_zig_rust_d_cpp/
Страница кстати одна из немногих актуальных, остальные из этого раздела написаны ещё во времена Zig 0.8 и куча команд и прочее изменилось с тех пор.
А что не так у состава спонсоров? Недостаточно инклюзивный? Уже самое их наличие отличает Zig от 99% процента аналогичных проектов в лучшую сторону.
> метапрограммированияДальше не читал. Не нужно. Усложнение ради усложнения.
Дернул ./build x86_64-linux-gnu baseline на 37-й Федоре -- получил 134 ошибки вида "error: ld.lld: undefined symbol"... Не впечатляет.
так zig-bootstrap нужен для кросс-компиляции, может вы с https://github.com/ziglang/zig/wiki/Building-Zig-From-Source перепутали? и https://github.com/ziglang/zig/wiki/Troubleshooting-Build-Is...
Читаю https://github.com/ziglang/zig-bootstrap, вижу: "The purpose of this project is to start with minimum system dependencies and end with a fully operational Zig compiler for any target."
В трублшутинке сверху как раз есть разделы для всяких undefined reference'ов, да и грех это LLVM не с пакетного менеджера ставить, когда он там есть (тем более в хорошо сопровождаемой Fedora, это ж не kisslinux какой-нить)
Как можно видеть, я не одинок: https://github.com/ziglang/zig-bootstrap/issues/156
Во-первых, зачем его собирать? Есть ночные версии которые прекрасно работают на Fedora .Ставишь в .local/bin и погнали.
Во-вторых, я совсем недавно собирал в Fedora из сорцов. Всё прекрасно работает и собирается.
https://github.com/ziglang/zig/wiki/Building-Zig-From-SourceВозможно zig-bootstrap и не работает. Но он и не гарантирует что обязан всегда работать.
Это скорее "nice to have".
Основная настоящая сборка языка - опция А по ссылке.
В Fedora нет llvm 16 для сборки языка. Поэтому из коробки он не соберёт.Но самое интересное - наличие свежей llvm (на Tumbleweed) не даёт гарантию сборки. LLVM то можно собрать кучей разных способов и упаковать.
И товарищи выпилили какие-то компоненты, lld что ли. Поэтому официально его нормально не собрать.
Отдельные лучи поноса за отсутствие возможности завести на ГитХабе ошибку в произвольной форме.
Джоны слишком много мусорили, да и вообще-то можно — кнопка Open a blank issue (если вы про ziglang/zig, в zig-bootstrap issues вообще шаблонов нет)
Да, это я напутал, прошу прощения.
Человек придрался к оформлению тикетов и сборке с помощью zig-bootstrap. Очевидно язык ему не нужен и не интересен))До языка товарищ так и не смог добраться,🙂
Он используется в Uber для его хорошей поддержки кросс-платформенной компиляции:
https://www.uber.com/en-IT/blog/bootstrapping-ubers-infrastr.../
Показательная ссылка: https://github.com/ziglang/zig-bootstrap/issues/152Краткое содержание: 25 мая очередной горемыка напоролся на тот факт, что бутстраппер Зига содержит примитивные ошибки, которые препятствуют сборке компилятора; спустя неделю (!), в течение которой никакой реакции от авторов языка не последовало, добавил комментарий "Hello guys, after a long time of hard work. I found a way to build zig successfully." и привел обходной способ решения проблемы; на 6 августа (прошло почти полтора месяца) авторы языка в теме так и не отметились. :-D
Аналогичные тикеты об ошибках нативной сборки на актуальных версиях мэйнстримовых дистров (например, Федора 37/38) авторы языка также обходят стороной. Думаю, что можно сделать обоснованный вывод: это поделие не то что в прод, на локалхост не стоит пытаться тащить.
P.S.
О "примитивности" ошибок сужу как разработчик/билд-инженер с 28-летним стажем официальной работы в профессии.
Стаж, похоже, в должности менеджера по клинингу с эпизодическими повышениями до тестировщика.> env: centos 8
> clang 14
> …
> … I try to force all to use libstdc++ ( I know it is not recommended)…В readme _явно прописано_, что необходимы LLVM/CLANG 16.
И какой же был обходной способ решения проблемы? Правильно, взять докер с совершенно другой (!!!) средой (ubuntu 23.04) и в нём собрать. «У меня ничего не работало, но я пошёл к Васяну, у него всё работает.»
А какая реакция должна быть на столь безобразно оформленный багрепорт? «Извините, но вы по–английски читать не умеете.» Впрочем, горемыка похоже студент–китаец, ему простительно.
Да, нынешняя система сборки совсем сырая, не все ошибки явно обрабатываются. Но тем не менее, будучи совершенно незнакомым с языком, компилятор я собрал. Да, пришлось читать сырцы и cmake–скрипт. Ничего, не переломился.
Какой ты "билд инженер" с 28 летним стажем, который не смог осилить простейшую сборку?1. Zig bootstrap это не официальная сборка, даже не в основном репозитории. Это ДОПОЛНИТЕЛЬНАЯ возможность сборки ещё одним способом.
2. Этот способ может не всегда работать, о чём сказано в документации.
3. Он и не может всегда работать, он не собирает всё из сорцов. Те этот упрощённый метод имеет ограничения.https://github.com/ziglang/zig/wiki/Building-Zig-From-Source
Собираешь clang из сорцов (в Fedora версия llvm протухшая) и далее по инструкции по ссылке. Всё собирается, всё работает.
Я думаю "билд-инженер" с 28 летним стажем в состоянии осилить 2-3 команды сборки?
В чем-то билд инженер прав - production ready это не только когда конпеляется. Важно, чтобы был саппорт, который отвечает в разумные сроки. Ну или хотя бы поддерживает.
Позвольте полюбопытствовать, саппорт, который будет отвечает в разумные сроки, разгребает ваш г...код, фиксит ваши специфичные баги?И всё это бесплатно? Те бесплатные рабочие руки топовых инженеров?
А так саппорт есть. В финансовой отчёте есть 25к баксов которые заплатил Uber за тот самый саппорт.
> Те бесплатные рабочие руки топовых инженеров? А так саппорт есть. В финансовой отчёте есть 25к баксов которые заплатил Uber за тот самый саппорт.К вам нет претензий. Вопрос был про production ready. Игнор это худшее, что можно делать в таком случае. Как там: не можешь помочь, так хотя бы рассмеши.
> К вам нет претензий. Вопрос был про production ready. Игнор это худшее,
> что можно делать в таком случае. Как там: не можешь помочь,
> так хотя бы рассмеши.Разработчики сабжа не клоуны чтобы забесплатно развлекать кого-то кто 2 предложений на инглише связать не может. А их время лучше потратить на кодинг и фиксинг САБЖ-а.
Отличные авторы языка, которые не могут осилить хотя-бы configure.
Изначальный автор поста просто нашел способ достать собственные руки из по пы и сделать всё сам. Зачем таким отвечать? Или что им ответить достань руки из по пы?
он их наоборот туда засунул, исходя из убунчи в докири
>как разработчик/билд-инженер с 28-летним стажем официальной работы вАльтлинуксе. Не забывайте называть это почётное имя, носите его с честью.
>> как разработчик/билд-инженер с 28-летним стажем официальной работы в
> Альтлинуксе. Не забывайте называть это почётное имя, носите его с честью.Такой же билдинженер с 28 летним стажем как Шигорин "старший программист" видимо. С таким бэджом и апломбом от вас ожидается как минимум прислать патч в апстрим с фиксом проблемы. Странно что вы за 28 лет еще не догадались об этом.
А можно название нормальным сделать?
А что не так? Название короткое и узнаваемое, что еще надо?
Надо попробовать переписать на него свои питоно-скрипты. Отпишусь в следующей новости о результатах.
Как всё прошло?
А никак! Решил так же как и ты переписать event loop на ассемблере!