За последние десять лет появилось не столь много новых языков программирования. Один из самых обсуждаемых — Rust. Исследования сообществ языков программирования показали, что растовцы самые счастливые, что мы тут тоже обсудим. Это язык без cборки мусора, с zero-runtime, типобезопасный и с мощными средствами абстракции. На нём даже написали операционную систему! Так в чём подвох? Почему весь мир не перешёл на Rust, несмотря на призывы его фанатов? Почему даже Go — язык с GC — часто опережает Rust по скорости? Далее я приведу свои наблюдения по этой теме.
...
Этот язык пропитан ложью: он пытается быть низкоуровневым, несмотря на невероятно высокоуровневую природу; пока он претендует, что не включает в себя сборщики мусора, его сообщество активно их использует; он забывает о последовательных программах в погоне за параллельными, и в итоге весь код становится писать сложней; он заявляет о том, что даcт прекрасные макросы, а на деле подсовывает лишь неудобное подобие, при этом существенно замедляющее время компиляции всех программ. Это язык-монстр, но ещё страшней его сообщество.
...
Несмотря ни на что, на Rust можно писать хорошо работающие программы. Но делать это будет крайне неприятно, а сами программы будут очень мало кому понятны, да их ещё и будет критиковать токсичное сообщество. Каким-то чудом в сообществе Rust умудряются выжить единицы адекватных программистов, и мне больно видеть, как их разъедает ржавчина. Не давайте себе и своему железу заржаветь!
Подводя итоги: не зря Mozilla сократила команду, работавшую над Rust.
Здравствуйте, Michael7, Вы писали:
M>Обсудим статью? http://rustmustdie.com/
M>(мопед не мой, если что)
статью писал буквально(!) студент. имеет смысл послушать людей использующих язык в коммерческих проектах, плюсы, минусы.
что там по скорости (как performance так и development time) в сравнении с теми же плюсами, действительно ли багов меньше при разработке, что с поддержкой IDE, легко ли переучиваться и много ли народу уже на нем кодит (легко ли нанять).
а кишки компилятора/рантайм и синтаксический сахар пусть студенты ковыряют
При этом невозможно занести сумму в x, ведь это неизменяемое значение. Почему не константа? Константами в Rust именуется ещё одна, третья сущность, обозначающая константы времени компиляции, те что в Си обычно определяются через define:
Что тут такого? В С++ также: переменная, const переменная и constextr времени компиляции.
Далее про обязательный mut для изменяемых переменных — а почему бы и нет? В С++ надо не забывать вставлять const, а тут не забудешь.
Ну и т.д.
Здравствуйте, Michael7, Вы писали:
M>Обсудим статью? http://rustmustdie.com/
Автор некомпетентен.
Итераторы — это по его мнению сложная конструкция. Подсчет ссылок — это уже сборщик мусора.
Я сам раст не особо знаю, только начал решать на нем adventofcode в этом году и всё. Было бы интересно почитать по недостатки. Но здесь просто брюзжание человека, который дальше С++ не ходил, да и его скорее всего не знает.
Статья — полнейший КГ/АМ.
Я скипнул на месте, где автор путает процедурные макросы и macro_rules
Народ, а там будет нытьё на тему "а вот в сишке сложные функциональные типа объявлялись через жопу по правилу улитки, а в Расте не так, это плохо, я хочу чтоб в Расте типы тоже объявлялись через жопу, потому что я привык делать это как в сишке и не могу переучиться"?
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, kaa.python, Вы писали:
KP>Язык программирования в котором разработчик выполняет работу компилятора по доказанию клрректности времени жизни объектов — это нонсенс.
В общем случае компилятор не может предсказать, куда денется ссылка на объект. Поэтому либо переносится нагрузка на рантайм, либо добавляется куча жёстких правил в языке.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>В общем случае компилятор не может предсказать, куда денется ссылка на объект. Поэтому либо переносится нагрузка на рантайм, либо добавляется куча жёстких правил в языке.
Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
Я вообще не могу себе представить причину которая сегодня побудила бы взять Rust, если есть Go, C++, Elixir и куча языков на JVM. ичсх ни один из них не перекладывает работу компилятора на разработчика, даже C++ с его тяжелым наследием.
Лень читать. Если вкратце по языку, то язык годный. Но он не взлетит даже не потому, что для плюсистов он неинтересный, а для сишников сложный, а потому что на нём нельзя "херак-херак и в продакшен"
Здравствуйте, kaa.python, Вы писали:
KP>Да если бы оно работало А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
Ну в общем случае — да, приходится сводить всё к Rc<RefCell>, в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Ну в общем случае — да, приходится сводить всё к Rc<RefCell>, в С++ приходится держать в голове кучу правил "не обращаться по этому указателю после того, как уничтожен тот буфер".
В современном мире такое может быть только если команда C++ Core Guidelines не осилила. Последний раз такое лет, наверное 10 назад видел, еще до того как C++11 начал массово проникать в плюсовое сообщество.
А вот получать удовольствие от зоопарка Rc<RefCell> в Раст надо как раз сейчас, что собственно и дико выглядит.
Разве "Раст" — это не такая же тухлая тема, как МММ? ДАВНО уже стало ясно (ещё с первых недель появления ржавчины в Тырнетах), что язык — полное гогно. Вернее, его изящно закамуфлированная "мозго_й_опка с памятью", которую разрабы аккуратно вывалили на бедного погромизда. Напомню — в C# и то находятся лабухи, ловящие NRE! И это при том, что язык насквозь безопасный и берущий на себя почти всю работу с памятью! Погромизду остаются ТОЛЬКО моменты, где память надо выделять (что в принципе довольно простая проблема). В Расте же на разраба свалена ВСЯ работа, да ещё с хитроподвывертом.
И поняв, что это гогно "никак не взлетает", по форумам стали запускать "Лёней Голубковых", которые враньём/агитацией макают всех в свои ржавые помои. Собственно, даже обсуждение "какое это гогно" — косвенная агитация и излишний хайп/цитируемость к этому дерьму. (вот почему минус) Может, хорош уже насиловать стюардессу?! Один раз закопали — И ХВАТИТ!
Здравствуйте, kaa.python, Вы писали:
KP>В современном мире такое может быть только если команда C++ Core Guidelines не осилила. Последний раз такое лет, наверное 10 назад видел, еще до того как C++11 начал массово проникать в плюсовое сообщество.
Ага, конечно, надо "просто помнить" кучу правил инвалидации итераторов.
А ещё очень круто, когда у тебя есть проект, в котором спокойно указатели используются в качестве ключей хеш-мапы, это наверное команда не осилила гайды. Проект называется LLVM, если что.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Michael7, Вы писали:
BFE>Я Rust не знаю, но как я понял, единственная реальная претензия — это неэффективный генерируемый код.
Так там автор (ученик самого Столярова) не осилил ключ компилятора -O
А то выходят монстры из портянок с Box/Rc/Arc/Cell которые надо хитро использовать в разных случаях что бы компилятор остался доволен, но они еще и до кучи херят гарантии времени компиляции, добавляют кучу боли, но не делают код безопаснее куда как более простого кода на C++.
