LINUX.ORG.RU

познать Rust

 


2

6

Доброго времени суток. Ищется материал по Rust, где:

1. В сжатой, но понятной форме изложено положение Rust в контексте других языков. В чём суть его новизны. В качестве базы ожидается C++, Java, Common Lisp. Желательно, с примерами кода.

2. Критика. Какие грабли уже проявили себя.

Желательный объём - до 5 страниц текста.

★★★★★

Ответ на: комментарий от maloi

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

eao197 ★★★★★ ()
Ответ на: комментарий от pashazz

а уж тем более, думается, плюсов у Rust перед C++14/17 и вовсе нет

Есть - макросы, pattern matching, lifetimes. Впрочем есть и много минусов. Вот как замена С он вполне хорош. Но заменить его не сможет, слишком поздно.

anonymous ()
Ответ на: комментарий от Macil

нахрена нам Раст, когда есть C++11/14/17. C++ будет всегда, и лучше инвестировать в него.

Вот чтоб этого дерьма несусветного не видеть, люди и пилят раст. Ибо крестоговно с последними стандартами в такое говно катится, что пользоваться этим становится невозможно.

Freyr69 ★★★ ()
Ответ на: комментарий от Deleted

Пора уже стандартизировать.

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

Как и биндинги к сишным библиотекам.

В смысле?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Freyr69

с последними стандартами в такое говно катится, что пользоваться этим становится невозможно.

Может хоть ты сможешь сказать что «с последними стандартами» становится хуже?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Freyr69

Ибо крестоговно с последними стандартами в такое говно катится, что пользоваться этим становится невозможно.

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

anonymous ()
Ответ на: комментарий от DarkEld3r

Интересно даже не это, а совсем другое: что в новых стандартах мешает олд-скульным C++никам продолжать использовать C++ привычным им способом. Может быть то, что override, noexcept и final стали ключевыми словами?

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

Давайте вы мне сначала покажете в Rust-е деструкторы и исключения

Да забей - в расте с исключениями ничуть не лучше чем в С++. Паника в деструкторе вызванном из-за паники - аборт.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Может хоть ты сможешь сказать что «с последними стандартами» становится хуже?

Х%й у него перестал вставать, вероятно, а во времена С++98 еще кое как работал.

anonymous ()
Ответ на: комментарий от eao197

что в новых стандартах мешает олд-скульным C++никам продолжать использовать C++ привычным им способом

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

О том и речь. Я, например, вообще не представляю, как после C++11 можно на C++03 возвращаться. Даже за гораздо большие деньги.

eao197 ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Как и стабилизировать биндинги...

Слово я пропустил.

Смущает, что не стандартизованны.

Deleted ()
Ответ на: комментарий от DarkEld3r

Может хоть ты сможешь сказать что «с последними стандартами» становится хуже?

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

Freyr69 ★★★ ()
Ответ на: комментарий от Freyr69

легаси и все такое
гарантированно содержит тонны багов и проблем
написание кода = бессонные ночи отладки
говно бай дизайн

Приятно видеть экспертов в треде.

Weres ★★★ ()
Ответ на: комментарий от Freyr69

Когда вы в последний раз писали decltype((((((j)))))) в продакшен коде?

eao197 ★★★★★ ()
Ответ на: комментарий от Freyr69

Пройдешь без запинок, эксперт?

А зачем? Написать нечитаемую ахинею можно на любом языке - хоть на Си++, хоть на русском.

tailgunner ★★★★★ ()
Ответ на: комментарий от Freyr69

ибо говно бай дизайн нельзя сделать конфеткой, просто добавляя фич.

Ломать совместимость тоже нельзя. Твоё решение?

Ну и мне всё-таки очень интересно какие новые фичи «добавляют проблем». Или все проблемы - это раздутый стандарт?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Ломать совместимость тоже нельзя. Твоё решение?

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

Ну и мне всё-таки очень интересно какие новые фичи «добавляют проблем»

