LINUX.ORG.RU

познать Rust

 


2

6

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

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

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

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

★★★★★

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

Читал много отзывов и наших и их. Отношение к Расту сейчас по меньшей мере негативно-настороженное. Главная мысль, нахрена нам Раст, когда есть C++11/14/17. C++ будет всегда, и лучше инвестировать в него.

Полностью согласен. Во-первых, и в мире C++ есть непаханное поле, на котором можно развернуться. Например, LLVM и потроха GCC, статические анализаторы, разнообразные санитайзеры.

Во-вторых, хочешь реального хардкора — инвестируй в Хаскель. Тут тебе из «зелёные» потоки, и STM, и многозадачность в стиле Эрланга, и гибкий рантайм, и крутой сборщик мусора, и целый спектр нерешенных задач различной генеалогии и требуемых скиллов от приведения в божеский стандартных библиотек до нетривиальной математики.

В-третьих, нет никаких гарантий что Раст сможет выжить. В смысле, самостоятельно ему *пока* не выжить. Накрылся мозилловский проект альтернативного движка — всё.

В-четвёртых, все кто хотел свалить с C++ — давно уже свалили, так что участь убийцы оного, ему (да и любому другому языку) не светит.

И последнее, на кой тебе изучать ещё одни бредни левых пяток очередных комитетских мудаков? Для этого есть C++. Там можно бесконечно заниматься дроч^W обсуждением разницы в семантике ++i и i++, или move-семантики, или разницей между {} и (). По крайней мере *это* монетизируется, в отличие от.

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

В Java finally — это нифига не C++ные деструкторы. В Java вы либо должны вручную писать close в блоках finally, что некоторые забывают делать, либо же делать close в finalize() и иметь те же самые проблемы, что и в C++.

Так что давайте еще раз: в каком другом языке вы с полтычка решаете проблемы выбрасывания исключений из деструкторов.

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

Даже в рамках C++ можно было узаконить 4-байтовость wchar_t

Успокойся, уже. См. напр. char16_t и char32_t.

Что же прекрасного в классе std::string, который почти ни на что не годен?

Юзай ICU! Ах да, бинарник распух, сложность взлетела до небес? Зато всё по фен-шую. Не нужно тащить *это* в стандартную библиотеку.

Macil ★★★★★ ()
Ответ на: перечитывая "Unix Haters Handbook" от anonymous

перечитывая «Unix Haters Handbook»

Прошло больше 20-ти лет. Где Unix, а где эти чудаки, на букву М, которые написали хрен знает что?

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

Новизны нет.

лайфтаймы, семантика владения/одалживания ?

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

Есть ещё try with resources. Выглядит так:

try (Closeable object = new SomethingCloseable) {
    ...
}
catch (SomeException e) {
    ...
}
Писать close самому не нужно. Но это опять же не C++ деструкторы, а сахар поверх вложенных try catch.

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

Отношение к Расту сейчас по меньшей мере негативно-настороженное

Можно линки на репрезентативные статьи? Я, конечно, не там тусуюсь, но ничего негативного о Rust еще не читал.

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

Во-первых, насколько позже деструкторов это появилось?

Во-вторых, как это себя ведет при вложенных друг в друга try with resources?

eao197 ★★★★★ ()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

Где Unix ?

ты не переживай, по нему ещё больше проехались:

You know the real trouble with Unix? The real trouble is that it became so popular. It wasn’t meant to be popular. It was meant for a few folks working away in their labs, using Digital Equipment Corporation’s old PDP-11 computer.


<...> Unix was a programmer’s delight. Simple, elegant underpinnings. The user interface was indeed horrible, but in those days, nobody cared about such things.
<...> I survived. Worse, Unix survived. Unix was designed for the computing environment of then, not the machines of today. Unix survives only because everyone else has done so badly. There were many valuable things to be learned from Unix: how come nobody learned them and then did better? Started from scratch and produced a really superior, modern, graphical operating system? Oh yeah

итого:

What is this horrible fascination with Unix? The operating system of the 1960s, still gaining in popularity in the 1990s. A horrible system, except that all the other commercial offerings are even worse.

ну почти как С++ (кстати, что ядро чего там Страуструп на С++ моделировал) — получился монолитный блоб, ОО кобол и ассемблер в одном лице. костыли, как они есть.

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

но ничего негативного о Rust еще не читал.

А я про хаскель ничего негативного не читал ;) кроме откровенных бредней и/или фактов десятилетней давности. Но, это же не повод.

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

костыли, как они есть.

