Comments 32
Это все замечательно, а можно хоть немного про язык, плюсы/минусы, сравнение, применимость?
Каждый раз, читая про какой-то новый язык, становится понятно, как скомпилировать приложение, но совершенно не понятно, для чего вообще он.
? Может какие то ответы есть в немногочисленных статьях в
Хабе по Zig на Habr
Вот все равно не понял. Не знаю, может я тупой, но есть 3 языка: Go, Rust, C/C++, теперь еще Zig, и мне не понятно главное: в чем разница-то?
Отличия между C/C++ и Rust хотя бы очевидны: оба достаточно низкоуровневые, но при этом возможностей отстрелить себе ногу в Rust в разы меньше. Отличия между этими двумя языками и Go - Go еще и интерпретируемый.
А Zig как-то в сторонке держится: мы можем транслировать код с С/С++ на Zig, а какие преимущества/недостатки в сравнении - все еще непонятно.
Отличия между этими двумя языками и Go - Go еще и интерпретируемый.
Go компилируемый, как и Rust с C/C++. Главное отличие Go - это сборка мусора, утиная типизация и его подход к многозадачности.
есть 3 языка: Go, Rust, C++
Все три языка (Go, Rust, C++, C здесь лишний пока) сильно друг от друга отличаются. Они преследуют разные цели. И их история разная. И Zig точно так же преследует свои цели, история его точно так же отличается. Если уточнять, то Go и Rust это два языка, которые в первоначальной идее разрабатывались для замены языка C++. Но у них абсолютный разный подход к решению этой задачи. И за годы их существования они выросли и разошлись в разные стороны. Сейчас оба этих языка больше чем были. Но в итоге они так и не стали заменой языка C++ (он живёт и здравствует), они стали его конкурентами. И сейчас мы видим конкуренцию. Rust при этом стал конкурировать с рядом других языком, с C в том числе.
У Zig же уникальная ситуация. Он может именно заменить язык C. Я этой статьёй это показал, что это возможно, и это просто. И при этом сам язык предоставляет дополнительные возможности, внедрение которых ничего не стоит, потому что они часть языка. Язык Zig во многом повторяет поведение языка C, что даёт возможность получить при переходе между языками аналогичное поведение кода после компиляции. Тут есть о чём ещё упомянуть, но я не смогу покрыть всё своими текущими знаниями
Давайте посчитаем вместе:
1. Go
2. Rust
3. C
4. C++
Это 4 языка.
Во вторых в расте столько же точек отстрела + свои ещё, в подробности лучше не вдаваться
Ну-ка, давайте вдаваться. А не то ваш комментарий как нонсенс выглядит
полного списка UB в расте вы нигде не найдёте, модель памяти раста не определена и примерная цитата из его "библии" "пока используется модель памяти С++, когда то потом изменим", в добавление к этому есть УБ связанные именно с растом, например если у вас существует 2 мутабельных ссылки на один объект, то это УБ в расте
...модель памяти раста не определена и примерная цитата из его "библии" "пока используется модель памяти С++...
Вот это одно из тех вещей, что в Rust мне непонятно. Особенно с учётом того, что Rust существует уже много лет, и метит на место языка C в межпрограммном «общении». Странно это. ABI до сих пор не устаканилось. Оно конечно не мешает писать программы, но осадочек остаётся
полного списка UB в расте вы нигде не найдёте...
А вот тут стоит сделать поправку. Списка UB в Rust и не может быть, так как UB подразумевает отсутствие описания поведения в стандарте, и реализация поведения ложится на плечи компилятора, а так как у Rust разработчики языка и компилятора это одна группа людей (то есть одна компания), то они просто не могут знать, что у них UB на самом деле. То есть не как в C или C++, где есть комитет по стандарту, который формирует стандарт и отдельные разработчики компиляторов (коих десятки), которые этот стандарт интерпретируют. И есть места, которые стандарт просто не может охватить, так как эти места по настоящему зависят от конкретной реализации. То есть в случае C и C++ список UB составить можно. Но то, что Rust имеет свои подводные камни, это факт
Причем тут модель памяти в Rust? Речь же про неопределенное поведение.
В Rust не может существовать две мутабельные ссылки на один объект, но могут быть два мутабельных указателя на один объект.
полного списка UB в расте вы нигде не найдёте
Дарю: https://doc.rust-lang.org/reference/behavior-considered-undefined.html
Если мы говорим про UB, то нужно делить Rust на safe и unsafe. UB в safe не существует. Список вещей, которые считаются UB предоставлен.
Во вторых в расте столько же точек отстрела + свои ещё
Как хорошо, что это неправда
Я так понимаю, на этом мы заканчиваем
Вопрос хороший, вот ответ на него уже будет не очень. Проблема здесь в самом вопросе. Эту статью я писал на определенную тему, так как задумал её ещё при написании предыдущей статьи, и старался придерживаться темы. Потому что мне самому понравился такой ход разработчиков языка - упростить взаимодействие с языком C. И в эпилоге я написал почему статья такая.
Отвечаю на сам вопрос. Так как язык Zig ещё разрабатывается, некоторые вещи в нём нестабильны из-за чего непонятно стоит ли указывать не полностью рабочие возможности языка как минус, или всё же это стоит указывать как плюс. Из-за этого же прямое сравнение с другими языками будет неполноценным. Вот про применимость можно написать, так как язык нацелен на замену языка C, то и применимость аналогичная
Если нацелен на замену, хорошо бы бенчмарки посмотреть, есть такие?
Моих личных нет. Есть сайт, но насколько можно ему доверять не знаю, пару раз встречал его в разных статьях
Вот тут Изучаем язык программирования Zig на русском можно почитать о языке от простого к сложному.
Интересно, что и много вариантов написания Форт (Forth) на Zig
Находится на Github :)
P.S. Правда не понятно чем он "лучше" для этого действия подходит, в сравнении с разными реализациями Форт на других высокоуровневых языках помимо ассемблера.
К, примеру, и на Rust есть несколько реализаций Форт.
Кстати, а Online компиляторы Zig какие наиболее актуальны учитывая "нестабильность" языка?
Спасибо. Забыл про rosettacode. У самого в закладках лежала, и забыл про неё
Я так и не понял, зачем мне переходить с C на что-то ещё (в этой нише).
там владелец чата странно себя ведёт
А...
Я так и не понял, зачем мне переходить с C на что-то ещё
Простите, что вопросом на вопрос отвечаю. А вы хотите перейти?
Неважно что хочу я. Важно что требуют задачи. Если появятся такие, для которых Zig окажется эффективней - почему бы и нет? Но пока их не вижу.
На самом деле очень важно, что именно вы хотите. Так как вы лично решаете перейти на новый язык или нет. Я могу ошибаться, но предполагаю, что вы не прогаммист на C, так как проблемы языка C очевидны и нельзя их не замечать
Пишу на C с 1992 года.
мир иначе устроен. Когда вы лопату меняете на экскаватор, то получаете кучу проблем: требуется обучение и права, солярка, ремонт, расходники и так далее.
Фундаментально Си "божественен" и неулучшаем. Потому что случилась цепочка событий: Multics -> Unix -> Posix
То есть у человечества есть единый стандарт на ось (Posix) и почти все операционки кроме Винды этому соответствует. И C89 там прибит гвоздями как язык ядра. Подавляющее большинство языков вначале транслируются на Си, то есть не являются самостоятельными.
Торвальдс начал процедуру миграции на С99, но что-то другое никому не надо. Достоинство Си в том что очень простой компилятор, который очень дешево портировать на любую железку. Ядро собирается без всяких зависимостей, без всех библиотек.
Второй важнейший язык это Си++ он также прибит гвоздями и устанавливается в самом начале построения дистрибутива. Мистер Степанов годами ходил за Стауструпом, пока не заставил прикрутить к языку шаблоны (STL). Си++ остается нижнем уровнем для прикладного кода.
Итого, пока существует эта парадигма POSIX то остаются эти два важнейших языка. Всё остальное является факультативными паразитическими сущностями. И так будет оставаться пока парадигма компьютера не сменится на некую биологическую или квантовую архитектуру.
Застоялось взглядов. Это мне знакомо.
Я отвечу так. Я понимаю о чём вы пишете. И понимаю, что в некоторых местах вы ошибаетесь. Проблема языка C не в том, что он не улучшаем, а в том, что комитет по стандартизации его не хочет улучшать. Я не утверждаю, что улучшений вообще нет. Нет тех улучшений, которые могут нивелировать недостатки накопленные за года. Здесь работает человеческий фактор. И понятно почему. Многое завязано на «стабильность» языка C. Для комитета это практически «бизнес». Для некоторых представителей комитета это и вправду бизнес. Программистам просто приходится мириться с тем, что сейчас представляет из себя язык C. А его есть куда улучшать. Даже упомянутый вами Товальдс говорил, что он готов принимать в ядро код написанный на других языках, если это будет «достойный» язык. Rust же он разрешил (с ограничениями). А Rust в сравнении с C куда более «сложный» язык.
Про остальное я не буду комментировать, там слишком холиварно может получиться
чтобы писать более компактный и выразительный код
https://gist.github.com/andrewrk/d285c8f912169329e5e28c3d0a63c1d8
del
Добрый день, скажите пожалуйста, можно ли изучать Zig вместо Си, чтобы разобраться в низкоуровневом программировании? Мне Zig больше нравится. Но по Си очень много материала.
Добрый день!
Если вас интересует именно системное программирование (как вид низкоуровневого программирования), то лучше начинать с языка C. Потому что подавляющее большинство системных библиотек, и основных блоков подавляющего большинства операционных систем написано на C. Изучение языка C необходимо для понимания того, как он работает внутри. Потому что работать с C-style API придётся часто, даже не смотря на то, что у вас есть желание изучать Zig, или Rust, или D, или Nim, или любой другой современный язык - «убийцу языка C». После C уже можно смело переходить на другие языки. И с другими языками у вас появится понимание того, почему язык C устарел, и почему ему нужна замена, которой выступает, в том числе, Zig. Но не стоит забывать, если вы читали статью, что язык Zig всё ещё развивается. Он всё ещё не дошёл до стабильной версии 1.0. Язык Zig пока ещё не рекомендуют использовать в критически важных продуктах. Потому что, изучая Zig, вы столкнётесь с частой необходимостью переписывать свой же код из-за изменений добавляемых в новых минорных версиях.
Лично я всё же рекомендую не сбрасывать Zig со счетов. Его киллер фитча - простая работа с существующим кодом написанным на языке C. О чём, собственно, эта статья. Это делается в разы проще, чем в любом другом современном языке - «убийце языка C». Рекомендую просто попробовать поработать с библиотеками написанными на языке C в Zig, Rust, Nim, D, или других языках программирования, и вы легко поймёте, что я имею в виду под «простотой»
Варим C с компилятором Zig и его build.zig