Кто тут ржавчиной интересовался?

Для всех любителей Rust'а, комментарии которых так и остались в очереди на премод — встречаем долгожданную (анонсированную ещё в интервью на ютЪюбике) статью Алексея Вересова: http://rustmustdie.com

Спасибо за

Спасибо за критическую статью! Теперь нужна версия на английском, чтобы отправить в IRC.

По поводу спора с compile-time и run-time: не защищаю раст, но у gcc есть библиотека libgcc, откуда компилятор может вставлять код в итоговую программу. Gcc предполагает, что эта библиотека доступна всегда, даже если собрать программу с ключами вроде -nostdlib (wiki.osdev.org/Libgcc). Не значит ли это, что в Си нет zero runtime?

По поводу токсичного сообщества: фанатики есть не только у раста, но и у многих других проектов. Я тут, например, могу фанатично позащищать один проект. Так что это не проблема раста, это вопрос к интернету.

admin аватар

Язык Си (именно

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

Рантайм

А вот тут кстати грань между рантаймом и компиляцией довольно тонкая. Например, если в ответ на конкретную конструкцию кода, компилятор вставляет конкретный машинный код, то можно считать набор таких кодов стандартной библиотекой, "функции" из которой инлайнятся. А можно и не считать.

С другой стороны можно взять критерием рантайма случай когда в исполнимый файл добавляются функции, которые не были описаны в исходники, и если есть call/ret — то это рантайм, а если инлайн — просто нормальная компиляция.

admin аватар

Я бы предложил

Я бы предложил другой критерий: язык должен содержать только такие конструкции, машинная реализация которых очевидна и тривиальна. Если потребовались подпрограммы, то тут уже ни о какой "тривиальной реализации" речи не идёт заведомо. Но есть и такие особенности языка, которые убивают zero runtime (если и не формально, то по факту) без всяких подпрограмм. Например, VLA из C99.

VLA

Не знал, что такая штука есть, думал что для динамических массивов надо вызывать malloc или calloc или подобную фиговину. Когда мне нужно было решето Эратосфена на C, так и делал.

Я так понимаю, что для создания VLA достаточно просто к стеку прибавить длину массива и затем спокойно размещать этот массив в текущем стековом фрейме? Хотя я только сейчас прочитал про них и могу чего-то не знать.

> машинная реализация которых очевидна и тривиальна.

Субъективно. Вам не тривиально, а разработчикам какого-то конкретного компилятора кажется что то же самое вполне тривиально. Такое разве не может быть?

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

Так как GRUB, GRUB2 и U-boot написаны на C (кроме первого сектора, который на асме) и успешно компилируются gcc, можно сказать, что нужное свойство у него таки есть. Хотя надо ещё посмотреть, нет ли там тонны других вставок, кроме первого сектора.

А вот на free pascal можно написать аналог grub2 или u-boot, пусть даже гораздо более простой, как proof of concept? Кстати учитывая наличие поддержки вставок на ассемблере, по идее может даже можно попытаться и первый сектор тоже написать в рамках *.pas файлов без подключения nasm или другого дополнительного ассемблера.

admin аватар

Не знал, что

Не знал, что такая штука есть,

"Такой штуки" нет. Использовать VLA нельзя никогда, ни для чего, ни при каких условиях, за это надо подвергать публичному осмеянию и гнать с работы погаными тряпками. Что касается C99 в целом — то это комитетский бастард, не имеющий никакого отношения к языку Си. Подробности см. в томе 2, гл. 4.1 и потом параграф 4.3.15.

> Субъективно.

Нет. Между словами "просто" и "тривиально" — смысловая пропасть.

> А вот на free pascal можно написать аналог grub2 или u-boot,

В принципе можно, хотя и не столь прямолинейно, как на Си.

C 2011

> Использовать VLA нельзя никогда

Кстати в C11 вроде как сделали его опциональным. То есть, по ещё более новому стандарту использовать опять нельзя.

> В принципе можно, хотя и не столь прямолинейно, как на Си.

А стандартная библиотека этому никак не помешает? fpc вставляет полмегабайта, а то и больше своего кода в любой исполнимый файл.

Или под "не столь прямолинейно" имеется ввиду что надо патчить компилятор, чтобы не вставлял rtl?

admin аватар

Компилятор не

Компилятор не надо патчить. Я не помню конкретики, но объектники компилятор fpc делает совместимые с обычным линкером, можно свой заменитель RTL сделать. Правда, там довольно много возможностей языка реализовано через RTL, и надо более-менее понимать, что в программе можно использовать, а что нельзя.

Язык D

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

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

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

И вообще, насколько D хорош или плох для системного софта? Режим nostd там тоже включается ключом компилятора, как и в сишке, то есть zero runtime там как бы есть.

aversey аватар

А есть такой же

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

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

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

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

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

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

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

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

А что вы

А что вы думаете по поводу языка V? Он вроде как сделан из расчета избавиться от всех недостатков раста, на нем даже операционку уже написали.

"Язык V" - это

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

Некоторые

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

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

os.system("curl ...") в

os.system("curl ...") в котором делается подстановка строк в http библиотеке это жесть конечно. Это не просто плохо, это трындец, за который в серьезных компаниях сразу выставляют на мороз.

aversey аватар

Слышал про него

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

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

Классная

Классная статья, прочитал с интересом. К вопросу о токсичности сообщества, Go - тоже культ тот ещё. Все эти многочисленные "considered harmful", "I've never used it and have never missed it", авторы ЯП твитящие о том, что можно писать на Go, а что - грех. Писал на нём с первой релизной версии, рад что ушёл.

Я когда-то

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

в конце

в конце паскалевской части первого тома говорилось, что ЯП не поддерживают понятие владельца структуры данных, а в rust'ишке это оказалось. насколько же это неинтуитивный язык!

admin аватар

Я бы сказал, что

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

Бред это всё.

Про статью и на rsdn еще есть

https://rsdn.org/forum/flame.comp/8156428 как-то многие не впечатлились

Как не думай о языке плохо, он всё равно ещё хуже окажется ...

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

Автоматическое преобразование типов и реконструкция типов

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

У ЛОРовских

У ЛОРовских растоманов от этой статьи дико пригорело https://www.linux.org.ru/forum/talks/16694596/

С каждым новым

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

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

Интересная

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

Rust не очень, но по другим причинам

Если честно, статья крайне сырая. Автор путает понятия runtime и compile time; не осознаёт зависимость (времени компиляции!) от библиотеки (с каких пор библиотечные примитивы стали сборщиком мусора?); меняет местами причины и следствия (язык построен на основе аффинной системы типов, отсюда и borrow checker со всеми плясками и бубнами, а не наоборот); умалчивает о том, ради чего всё это сделано именно так (вот валидность причин уже гораздо более интересная тема); совершенно не учитывает наличие оптимизирующего компилятора в системе (машинный код для примера с фильтром массива строк выглядит несколько иначе[1]). В текущем виде наибольшая часть претензий выглядит совершенно необоснованной.

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

1. https://rust.godbolt.org/z/4ofEe8

Rust и его runtime

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

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

aversey аватар

Rust ужасен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rust не очень, но по другим причинам

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

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

Попробуйте

Попробуйте добавить -O к ключам компилятора rustc. Иначе заявленные числа ассемблерных строк являются совершенно нерепрезентативными.

А какую задачу мы решаем?

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

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

aversey аватар

Оптимизация

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

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

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

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

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

Спасибо за

Спасибо за статью. Я только начал читать и сломался на первом абзаце. Можете объяснить почему compiler-built-in == runtime?

aversey аватар

Спасибо!

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

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".