Это костыли повсюду. И, судя по всему, спокойно переживут всех анонимных тимлидов аналитиков с LOR-а.

Не исключено, что и с C++ будет аналогичная ситуация.

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

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

ну например, тот же CLOS с сигнальным протоколом ошибок, с рестартами и условиями. нет исключений — нет ошибок. нет деструкторов (но есть финализаторы, и можно изобразить RAII) — нет проблем.

подробности у den73, он что-то такое делал на RAII в CL. ну или в статье про «Interface Passing Style».

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

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

дескать: а мы ещё и вот так могём, с переподвывертом !!! :)))

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

Все Lisp-еры настолько тупые, что не способны прочитать вопрос? Спрашивалось про деструкторы.

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

Только вот почему-то мало кто отдает себе в этом отчет. Но для звиздежа на форумах — самое оно получается.

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

А я про хаскель ничего негативного не читал ;)

А я не говорил, что «много негативно-настороженных отзывов и наших, и их». Так будут линки?

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

Нет, похоже, тупы не все Lisp-еры, а только чмо аноним со смайликами, которое который приходит уныло срать в камменты во все темы про Rust, D и C++.

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

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

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

А я про хаскель ничего негативного не читал

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

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

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

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

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

количество вовсе не означает качество, особенно в случае с С++.

важна одна правильная идея, а не 10500 неправильных попыток на тему идеи.

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

Сильно позже. Это появилось в Java 7 (2011 год).

Завершается блок try - вызываются close для объявленных между скобок ресурсов. Если внутри блока выскочит исключение, то close будет вызван всё равно. Отвечу песней:

try (ExceptionCloseable closeable = new ExceptionCloseable()){
    try (JustCloseable justCloseable = new JustCloseable()) {
        throw new Exception("Inner exception");
    }

}
catch (IOException e) {
    System.out.print("IO: " + e.getMessage());
}
catch (Exception e) {
    System.out.println("Other:" + e.getMessage());
    System.out.println("Suppress exception: " + e.getSuppressed()[0].getMessage());
}
Объявление классов:
private static class ExceptionCloseable implements Closeable {

    @Override
    public void close() throws IOException {
        throw new IOException("Close exception");
    }
}

private static class JustCloseable implements Closeable {

    @Override
    public void close() throws IOException {
        System.out.println("Close JustCloseable");
    }
}
Вывод:
Close JustCloseable
Other:Inner exception
Suppress exception: Close exception
Как видите, вложенный try with resource закрылся, исключение брошенное из операции close было подавлено. Его можно достать, но вряд ли кто-то этим озаботится. В try можно объявлять несколько Closeable ресурсов, но вы спрашивали про вложенные - и я сделал вложенные.

Если что, я не против С++ и концепции деструкторов. Она мне нравится. Просто показал способ.

Weres ★★★ ()
Последнее исправление: Weres (всего исправлений: 1)
Ответ на: комментарий от anonymous

важна одна правильная идея, а не 10500 неправильных попыток на тему идеи.

Поклонники CLOS-а эту мантру будут еще 30 лет повторять?

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

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

вместо адкватного, при котором этой проблемы просто не возникает. потому что структурированы концепции адекватно — не как карточный домик.

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

Сильно позже. Это появилось в Java 7 (2011 год).

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

Даже возможность создания исключений, сохраняющих информацию о предшествующих исключениях, появилась в C++11. И далеко не все C++ники, к сожалению, могут пользоваться даже C++11, не говоря уже про C++14.

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

выдумывая на проблему неадекватный способ решения

Специально для анонимных CLOS-еров: я ничего не выдумываю. Просто говорю о том, что есть Unix, который переживет тучу интеллектуалов, находивших в нем фатальные недостатки. Есть C++, который имеет шансы пережить кучу не менее интеллектуальных интеллектуалов, находящих в нем еще более фатальные недостатки.

Просто есть то, что есть и чем можно пользоваться с минимальными накладными расходами: Unix, C++, Java и т.д. А есть идеальный мир, который грезится анонимным LOR-аналитикам.

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

с минимальными накладными расходами: Unix, C++, Java и т.д

wrong, plain wrong.

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

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

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

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

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

В java уже 4,5 года как это есть, вылезай из криокамеры.

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

В Java вы либо должны вручную писать close в блоках finally

и тебе посоветую вылезти из криокамеры - 4,5 года как не должны

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

