Разработчики systemd рассматривают возможность внедрения Rust

Можно сказать «мне не нравится, когда мой код завален бесполезными вспомогательными конструкциями».

Но они не бесполезные. (:

Опять же: код «завален» конструкциями, которые ты считаешь бесполезными. Я считаю благом возможность видеть где может возникать ошибка.

Желающими сейчас припомнить Go сразу отвечу — при разработке Go допустили ошибки, и обработка ошибок — одна из них.

Не думаю, что с тобой все согласятся.

В соседнем треде я приводил аргумент, что на самом деле Perl/PHP/Python/Ruby/JS — это языки в которых тип «выводится» везде, но во время выполнения. И это чудовищно популярно, на текущий момент это намного популярнее всех языков с явным описанием прототипов.

А есть где-то статистика? По количеству кода или по количеству вакансий? Правда интересно.

Кажется, что такой спор я уже с кем-то вёл, может даже на лоре, может даже с тобой?.. По моим ощущениям, новых статически типизированных языков больше. JS пытаются типизировать (typescript), питону аннотации типов добавляют… но легко могу быть не объективен - никогда динамически типизированными языками не интересовался как следует.

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

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

И нет, я не считаю раст идеальным языком. Но если ты придёшь с предложением, например, добавить исключения, то буду против. Потому что мне другое нужно.

Всё?

Нет. Ещё insert (11 перегрузок), append (9), compare (9), replace (9), += (5), find (5) starts_with (3), ends_with (3), contains (3), erase (3), resize (2). И нет, это ещё не всё.

Может быть давай тогда пройдемся по методам трейтов у std::string::String?

Давай, если ты будешь готов обосновать, что из этого лишнее, а не просто ныть «ой, как много всего».

Через 10 лет половина этих функций устареет.

А через сто - устареют по два раза!

Поспорим? (:

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

Ну вот когда дело доходит до критики, мы все керниганы. Как минимум, макросы в Раст устраняют большую часть претензий, предъявляемых к макросам Си. Чем они плохи-то, кроме разве что зубодробительного синтаксиса?

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

Хах, так почему ты не пишешь на Go?

Вот только те, кто на расте пишет, недовольны совсем не тем, что ты тут и в соседних темах перечисляешь.

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

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

Плохая читаемость и медленная компиляция — это факторы, которые не дают непосредственных хорошо наблюдаемых результатов, которые можно было бы измерить линейкой и сказать «вот этот инструмент проявил себя на 37% лучше, чем другой инструмент». И, тем не менее, человек, который пользуется хорошо читаемым инструментом, предоставляющим возможность быстро протестировать написанное, при прочих равных будет справляться намного лучше человека с неудобным инструментом, даже несмотря на то, что человек со вторым инструментом не будет жаловаться (потому что ему не с чем сравнить)

Вот для коммерсов всё просто: основная преграда — это сложность обучения языку. В остальном им пофигу на чем писать и насколько этот инструмент удобен. То же относится к C++. Потому они предпочитают Go/Python/JS.

В соседнем треде я приводил аргумент, что на самом деле Perl/PHP/Python/Ruby/JS — это языки в которых тип «выводится» везде, но во время выполнения. И это чудовищно популярно, на текущий момент это намного популярнее всех языков с явным описанием прототипов.

А есть где-то статистика? По количеству кода или по количеству вакансий? Правда интересно

По количеству рыл, например:

https://insights.stackoverflow.com/survey/2020#technology-databases-professio...

Или код на гитахабе:

https://madnight.github.io/githut/#/pull_requests/2021/1

Если отнести Go к статике, то получается примерно 50% динамики и 40% статики, ну и 10% на всякие минорные языки и баш.

Можно пробовать сделать лучше (свой язык или пытаться помочь взлёту какого-нибудь малопопулярного), можно пытаться улучшить ситуацию (в контексте раста - предлагать RFC)

Мне по поводу питона подобное предлагали. Однако, существенные изменения в имеющийся язык внести практически нереально. То есть, теоретически пути существует, но 99% сообщества будет против, по тем или иным причинам. Примерно так же, как в Emacs уже десятилетиями не могут решить проблему динамической области видимости. И не решат, потому что решать ее надо было до того, как инструмент приобрел популярность. После этого изменения будут равноценны созданию совершенно нового инструмента, который нужно будет подымать с нуля.

Хах, так почему ты не пишешь на Go?

Потому что там (почти) ничего из перечисленного нет? Плюс слишком слабые типы, сборка мусора и убогая обработка ошибок.

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

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

Это как у наркоманов спрашивать про вред героина.

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

За ссылки спасибо. Честно говоря, думал, что С, С++, джавы и шарпа будет больше.

Однако, существенные изменения в имеющийся язык внести практически нереально.

Да, но я думал, что мы о ситуации когда язык «почти устраивает». Впрочем, и в этом случае можно пойти по пути скалы/котлина: создав совместимый язык, а не абсолютно новый.

Может быть давай тогда пройдемся по методам трейтов у std::string::String?

Давай, если ты будешь готов обосновать, что из этого лишнее, а не просто ныть «ой, как много всего»

Да, пожалуй, я слишком забегаю вперед, потому что пока это только мои наработки с полки, и глупо ожидать чего-то передового от индустрии, которая по десятому кругу гоняет модели 20-летней давности. Подход питона, C++, и Rust очень похож — я не просто так их упоминал тут рядом. Да. на вопрос о том, что из этого списка проще, а что сложнее, будет довольно тяжело ответить, потому что подходы похожие и сложность плюс-минус похожая. Единственная претензия к расту здесь может быть лишь в том, что он не совершил чуда и не показал нам ничего нового.

Через 10 лет половина этих функций устареет.

А через сто - устареют по два раза!
Поспорим?

Да я не сомневаюсь. Я лишь хотел указать, что никакой гибкости там нет. В остальном я согласен.

Ну вот когда дело доходит до критики, мы все керниганы

Керниганы? Это ты намекаешь на того индуса, который накодил препроцессор для ассемблера под названием «Си»? Видимо, ты пока что не принимал участия в дискусиях с моим участием.

Как минимум, макросы в Раст устраняют большую часть претензий, предъявляемых к макросам Си

Макросы Си = шаблоны C++.

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

В какой-то момент я просто начал замечать, как писал vertexua, что все ЯП являются просто копиями друг друга. Они не только копируют друг у друга хорошие приемы, но и плохие тоже. И в итоге я имею честь наблюдать, как в 2010 году какие-нибудь разработчики ЯП повторяют ошибку разработчиков ЯП 1980 года. При этом у разработчиков из 1980 есть оправдание первопроходцев, и их идеи изначально шли дальше, чем просто синтаксический сахарок, но они не смогли оценить выполнимость этих идей. ООП ведь изначально подразумевало возможность сохранения образа объектов, и только в таком контексте оно имело смысл — современное книжное понимание ООП не имеет совершенно ничего общего с изначальной задумкой.

Вот только я говорю о том, что у пишущих на расте есть претензии, просто другие

Я не сомневаюсь, что у них они другие и их видение отличается от моего. Мне интересно только одно — как они оправдывают медленную компиляцию? «Мой проект все равно не станет больше 20 к строк»? «Прошлый проект на крестах тоже медленно собирался»? «Ничего страшно, буду работать с параллельной веткой, пока эта собирается"7

Впрочем, и в этом случае можно пойти по пути скалы/котлина: создав совместимый язык, а не абсолютно новый

В случае скалы/котлина базовый «язык» — это JVM. В случае раста «совместимый язык» скорее будет фронтом к LLVM, то есть, полноценным отдельным компилятором.

«Прошлый проект на крестах тоже медленно собирался»?

В моём случае именно так, да.

В случае раста «совместимый язык» скорее будет фронтом к LLVM, то есть, полноценным отдельным компилятором.

Это да. Хотя можно попытаться сэкономить и компилировать не в машинный код, а генерировать сишный, как и делают некоторые новые языки.

«Прошлый проект на крестах тоже медленно собирался»?

В моём случае именно так, да

Вот видишь — а у меня шире кругозор, а я писал на языках, которые собирают с нуля проект объема Firefox-а за несколько минут на ноутбуке.

Я же пишу как независимое лицо

Ох, лол🤦

Макросы Си = шаблоны C++

Это к чему? Макросы и шаблоны немножко разноплановые сущности, особенно в контексте Раста.

Макросы и шаблоны немножко разноплановые сущности, особенно в контексте Раста

К тому, что макросы Си выполняют ту же функцию, что и шаблоны C++ или обобщения Rust. Да, макросы в Си еще используются для объявления констант и условной компиляции по ним, но это еще дальше от популярного смысла понятия «макрос».

Ок, но тогда макросы Раст != макросы Си/С++ и сравнивать их некорректно.

Ок, но тогда макросы Раст != макросы Си/С++ и сравнивать их некорректно

Так я тебе об этом и пишу. Ты начал их сравнивать.

Вот видишь — а у меня шире кругозор, а я писал на языках, которые собирают с нуля проект объема Firefox-а за несколько минут на ноутбуке.

Ну вообще сказанное мной никак не противоречит тому, что ты сейчас говоришь. Если прошлый проект на плюсах был медленным, это не значит, что я не писал на других языках. (:

Но вообще да, не буду отрицать: самые значительные (большие) проекты, в которых я участвовал, были написаны преимущественно на С++ или расте.

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

Ну и всё-таки я потестил хэлловорлды на Раст и С++, и вот не могу сказать что разница во времени компиляции разнится прямо В РАЗЫ. В отдельных случаях могут быть сложные случаи, которые в компиляторе Раст ещё не учли, но в целом разница времени компиляции отличается не в разы.

Не могу адекватно сравнить. Самый большой растовый проект, над которым доводилось работать, ~300к строк. Плюсовые были больше.

Ну и всё-таки я потестил хэлловорлды на Раст и С++, и вот не могу сказать что разница во времени компиляции разнится прямо В РАЗЫ

Не в разы, но все же раст компилируется дольше:

https://users.rust-lang.org/t/are-there-any-compilation-time-benchmarks-of-ru...

Но я здесь еще раз подчеркиваю, что C++ — это самый медленно компилирующийся из известных мне ЯП, И Rust смог побить этот рекорд, не в разы, но смог.

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

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

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

Что-то ещё будет?

Они будут всегда меньше потому что в Rust есть экосистема крейтов, многие из которых очень небольшие и они есть на каждый чих. После первой сборки проекта будешь пересобирать только основной крейт твоего приложения, в котором банально меньше кода. На деле что я замечаю - боттлнек у линкера. Я это замечал кода собирал проекты прямо на Raspberry Pi.

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

Ничего не будет. В языке почти ничего нет нового, это почти тот же C++, такой же трудоемкий по написанию кода, такой же перегруженный вспомогательными конструкциями и описаниями типов контейнеров, такой же медленный по компиляции. Я сам планировал освоить раст под соусом «наконец сделали годную замену ненавистному C++». Но слегка измазавшись в ржавчине я понял, что никакая это не замена — это тот же C++. Зачем он нужен? Чтобы можно было качать cargo через интернет пакеты единым интерфейсом вместо использования многочисленных костылей? Там вон скоро в C++ завезут модули. того гляди сделают пакетный менеджер, и тогда у раста вообще никаких преимуществ не останется.

После первой сборки проекта будешь пересобирать только основной крейт твоего приложения, в котором банально меньше кода. На деле что я замечаю - боттлнек у линкера. Я это замечал кода собирал проекты прямо на Raspberry Pi

Ну так раздельная компиляция же ж. А у нас при сборке гуевины на крестах производится компиляция Qt к ней?

в Rust есть экосистема крейтов, многие из которых очень небольшие и они есть на каждый чих

И это ужасно.

Как думаешь сколько минут компилирутся треугольник на Rust?

https://github.com/tsoding/vulkano-rainbow-triangle

И сколько секунд такой треугольник компилируется на С++?

Можешь проверить если у тебя установлен Rust и есть время, потом расскажешь про быструю компиляцию Rust :)

Любой может проверить.

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

Ну хз. В плюсах вон если притащить boost, Qt, abseil, то там тоже будет много всего и пересобирать это не нужно. В конце концов, и в расте и в С++ на больших проектах многое выносится во внутренние библиотеки, которые тоже редко пересобираются.

Как думаешь сколько минут компилирутся треугольник на Rust?

Со всеми зависимостями (74 крейта) – 5 минут. Билд и линковка самого крейта – 5 секунд.

$ time cargo build --release
   Compiling vulkano-rainbow-triangle v0.1.0 (/Users/xxx/Downloads/vulkano-rainbow-triangle-main)
    Finished release [optimized] target(s) in 5.28s

real	0m5.397s
user	0m22.323s
sys	0m0.343s

Да плевать на время компиляции. В языке есть объективно крутые фичи, ради которых поступились временем компиляции, хотя бы тот же вывод типов.

У хейтеров закончились аргументы, кроме как попрёки скоростью компиляции?

В языке почти ничего нет нового, это почти тот же C++, такой же трудоемкий по написанию кода, такой же перегруженный вспомогательными конструкциями и описаниями типов контейнеров, такой же медленный по компиляции.

Враньё в каждой букве. В Раст реализовано очень многое из того, о чём десятилетиями мечтали крестописаки. Но теперь они быстро переобуваются и утверждают, что всё это «НИНУЖНА НИНУЖНА СЛЫШАТИ НИНУЖНА».

Всё, я отписываюсь от треда, пусть тут дальше крестописаки порванные части тела массируют.

В смысле аргументы? У него не было аргументов. Были утверждения.

«Фич нет, язык говно, все плохо» - это не аргументы. Это в лучшем случае набор утверждений, но по настоящему это нытье. И ноет он уже 9 страниц

У хейтеров закончились аргументы

C++ безопаснее Rust, иначе как объяснить, что за всю историю Visual C++ standard library + libstdc++ + libc++ имеют меньше уязвимостей чем Rust standard library?

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libstdc%2B%2B

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libc%2B%2Babi

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Visual+C%2B%2B+standard+library

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust+standard+library

Вот C опасный, там в стандартной библиотеке много уязвимостей было, в одной только glibc: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=GNU+C+Library

А С++ безопаснее Rust, доказано многолетней статистикой…

годный вброс

но заметь, в 21 году сишечка родила 3 CVE против 8 у растишечки.

тагштааа….

Блин, возьми слаку с зависимостями...

Блин, возьми слаку с зависимостями...

28.05.21 - хмм, ты 10 дней думал над ответом? спасибо, конечно, за этот обдуманный и очень ценный совет, но... что если с патриком что-то случится? да и был я на слаке, когда это было модно.

В языке есть объективно крутые фичи, ради которых поступились временем компиляции, хотя бы тот же вывод типов.
У хейтеров закончились аргументы, кроме как попрёки скоростью компиляции?

В таком ключе — не закончились. Потому что в языке объективно нет крутых фич, есть лишь фичи немного лучше, чем в C++, и только по сравнению с этим самым C++, который в расте по большей части повторен со всеми его недостатками.

В Раст реализовано очень многое из того, о чём десятилетиями мечтали крестописаки

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

Вот C опасный, там в стандартной библиотеке много уязвимостей было, в одной только glibc: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=GNU C Library

Glibc — это эталон чрезмерной оптимизации-лапшизации. Это совершенно нечитаемый код, который на первый взгляд даже не похож на Си. Но тут как бы дело в том, что в сообществе писак на Си считается нормой забивать по черному на стабильность работы/безопасность.

Glibc — это эталон чрезмерной оптимизации-лапшизации.

olelookoe , byko3y

Кстати да. Если взять musl, то там тоже меньше уязвимостей чем в Rust standard library, хотя musl появился раньше.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=musl

Совокупное количество уязвимостей в Visual C++ standard library + libstdc++ + libc++{abi} + musl меньше чем в Rust standard library :)

Так какой язык у нас безопасный С вместе с С++ или Rust?

Ахаха.

Потому что в языке объективно нет крутых фич

РРРРРЯЯЯЯЯЯЯ НЕТ НЕТ НЕТ ИХ СЛЫШАТИ НЕЕЕЕТ

Краткое содержание предыдущих 10 страниц

но заметь, в 21 году сишечка родила 3 CVE против 8 у растишечки.

На нашей деревяшке, которую мы полируем 30 лет, обнаружилось всего 3 задира!

но заметь, в 21 году сишечка родила 3 CVE против 8 у растишечки.

На нашей деревяшке, которую мы полируем 30 лет, обнаружилось всего 3 задира!

Musl в 2011 году релизнута. Вообще, спорить тут мало смысла, потому что стандартная либа раста, как и musl, как и glibc написана на небезопасных указателях, потому никакой компилятор не помогает от багов в ней. На самом деле, библиотека раста тупо больше: где-то 20 Мб против 3 Мб в musl.

Сорян, я не крестописака

Дай угадаю: пых? Или всё же жаваскрипт?