Стандарт, да. Ну и новые подводные камни. То есть достаточно открыть какой-нибудь сипипиквиз, чтоб осознать, что далеко не всегда очевидно, как это все работает.

Freyr69 ★★★ ()
Ответ на: комментарий от Freyr69

Судить о языке по викторине, это находка. Вы на работе тоже код из викторин пишете?

Weres ★★★ ()
Ответ на: комментарий от Freyr69

Ну и новые подводные камни.

Возможно. Но приведённый пример точно не катит. Во первых, какова реальная применимость таких извращений? Во вторых и что главнее - какова цена ошибки? В смысле, ожидал я, допустим, int, а получился const int&. И что ужасное случится?

DarkEld3r ★★★★★ ()
Ответ на: комментарий от anonymous

Вот да. RAII последовательно решает проблему управления любыми ресурсами. GC решает проблему управления памятью, но при этом вынуждает управлять всем остальным вручную, так как общего решения, безопасно работающего в любом случае, сделать нельзя из-за недетерминированного управления базовым ресурсом памяти. Сообщество managed-языков конечно напирает на то, что non-memory ресурсы редкие, так что им не впадлу поуправлять руками, но они редкие только в энтерпрайз-перекладывалках данных и научных расчётах.

anonymous ()

познать Rust

В библейском смысле?

anonymous ()

В топике не хватает только Iron Bug, рассказывающей про то, что кошерно только трахать байты на си под микроконтроллеры с 1кб рам, а все остальные быдлокодеры

anonymous ()
Ответ на: комментарий от DarkEld3r

Во первых, какова реальная применимость таких извращений? Во вторых и что главнее - какова цена ошибки?

Да не знаю я. Ну вот у меня сейчас перед глазами код с двухстраничными switch-case и каким-то безумием на mfc. Если язык позволяет так писать, кто-то обязательно так напишет, ты же в команде работаешь, выше вон говорят, мол, писать говнокод можно на любом языке, но говнокод на сипипи особенный.

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

Freyr69 ★★★ ()

В чём суть его новизны.

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

Критика. Какие грабли уже проявили себя.

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

Довольно тяжело читать код с лайфтайми, дженериками, в перемешку с макросами. К тому же отсутсвует IDE заточенная под Rust, которая до компиляции показывала бы тебе все ошибки, как это делается в Java.

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

foror ★★★★ ()
Ответ на: комментарий от Freyr69

Вот чтоб этого дерьма несусветного не видеть, люди и пилят раст.

Я слишком долго живу на свете, и в сказочки уже не верю... Старость...

Вот в то что команда Раста «осваивает» мозилловское бабло вследствие повышения уровня розовых соплей в бошках руководства — верю охотно.

Ибо крестоговно с последними стандартами в такое говно катится

Напоминаю, все кому кресты объективно мешали, давно уже с них свалили. Никакого «скатывания» в куда бы то ни было я не заметил.

Скорее наоборот, интерес к C++ только возрос как только прошёл угар ООП-ООД (т.е. все неадекваты дружно свалили в динамические недоязычки).

Macil ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Раст не стандартизирован и подход к разработке менее формальный.

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

Да, есть люди чьё мнение окажется более важным, но с каким языком не так?

С хаскелем, например. Причём это верно как для самого языка, так и для «сторонних» библиотек.

Macil ★★★★★ ()
Ответ на: комментарий от eao197

Зачем в нём это криво спроектированное говно?

maloi ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Паника в деструкторе вызванном из-за паники - аборт.

Вообще исключение в деструкторе не обязательно вызывает аборт (терминейт). По-умолчанию это так, да. но никто не мешает сделать

class keeper {
public:
    keeper( ... ) 
    { ... }
    ~keeper( ) noexcept(false)
    {
        if( !std::uncaught_exception( ) && some_exit_cond ) {
            throw std::runtime_error("1\n");
        }
    }
};

void call( )
{
    keeper k( .... );
    ........
    if( some_internal_cond ) {
        throw std::runtime_error( "2\n" );
    }
}

