LINUX.ORG.RU

Почему Ziglang не популярен на ЛОРе?

 ,


0

7

Вроде вкусный язычек для перекладывания байтиков, хорошая замена Сишке со многими плюшками:

  • Manual memory management. Memory allocation failure is handled correctly. Edge cases matter!
  • Zig competes with C instead of depending on it. The Zig Standard Library does not depend on libc.
  • Small, simple language. Focus on debugging your application rather than debugging your knowledge of your programming language.
  • A fresh take on error handling that resembles what well-written C error handling looks like, minus the boilerplate and verbosity.
  • Debug mode optimizes for fast compilation time and crashing with a stack trace when undefined behavior would happen.
  • Concurrency via coroutines. Async/await is thread-safe, non-blocking, and makes no syscalls, and therefore available in freestanding mode. You can multiplex coroutines onto a thread pool in userland for M:N concurrency.
  • ReleaseFast mode produces heavily optimized code. What other projects call «Link Time Optimization» Zig does automatically.
  • ReleaseSafe mode produces optimized code but keeps safety checks enabled. Disable safety checks in the bottlenecks of your code.
  • Generic data structures and functions.
  • Compile-time reflection and compile-time code execution. No preprocessor.
  • Import .h files and directly use C types, variables, and functions.
  • Export functions, variables, and types for C code to depend on. Automatically generate .h files.
  • Nullable type instead of null pointers.
  • Order independent top level declarations.
  • Friendly toward package maintainers. Reproducible build, 3-step bootstrapping process.
  • Cross-compiling is a first-class use case.

Пожалуй, возьму его, если что-нибудь нужно будет сделать на низком уровне.

https://ziglang.org/

https://github.com/ziglang/zig



Последнее исправление: mimimimi (всего исправлений: 1)

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

Разработка бэкендов (думаю про Идрис), игор, крипты и прочего, где можно заменить Си и плюсы.

Т.е. в разработке для localhost-а.

Ну и если D по сравнению с Zig протух, то с адекватностью вашего мировосприятия все понятно. Вопросов больше не имею.

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

И это не мешает ему двигаться семимильными шагами.

да там все серьёзно...

2018-06-07 - I Quit My Cushy Job at OkCupid to Live on Donations to Zig

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

Т.е. в разработке для localhost-а.

Окэй. Сегодня для локалхоста, завтра... посмотрим

Вопросов больше не имею.

Ничего страшного нет в том, что наши мнения не совпадают.

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

А у меня на гитхабе только всякое говно, например курсач на bash, который просил какой-то чел на ЛОРе ему срочно сделать в середине ночи, а я был пьяный и добрый и сделал ему. Основные проекты у меня на bitbucket, либо закрытые.

DELIRIUM ☆☆☆☆☆
()
Ответ на: комментарий от eao197

На Hacker News недавно было большое обсуждение.

Это? https://news.ycombinator.com/item?id=17184407

«Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust»

Вообще выглядит любительской поделкой.

tailgunner ★★★★★
()

Выглядит как немного дополненный Monkey, вывернутый в llvm

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

уже не буду тестить :-(

штука прикольная, но неудобно устроена. Просто взяты сорцы Tcl 8.6.1 и пропатчен парсер.

Если бы было отдельное приложение или библиотека, то была-бы нужная вещь

MKuznetsov ★★★★★
()
Ответ на: комментарий от MyTrooName
	freestanding	linux	macosx	windows	other
i386	OK	planned	OK	planned	planned
x86_64	OK	OK	OK	OK	planned
arm	OK	planned	planned	N/A	planned
aarch64	OK	planned	N/A	planned	planned
bpf	OK	planned	N/A	N/A	planned
hexagon	OK	planned	N/A	N/A	planned
mips	OK	planned	N/A	N/A	planned
powerpc	OK	planned	N/A	N/A	planned
r600	OK	planned	N/A	N/A	planned
amdgcn	OK	planned	N/A	N/A	planned
sparc	OK	planned	N/A	N/A	planned
s390x	OK	planned	N/A	N/A	planned
thumb	OK	planned	N/A	N/A	planned
spir	OK	planned	N/A	N/A	planned
lanai	OK	planned	N/A	N/A	planned

ну

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

Go

Убог

В целом - нет. Может, в каких-то конкретных деталях и проще чем нужно.

или D

протух

В целом - нет. Например, написанный на D код может посоревноваться в производительности с OpenBLAS. Код на D можно запустить и на микроконтроллере ARM Cortex M. Есть даже кроссплатформенный нативный (написанный на D и не использующий GTK/Qt/...) UI-тулкит dlangui, чем, к сожалению, не могут похвастаться ни Go, ни Rust.

или Ada (если GC проблема).

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

Результат сборки gnat из состава коллекции компиляторов gcc можно использовать так же как и результаты сборки gcc/g++/gfortran/... Т.е. по своему желанию без коммерческих лицензий.

Динозавр? По такой логике скоро перестанут пользоваться ядром Linux только потому, что стукнет энное кол-во лет.

gag ★★★★★
()

А он в TempleOS работать будет?

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

Но ведь «чем оно лучше раста?» - нынче вполне естественный вопрос для любого языка без сборки мусора и VM

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

А Zig кидает исключения или что-то другое?

Почти исключения. В виде возвращаемого значения. Если надо бросить исключение дальше вверх, есть слово try.

const number = try parseU64(str, 10);

Если нет, можно просто сохранить ошибку в переменную.

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

Но ведь «чем оно лучше раста?» - нынче вполне естественный вопрос для любого языка без сборки мусора и VM

В стартовом посте перечислена куча фич (той или иной степени годности) - выдели те, которые в данный момент отсутствуют в расте, или реализуются нетривиально. Будет видно - нужен зиг или нет ;)

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

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