try (ExceptionCloseable closeable = new ExceptionCloseable()){

После RAII это как malloc/free в С - ручная работа, которую компилятор даже не помогает проверять.

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

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

в rust есть.

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

в rust есть.

Что есть: другие проблемы или деструкторы с исключениями?

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

Согласен. Я пишу на Java и мне этот язык нравится. Но я не стану утверждать, что он самый лучший на земле. RAII - прекрасная концепция.

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

Специально для анонимных CLOS-еров: я ничего не выдумываю. Просто говорю о том. Есть C++, который имеет шансы пережить кучу не менее интеллектуальных интеллектуалов, находящих в нем еще более фатальные недостатки

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

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

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

а ты пытаешься решать неправильным методом, таким способом который сам по себе является проблемой, а не решением.

но ты почему-то выдумал, что решать эту задачу нужно именно этим, привычным тебе — но неправильным методом.

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

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

ты прочитай сообщение-то на которое отвечаешь, дурилка картонная.

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

включи мозги и научись думать. разумно, осознанно — а не комбинаторно.

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

компилятор даже не помогает проверять.

4.2

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

4.2

Т.е. ты хочешь сказать, что компилятор говорит, что вот тут надо try-with-resources? Может он еще и код сам пишет?

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

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

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

Я не говорю, что в C++ правильный подход, а в CLOS-е — неправильный. Или наоборот.

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

И если жизнь заставляет писать на C++, а не на CLOS, то плакать о том, что в C++ «неправильный» подход к обработке ошибок нет никакого смысла.

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

А можно развернуть мысль? Тут может помочь синтаксический анализатор, указав что Closeable объект не закрыт. А как в данном случае помогает компилятор?

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

Массив байтов, обозванный строкой, например.

Ок, но если бы строки не пихали в стандартную библиотеку разве было бы лучше? Думаешь, в таком случае, появились бы «нормальные строки»? Я вот не уверен, ведь их и сейчас никто не мешает добавить. Опять же, для ряда задач и такие строки сгодятся. То есть, кое-где стало удобнее и уж точно не хуже.

Перегрузка операторов меня не смущает, так что это вкусовщина. Ну и да, функция to_string появилась.

Какие-то придуманные на ровном месте проблемы с исключениями в деструкторе

Постой, ты начинаешь с того, что стандартная библиотека «всё испортила». Но деструкторы всегда такие были. Можно, конечно, не вызывать close в деструкторе, но заставить вызвать его руками и обработать потенциальные ошибки нет возможности. Так что это не проблема деструкторов.

В любом другом языке я выкину ошибку тем или иным образом. В C++ я могу только поругаться в консоль.

Ерунда. Если тебе надо, то зови close явно и обрабатывай ошибки. В «других языках» тебе точно так же никто не мешает игнорировать их.

Отсутствие стектрейсов у исключений.

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

Ну и как пример тоже относительно нового языка - Go. В нём, если я ничего не путаю, по умолчанию, точно так же, нет стектрейсов.

Зоопарк реализаций стандартных структур данных.

О чём речь?

Слишком гибкая система классов

И это хорошо. Отсутствие общего предка имеет вполне заметные преимущества (как и недостатки).

это ведь ужасно.

Что именно?

Когда отвёрткой забивают гвозди, ничего хорошего в этом нет.

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

Это не проблема языка и шаблонов, что их можно использовать не только для «векторов и списков». Проблема - что ничего получше нет. Может когда-то и решится, отдельные улучшения ведь уже появляются. В любом случае, без шаблонов было бы хуже.

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

Что же прекрасного в классе std::string, который почти ни на что не годен?

Чего конкретно тебе не хватает?

Даже в рамках C++ можно было узаконить 4-байтовость wchar_t и объявить std::string устаревшей.

Добро пожаловать в современный мир:

http://www.cplusplus.com/reference/string/u32string/

а std::string прекрасно себе хранит utf-8.

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

Даже в рамках C++ можно было узаконить 4-байтовость wchar_t и объявить std::string устаревшей.

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

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

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

В смысле? Раст не стандартизирован и подход к разработке менее формальный. Проще вносить предложения и т.д. Да, есть люди чьё мнение окажется более важным, но с каким языком не так?

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

(хотя такие примеры с рестартами на С++ я видел).

Покажешь?

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

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

В java уже 4,5 года как это есть, вылезай из криокамеры.

В finally-блоках нет.

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

Я уже сказал, это ваши проблемы что вы не в состоянии прочитать столь короткое сообщение

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

То, что Rust не стандартизирован и является разработкой одной лишь Mozilla - минус языка. Пора уже стандартизировать. Как и биндинги к сишным библиотекам. Те, которые есть сейчас - уродство.

Deleted ()
Ответ на: комментарий от I-Love-Microsoft

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

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