int main( )
{

    try {
        call( );
    } catch ( std::exception &ex ) {
        std::cout << ex.what();
        return 1;
    }
    return 0;
}

Правда задачи под такое очень редки.

anonymous ()

Ищется материал по Rust, где

Годик обожди :) Или напиши.

slackwarrior ★★★★★ ()
Ответ на: комментарий от eao197

Надо эти смайлы аффтару квиза вырезать ножыком на лице.

slackwarrior ★★★★★ ()
Ответ на: комментарий от eao197

Если платили б только за новый кот на плюсах - безусловно :)

slackwarrior ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Я отвечал на вопросы в обратном порядке. Меня смущают нестандартизованные и популярные языки.

За стабильную libc - спасибо, посмотрим.

Deleted ()

Не вижу в Русте смысла, лучше ботать Свифт. Он как-то посерьёзнее выглядит. Под Линух есть. И рустовые вакансии ещё поди поищи, а свифтовые будут расти.

Hertz ★★★★★ ()
Ответ на: комментарий от Hertz

Не вижу в Русте смысла, лучше ботать Свифт

эскобар.жпег

anonymous ()
Ответ на: комментарий от maloi

Вы бы определились: либо в Rust-е деструкторы есть (по вашему же утверждению), либо там это «криво спроектированное говно» не нужно.

А то ведь Rust-овский drop не тянет на C++ные деструкторы по обозначенными выше причинам.

eao197 ★★★★★ ()
Ответ на: комментарий от Freyr69

Мне сложно судить о раст, но хотелось бы верить, что он таковым станет.

Мне весьма нравится раст, но подозреваю, что если показать специально отобранные куски кода, то тебе захочется обратно на MFC убежать. (:

DarkEld3r ★★★★★ ()
Ответ на: комментарий от foror

К тому же отсутсвует IDE заточенная под Rust, которая до компиляции показывала бы тебе все ошибки, как это делается в Java.

А чего сразу джава? Для плюсов такое есть? Чтобы надёжно и быстро? У меня не всегда даже автодополнение нормально работает в QtCreator.

Так можем будем сравнивать сопоставимые вещи?

но при этом не предоставив какого-то синтаксического сахара для простоты работы с этими композициями

На данный момент, да.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от DarkEld3r

Разве они не вдохновлялись окамл? Что там может быть такого ужасного?

Freyr69 ★★★ ()
Ответ на: комментарий от Macil

Напоминаю, все кому кресты объективно мешали, давно уже с них свалили.

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

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Macil

Говоря проще, развитие диктуется не технической целесообразностью, а желанием левой пятки очередного комитетского мудака

Даже не знаю как этот бред комментировать.

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

С хаскелем, например. Причём это верно как для самого языка, так и для «сторонних» библиотек.

Ты бы хоть немного вопросом поинтересовался что ли. У хаскеля есть комитет и отдельный для «Core Libraries».

В общем, всё понятно - про оба языка знания отсутствуют, но основанное на фантазиях, мнение имеется.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от Macil

Напоминаю, все кому кресты объективно мешали, давно уже с них свалили.

Некуда валить-то. Языки со сборкой мусора и прочим jit — не канают.

Manhunt ★★★★★ ()
Ответ на: комментарий от anonymous

Вообще исключение в деструкторе не обязательно вызывает аборт (терминейт).

Дык, я такого не говорил. А вот исключение выброшенное из деструктора, который вызвался из-за другого исключения - вызывает.

Ну и собственно, я говорил о том, что в расте ситуация такая же. За исключением отсутствия uncaught_exception, ну и того, что паника - это недоисключения.

DarkEld3r ★★★★★ ()
Ответ на: комментарий от slackwarrior

Если платили б только за новый кот на плюсах - безусловно :)

Можно найти работу, где не придётся копаться в древнем легаси. Или где оно, хотя бы, переписывается понемногу.

DarkEld3r ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.