Тогда, да, это можно использовать и это крайне интересно. А в том виде что сейчас есть - это просто ещё одна версия tcl в системе, причём не совместимая с основной. Взаимные вызовы невозможны.

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

Ммм, а тормозить-то оно как будет? Парсер на чём писать? Или ты хочешь сказать, парсер написать на С, просто прилинковать к libtcl?

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

ты меня разочароваешь, прямо вообще..

парсер и так написан на ansi С (из зависимостей pcre), и порождает байт-код вирт.машины tcl, но авторы железобетонно его впаяли в конкретную версию.

для просто preview технологии, это классно!

Но дальше никак..например моим юзерам удобно было-бы писать на нём (он более-менее близок к С) но сие не реализуемо ну никак. Я из проекта не могу вызвать их функцию невзирая на то что вирт.машины одинаковы и используют один и тот-же TAL

MKuznetsov ★★★★★
()

Чем оно лучше божественного c#?

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

Не знаю, чем мог разочаровать, я вроде никогда не претендовал на эксперта по всему :) Как устроен tcl внутри, я представляю очень и очень смутно. То, что ты сейчас написал, тоже нифига не понял. Просто хотел уточнить, как правильно, на случай, если вдруг взбредёт в голову делать язык на базе tcl.

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

То, что ты сейчас написал, тоже нифига не понял. Просто хотел уточнить, как правильно, на случай, если вдруг взбредёт в голову делать язык на базе tcl.

вот смотри как сейчас сделан litle-lang: взяты полностью исходники tcl (кстати и tk тоже) и прямо там внутри впатчен парсер и генерация бай-кода (у tcl внутри есть свой ассемблер и байткод), а исполнение проводит машина tcl.

как должно было-бы быть: он должен быть отдельным проектом, иметь в build зависимостях сорцы tcl, нужные ему от tcl функции получать от libtcl.so. Экспортировать пару команд «compile» «eval».

Тогда его можно вызвать из штатного tclsh и будет щастье - на чём удобно на том пиши.

что получилось в результате: просто появился «ещё один» интерпретатор. В отличии от tcl он уже не embedded, его нельзя никуда встроить и он имеет потенциальный конфликт с штатным tclsh за stub и библиотеки.

в качестве «tehnology preview» - хорошая штука, симпатичный язык

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

вот смотри как сейчас сделан litle-lang

Это я ещё с первого раза понял, и почему не нравится, тоже ясно. Но тут вопрос в том, парсер заменён или добавлен второй. Судя по Судя по тому, что «Little can call Tcl, Tcl can call Little», добавлен второй. Т.е. тебя напрягает то, что он прибит гвоздями к одной версии, и эта версия, вообще говоря, не та, которая тебе нужна? Но ведь можно тянуть этот форк, и применять патч к каждой следующей версии tcl/tk. Останется только проблема того, что он будет конфликтовать с существующим, но тогда его можно просто переименовать.

иметь в build зависимостях сорцы tcl, нужные ему от tcl функции получать от libtcl.so.

Это возможно только в случае, если tcl экспортирует достаточно для того, чтобы это реализовать. Это во-первых. Когда я делал Яр, я сделал достаточно много форков. Потому что даже в лиспе с его «всё паблик», декораторами и горячим переопределением далеко не всегда возможно держать в стороне нужный тебе патч. Иногда патчить исходники - это, по сути, единственная возможность получить решение, принципиально отличающееся от форка. А уж в Си возможностей для этого на порядок меньше. Поэтому вместо того, чтобы кодить, они боролись бы с запретами, и не факт, что победили бы. Это я говорю абстрактно, не глядя в код tcl/tk, может быть там всё шоколадно. Но я просто из опыта подобного проекта могу предположить, что им нужна была вся инфраструктура интерпретатора tcl/tk, в т.ч. private части.

Но в целом, конечно, то, как ты хочешь, было бы лучше для пользователей.

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

у Odin из документации только видосы что ли?

anonymous
()

Разговор про язык программирования должен начинаться с разговора про систему типов (про которые афтар ничего не слышал, очевидно). А всё, что начинается со слов типа «простой», «быстрый», «легкий», «интуитивный» и прочей чепухи для даунов и домохозяек, есть мусор, который станет очередным пхп или питоном (и будет отравлять жизнь приличным людям), если вдруг наберет популярность.

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

Смотри на то, что уже реализовано.

А что на нём уже реализовано из более-менее известных проектов?

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