Другая, гораздо более трудная для понимания проблема с идиоматическим циклом Rust заключается в том, что в некоторых случаях компилятор добавлял некоторый дополнительный код настройки итератора, который действительно раздувал код. Я так и не понял, что вызывает эту дополнительную настройку итератора
match IntoIterator::into_iter(0..10) {
mut iter => loop {
let next;
match iter.next() {
Some(val) => next = val,
None => break,
};
let x = next;
let () = {
// do code
};
},
}
На первом этапе нужно хотя бы сообразить, что вам нужна именно абстракция, а уже потом решать, какая хорошая, какая — нет. Я вижу именно это начальное суждение в данном заголовке, потому что не для всех очевидно, что со сложностью нужно бороться с помоцью абстракции.
Дело в том, что основное преимущество использования классов стилей — это создание высокоуровневых абстракций и сокрытие их реализации. Вам не надо знать, какого размера или цвета кнопка, если она по смыслу использования "btn-primary" — такой класс и используете. А уж какой там конкретно стиль "под капотом" — не суть важно.
Самое элементарное: оберните инты в классы, чтобы добиться контроля типов со стороны компилятора, и посмотрите, что произойдет с производительностью вашей программы. В моем случае она падала почти на порядок.
А почему должен? Этот метод достает из Option значение или приводит к панике, если там оказался None. Если вы в своем коде позвали этот метод, то наверное вы сознательно это сделали? О чем тут компилятор должен предупреждать? Если бы вызов unwrap считался ошибкой, то такого бы метода просто не было.
Слишком сложная многопоточность, вечные NPE, необходимость иметь под рукой эксперта по тюнингу JVM, если не хочешь принудительно перезапускаться раз в месяц, непредсказуемые моменты сборки мусора и освобождения ресурсов, нарастающие тормоза при попытке писать выразительный высокоуровневый код.
Ну и сам язык развивается путем накручивания костылей сверху, яркий пример — система модулей. Появляется куча нюансов, которые нужно знать и учитывать, как только ты чуть сворачиваешь в сторону от написания типового шаблонного кода. Простой и лаконичной Java я бы не назвал, во многих аспектах она сложнее, чем Rust.
А чего вы ожидали? Встроенную синхронизацию в сам язык, а не спец. типы в стандартной библиотеке? Я вот не пойму, в чем проблема-то? Свою задачу предотвращения гонок и защиты от пересылки не шарящихся между потоками объектов — Rust решает, и в практике многопоточного программирования это серьезно помогает.
Нет, просто у вас предельно консервативная позиция, вы не видите и не хотите видеть реальных перспектив, которые дают новые языки. Они, кстати говоря, не на ровном месте появились, а в процессе решения тех или иных проблем старых языков. Вы же — просто закостенели, вы боитесь, что скоро придется значительную часть своего опыта просто выкинуть — а ведь так хорошо живется "старым жиром"! Я это говорю без осуждения, знаю по себе, как неприятно расставаться со своим "багажом" и снова "садиться за парту". Но еще хуже — постоянно мучиться проблемами C++ и Java (которые я использовал для своих проектов и от "особенностей" которых я просто устал). Так что теперь совсем не жалею, что проделел эту процедуру — это пошло на пользу и делу, и мне, как разработчику.
Единственный серьезный недостаток у Rust сегодня — это некоторая сырость самого языка и его экосистемы. Но эта проблема решается популярностью и временем.
Rust — это очень передовой язык по многим технологическим аспектам инженерии ПО. Да, у него есть недостатки, да — он не идеален. Но пока — это лучшее, что есть для разработки больших, требовательных к производительности программных систем. Вам этого не надо? Не используйте Rust. Вы хотите что-то проверенное временем? Берите тот же COBOL. Но не надо очернять новый язык ни написав на нем ни одной сколь-либо значимой строчки: как бы вы не боролись с прогрессом, рано или поздно такая борьба приведет вас к неудачам.
Я уже приводил вам пример, как в Rust шарить неизменяемую ссылку на статический объект между потоками. А если ваш ресурс изменяемый — то логично, что в 90% случаев он должен быть защищен примитивом синхронизации. Остальное — это unsafe, оно такое в расте и есть.
Однако, я скорее согласен с критикой Дейкстры и считаю, что язык программирования не должен быть близким к естественному языку — у него другая задача.
А то, что COBOL до сих пор так широко используется… Тут нужно отдельно исследовать этот феномен, но видится мне, что просто синтаксис в распространении ЯП играет далеко не самую главную роль, как бы ни казалось обратное при поверхностном взгляде.
ну так я и говорю — почему бы не писать чисто на спец. символах?
Потому что язык не состоит только из структурных разделителей. Если это не Lisp, конечно )
Если использовать только спецсимволы — то что они будут разделять? В таком языке легко будут отделяться только пользовательские имена, заданные в виде слов, от остальных спецсимволов. Использовать ключевые слова для различных встроенных команд — это прекрасно, но не надо требовать писать словами разделители и границы структурных блоков, воспринимать такой код будет труднее и медленнее.
Задача как-раз в том, чтобы найти баланс использования спецсимволов, ключевых слов и пользовательских идентификаторов (которые обычно всегда слова) с тем, чтобы улучшить восприятие кода и сократить его набор.
Вы же это прочитали? Так зачем опять сводите ситуацию к абсурду и продолжаете демагогию?
Дело в том, что подобный цикл
Развернется в следующий код:
На первом этапе нужно хотя бы сообразить, что вам нужна именно абстракция, а уже потом решать, какая хорошая, какая — нет. Я вижу именно это начальное суждение в данном заголовке, потому что не для всех очевидно, что со сложностью нужно бороться с помоцью абстракции.
Дело в том, что основное преимущество использования классов стилей — это создание высокоуровневых абстракций и сокрытие их реализации. Вам не надо знать, какого размера или цвета кнопка, если она по смыслу использования "btn-primary" — такой класс и используете. А уж какой там конкретно стиль "под капотом" — не суть важно.
Это будет проще.
Вы просто интерпретируете суждение как "всякая абстракция — ключ", но квантора всеобщности там нет.
Правильные абстракции — это прежде всего абстракции. Так что подмены тут нет.
Неплохо отмазались )
Как будто что-то плохое )
Нужно создать новые типы, а не просто добавить алиасы имен. Вот в этой статье хорошо написано, что нужно делать: Передача намерений.
Самое элементарное: оберните инты в классы, чтобы добиться контроля типов со стороны компилятора, и посмотрите, что произойдет с производительностью вашей программы. В моем случае она падала почти на порядок.
А почему должен? Этот метод достает из Option значение или приводит к панике, если там оказался None. Если вы в своем коде позвали этот метод, то наверное вы сознательно это сделали? О чем тут компилятор должен предупреждать? Если бы вызов unwrap считался ошибкой, то такого бы метода просто не было.
Хах, Rust уже становится законодателем мод? )
Слишком сложная многопоточность, вечные NPE, необходимость иметь под рукой эксперта по тюнингу JVM, если не хочешь принудительно перезапускаться раз в месяц, непредсказуемые моменты сборки мусора и освобождения ресурсов, нарастающие тормоза при попытке писать выразительный высокоуровневый код.
Ну и сам язык развивается путем накручивания костылей сверху, яркий пример — система модулей. Появляется куча нюансов, которые нужно знать и учитывать, как только ты чуть сворачиваешь в сторону от написания типового шаблонного кода. Простой и лаконичной Java я бы не назвал, во многих аспектах она сложнее, чем Rust.
А ворнинги компилятора вам на что даны? Компилируйте с
И будут вам ошибки компиляции, вместо ворнингов. В таком случае проигнорировать Result не получится.
А чего вы ожидали? Встроенную синхронизацию в сам язык, а не спец. типы в стандартной библиотеке? Я вот не пойму, в чем проблема-то? Свою задачу предотвращения гонок и защиты от пересылки не шарящихся между потоками объектов — Rust решает, и в практике многопоточного программирования это серьезно помогает.
Уже писал тут: https://habr.com/ru/post/504622/
в разделе "Бесплатные абстракции".
Нет, просто у вас предельно консервативная позиция, вы не видите и не хотите видеть реальных перспектив, которые дают новые языки. Они, кстати говоря, не на ровном месте появились, а в процессе решения тех или иных проблем старых языков. Вы же — просто закостенели, вы боитесь, что скоро придется значительную часть своего опыта просто выкинуть — а ведь так хорошо живется "старым жиром"! Я это говорю без осуждения, знаю по себе, как неприятно расставаться со своим "багажом" и снова "садиться за парту". Но еще хуже — постоянно мучиться проблемами C++ и Java (которые я использовал для своих проектов и от "особенностей" которых я просто устал). Так что теперь совсем не жалею, что проделел эту процедуру — это пошло на пользу и делу, и мне, как разработчику.
Единственный серьезный недостаток у Rust сегодня — это некоторая сырость самого языка и его экосистемы. Но эта проблема решается популярностью и временем.
Rust — это очень передовой язык по многим технологическим аспектам инженерии ПО. Да, у него есть недостатки, да — он не идеален. Но пока — это лучшее, что есть для разработки больших, требовательных к производительности программных систем. Вам этого не надо? Не используйте Rust. Вы хотите что-то проверенное временем? Берите тот же COBOL. Но не надо очернять новый язык ни написав на нем ни одной сколь-либо значимой строчки: как бы вы не боролись с прогрессом, рано или поздно такая борьба приведет вас к неудачам.
Я уже приводил вам пример, как в Rust шарить неизменяемую ссылку на статический объект между потоками. А если ваш ресурс изменяемый — то логично, что в 90% случаев он должен быть защищен примитивом синхронизации. Остальное — это unsafe, оно такое в расте и есть.
Так что сдается мне, что бредите тут все-таки вы.
Конечно. Попробуйте-ка вместо примитивных типов в Java использовать на каждый чих классы — и вы сами это поймете.
Однако, я скорее согласен с критикой Дейкстры и считаю, что язык программирования не должен быть близким к естественному языку — у него другая задача.
А то, что COBOL до сих пор так широко используется… Тут нужно отдельно исследовать этот феномен, но видится мне, что просто синтаксис в распространении ЯП играет далеко не самую главную роль, как бы ни казалось обратное при поверхностном взгляде.
Потому что язык не состоит только из структурных разделителей. Если это не Lisp, конечно )
Если использовать только спецсимволы — то что они будут разделять? В таком языке легко будут отделяться только пользовательские имена, заданные в виде слов, от остальных спецсимволов. Использовать ключевые слова для различных встроенных команд — это прекрасно, но не надо требовать писать словами разделители и границы структурных блоков, воспринимать такой код будет труднее и медленнее.
Вы же это прочитали? Так зачем опять сводите ситуацию к абсурду и продолжаете демагогию?