Андрей Викторович Столяров: сайт автора

Язык Си (именно язык, а не компилятор gcc, в команде которого прямо-таки сборная команда моральных уродов) допускает zero-runtime, чем и интересен (и больше вообще-то ничем). Конкретная реализация свойством zero-runtime не обладает.

А есть такой же обзор про язык D?

Наверное есть, интернет вам в помощь. =)

Мне интересно, он годится на замену C++?

Из того что я слышал для замены современного Си++ вполне сгодится, но это маловероятно так как на перетаскивание программистов и проектов с плюсов уйдёт необоснованно много сил.

И зачем нужен был Rust, когда D был раньше?

Раст всё же вносит много оригинальных идей. Плюс, развитие языков программирования не линейное -- был Алгол 60, зачем появился 68? Просто потому что накопились идеи, которые хотелось проверить -- вот и раст мне видится таким экспериментом, по-моему, к сожалению, неудачным.

И вообще, насколько D хорош или плох для системного софта?

Можете посмотреть ответ ниже про V, плюс добавлю что ответ зависит от того, что вы понимаете под системным софтом.

"Язык V" - это школоподелка от взрослого неуча. Лень смотреть как выглядит сейчас, но после открытия исходников это был испанский стыд: полное отсутствие возможности очистки памяти - ни вручную, ни с помощью сборщика мусора (память текла даже в hello world); функции библиотеки - просто обёртки над GNU утилами. Дизайна и идеи (если не считать идеей нескучный синтаксис) не было как класса. Откуда вокруг взялось столько хайпа на счёт этой 1-апрельской шутки - решительно непонятно. Боты, накрутка или идиоты?

Некоторые время назад читал обзор на V. На момент написания обзора язык очень сырой. Но проблема даже не в этом. В конце концов, нельзя (наверное) сразу сделать такой нетривиальный проект как язык программирования не наступив на какие-то грабли. Проблема в том, что достоинства языка, о которых говорит автор, оказываются обычной фантастикой.
Хотя, скорее всего, что-то успело измениться в лучшую сторону.

Ссылка на обзор:
https://christine.website/blog/v-vaporware-2019-06-23

Слышал про него, думаю что ждёт неудача. Мне в целом кажется концепция уберязыка без изъянов слишком сложной, что бы быть реализованной, особенно когда пытаются дать инструмент для работы с низким уровнем в виде высокоуровневого языка. На данный момент только ассемблер подходит для работы с низким уровнем (читайте: для контроля над железом), что не исключает возможность создания нового языка, который эту тему таки бы закрыл, но вызывает сомнения при появлении очередного "заменителя Си/ассемблера/..."

То что на чём-то написали операционку мало о чём говорит -- её можно написать как на Паскале или Форте, так и, при большем извращении, на Лиспе, Хаскеле или Питоне. Было бы желание.

Я когда-то хотел изучать Go. Поставил компилятор, скомпилировал hello world. посмотрел на файл, занимающий мегабайт. Передумал изучать Go.

Я бы сказал, что тут дело даже не в том, что он "неинтуитивный". Дело скорее в том, что компилятор раста сам решает, когда владение "должно" (с его, компилятора, точки зрения) перейти от одного игрока к другому. А решать это вообще-то должен программист, а не компилятор. Ну и начинается пляска вида "как заставить тупой компайлер сделать то, чего я хочу".

Бред это всё.

Не путайте тёплое с мягким: автоматическое преобразование типов есть в Си, но нет в Rust; автоматический вывод (также известный как реконструкция) типов есть в Rust, но нет в Си. То есть с точки зрения типизации в программе на языке Rust всё в порядке, но вот читать хоть сколько-нибудь сложный код, в котором отсутствуют явные указания типов -- боль и страдания.

С каждым новым написанным там комментарием, предположение об "особенном" сообществе раста становится все более похожим на факт. По крайней мере, я не так себе представлял самых счастливых и довольных жизнью разработчиков:) Автору хочу пожелать не воспринимать это близко к сердцу (хотя там в одном комментарии были упомянуты интересные минусы раста, которые могли бы дополнить статью), т.к. он затронул вторую по значимости святыню ЛОРа (первая systemd).

А самим агрессивным адептам раста должно быть обидно не от того что кто-то посмел критиковать язык будущего, а от того что на нём до сих пор не написано чего-то стоящего. Взять, например, тот же Go, как бы к нему не относиться. Вышел примерно в то же время, так же продвигается корпорацией, но количество проектов, используемых каждый день по всему миру многократно выше и сравнимо только с количеством призывов переписать очередной работающий проект на раст.

Автор путает понятия runtime и compile time; не осознаёт зависимость (времени компиляции!) от библиотеки

"Смешалисьвкучуконилюди". Ну и какое отношение имеет библиотечный рантайм к тому, что происходит во время компиляции (рантайм-костыли, обеспечивающие языковое возможности не в счёт)? Мне кажется, что вы не поняли одного из посылов статьи - раст не обладает свойством zero runtime по факту. Формально, конечно, обладает. Только никто из его адептов на практике не сможет его использовать таким образом, по причине недоступности так любимых растовиками фишичек, которые (внезапно) реализуются посредством библиотечного рантайма ) Вам аналогию с D не просто так привели ниже.

Автор путает понятия runtime и compile time

И где же я путаю компайлтайм и рантайм?

Не кажется ли вам, что вы не осознаёте что любая часть программы, которая навязывается языком для включения в итоговый машинный код -- является частью рантайма?

не осознаёт зависимость (времени компиляции!) от библиотеки

Вообще не понимаю что вы тут пишете. Не осознаю зависимость от библиотеки? Времени компиляции? О чём вы?..

с каких пор библиотечные примитивы стали сборщиком мусора?

С тех пор как они стали исполнять алгоритмы сборки мусора, не поверите. Как именно сборщик мусора включён в программу -- абсолютно не важно, важно что если он в ней по итогу есть, то он в ней есть. То что раст позволяет писать программы без сборщика мусора -- это конечно замечательно, но ровно в той же степени, в какой это позволяет делать D. Предупреждая линию мысли "но в D это часть языка, а тут лишь часть стандартной библиотеки" -- стандартная библиотека Rust неотделима от языка, как было показано в статье.

меняет местами причины и следствия (язык построен на основе аффинной системы типов, отсюда и borrow checker со всеми плясками и бубнами, а не наоборот)

Ну это вообще прекрасно. По вашему я написал, что из borrow checker-а со всеми плясками и бубнами вытекает построение языка на аффинной системе типов, тогда как я просто написал про непосредственно пляски с бубнами (как вы сами точно подметили!) -- и меня в принципе не волнует причина их возникновения. Благими намерениями вымощена дорога в ад, поэтому меня интересуют не идеалы и желания, а суровая реальность и результаты, про которые я и пишу в статье.

умалчивает о том, ради чего всё это сделано именно так (вот валидность причин уже гораздо более интересная тема)

Очень интересная для фанатиков Rust, которые предпочли бы вечно мечтать о том, какую идеальную модель программирования они имеют, вместо того чтобы, как было сказано в прошлом абзаце, не обращать внимания на причины и смотреть на результат. Я ведь на разрабатываю новый язык (тогда имело бы смысл думать о высоком, пытаться выработать принципы построения языка, и тому подобное), я анализирую существующий язык с точки зрения его самого по себе, в вакууме, если хотите -- так почему же меня должны волновать намеренья его создателей?

совершенно не учитывает наличие оптимизирующего компилятора в системе (машинный код для примера с фильтром массива строк выглядит несколько иначе)

И не собираюсь учитывать -- как не учитывал для примера на языке Си. Разбирать оптимизированный код почти невозможно, ровно как и предсказывать, как себя поведут оптимизации. Неоптимизированный код лучше отражает саму идею компиляции, а именно её я хотел показать для тех, кому станет интересно, как же Rust представляет замыкания, кроме того он лучше подходит для сравнения, всё по той же причине большей прозрачности. Если вам кажется нормальным не профессионалу разбирать оптимизированный машинный код -- вы или гений, или идиот.

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

Короче, не кажется ли вам, что это ваш ответ крайне сырой и несерьёзный? Вы назвали меня идиотом (путаю рантайм и компайлтайм, не осознаю что-то там только вам известное) и выставили подлецом и лжецом (я, видете ли, меняю местами причины и следствия, умалчиваю о чём-то важном -- в общем, намерено врежу своим читателям!) -- зачем?

И да, данная вами ссылка битая.

В оригинальном сообщении сылка битая (видимо, что-то пошло не так при редактировании), корректная ссылка с JS[1] и копия на pastebin[2] (без JS):

1. https://rust.godbolt.org/z/4ofEe8Yxn
2. https://pastebin.com/raw/rfCHwmyL

Сравнивать оптимизированные коды по производительности - да, разумно. Но, как уже ответил автор, при этом сравнивается много всего, включая, собственно оптимизаторы.
Вот только на таких маленьких примерах, в которые ничего не выдают/не возвращают наружу, суровый оптимизатор просто выкинет весь код. Ну да - количество строк будет одинаковым и равно нулю. А если не выкинет, то это ещё хуже для Rust.

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

Мне кажется нерепрезентативен как раз оптимизированный код, но спасибо за предложение. Поясню почему оптимизированный код мне сравнивать кажется неверным решением:

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

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

Наконец -- можно и включить оптимизации, результат изменится не принципиально -- код будет всё так же больше и всё так же медленней в случае Раста, особенно в случае Раста "эталонного".

Спасибо за комментарий!

Исправил это предложение -- имелось ввиду, что макросы, которыми якобы можно перенести любое вычисление в компайлтайм -- на деле настолько неудобны, что даже сами компиляторщики их не используют. В итоге это всё у меня скомпоновалось в сказки о нулевом рантайме. =)