LINUX.ORG.RU

Rust 1.31.0 (2018)

 , rust2018


5

10

Команда Rust объявила о выходе новой стабильной версии Rust 1.31.0, который ознаменует собой также выход новой редакции «Rust 2018». Rust — это язык программирования, который позволяет каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust, обновиться до Rust 1.31.0 проще всего следующим образом:

rustup update stable

Если у вас ещё не установлен Rust, то это можно сделать, загрузив с сайта утилиту rustup.

Что нового в Rust 1.31.0

Rust 2018

Данный релиз ознаменует собой выпуск редакции Rust 2018. Впервые Rust 2018 был упомянут в марте, затем в июле: прочтите их, чтобы понимать для чего нужен Rust 2018. Также, есть статья на сайте Mozilla Hacks.

Вкратце, Rust 2018 это возможность представить всю работу за последние три года в виде цельного пакета. Кроме возможностей языка, сюда входят:

  • Инструментарий (поддержка IDE, rustfmt, Clippy)
  • Документация
  • Работа различных рабочих групп
  • Новый веб-сайт

Для обозначения редакций Rust был представлен ключ edition в Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"

[dependencies]

Значение 2018 означает, что используется редакция Rust 2018; отсутствие ключа или значение 2015 означает использование редакции Rust 2015.

Важно отметить, что каждый пакет может быть в редакциях 2015 или 2018, и они без проблем могут работать вместе. Проект под редакцией 2018 может использовать зависимости 2015, а проект 2015 использовать зависимости 2018. Это гарантирует целостность экосистемы, сохраняя совместимость существующего кода. Кроме того, существует возможность автоматической миграции кода с редакции Rust 2015 на Rust 2018 при помощи cargo fix.

Non-lexical lifetimes (NLL; Нелексические времена жизни)

В 2018 появились нелексические времена жизни, что на простом языке означает, что проверщик заимствований (borrow checker) стал умнее и теперь не отклоняет правильный код. Например:

fn main() {
    let mut x = 5;

    let y = &x;

    let z = &mut x;
}

В старых версиях этот код выдаст ошибку компиляции:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
6 | }
  | - immutable borrow ends here

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

Другой пример:

fn main() {
    let mut x = 5;
    let y = &x;
    let z = &mut x;
    
    println!("y: {}", y);
}

Старый Rust выдаст следующую ошибку:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
...
8 | }
  | - immutable borrow ends here

В Rust 2018 вывод ошибки стал лучше:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:13
  |
4 |     let y = &x;
  |             -- immutable borrow occurs here
5 |     let z = &mut x;
  |             ^^^^^^ mutable borrow occurs here
6 |     
7 |     println!("y: {}", y);
  |                       - borrow later used here

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

Пока эти возможности доступны в Rust 2018, но в будущем планируется портировать их на Rust 2015.

Изменения в системе модулей

Редакция Rust 2018 привносит некоторые изменения в работу с путями, что в конечном итоге привело к упрощению системы модулей.

Вкратце:

  • extern crate больше не требуется практически во всех случаях.
  • Макросы теперь можно импортировать при помощи use вместо атрибута #[macro_use].
  • Абсолютные пути начинаются с названия пакета, где ключевое слово crate ссылается на текущий пакет.
  • foo.rs и поддиректория foo/ могут сосуществовать вместе; mod.rs больше не нужен при размещении подмодулей в поддиректории.

Полную информацию можно прочесть в руководстве.

Упрощенные правила синтаксиса времени жизни

В обеих редакциях представлены новые правила синтаксиса времени жизни для блоков impl и определениях функций. Следующий код:

impl<'a> Reader for BufReader<'a> {
    // methods go here
}
теперь может быть написан таким образом:
impl Reader for BufReader<'_> {
    // methods go here
}

'_ подсказывает, что BufReader берёт параметр, но больше нет необходимости именовать его.

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

// Rust 2015
struct Ref<'a, T: 'a> {
    field: &'a T
}

// Rust 2018
struct Ref<'a, T> {
    field: &'a T
}
: 'a добавляется автоматически. При желании, можно продолжать использовать явное определение.

const fn

Существует несколько способов определения функций в Rust: регулярная функция с fn, небезопасная функция с unsafe fn, внешняя функция с extern fn. В этом релизе появился ещё один способ: const fn, который выглядит следующим образом:

const fn foo(x: i32) -> i32 {
    x + 1
}
Функции const fn могут вызываться как регулярные функции, но вычисляются во время компиляции, а не во время выполнения. Для стабильной работы, они должны иметь детерминированный результат и в настоящее время ограничены следующим минимальным набором операций:

  • Арифметические операторы и операторы сравнения с целыми числами
  • Все логические операторы, кроме && и ||
  • Построение массивов, структур, перечислений и кортежей
  • Вызов других функций const fn
  • Задание индекса массивам и срезам
  • Доступ к полям структур и кортежей
  • Чтение из констант
  • & и * на ссылках
  • Приведение типов, за исключением необработанных указателей на целые числа

В будущем данный набор будет расширяться, подробную информацию можно посмотреть здесь.

Новые инструменты

Наряду с Cargo, Rustdoc, и Rustup, которые являются ключевыми инструментами с версии 1.0, редакция 2018 представляет новое поколение инструментов: Clippy, Rustfmt, и поддержку IDE.

Clippy является статическим анализатором кода в Rust, достиг версии 1.0 и теперь доступен в стабильной версии Rust. Установку можно произвести следующим образом: rustup component add clippy, запуск: cargo clippy.

Rustfmt является инструментом для автоматического форматирования кода Rust в соответствии с официальной стилистикой Rust. В этом релизе он достиг версии 1.0 и, начиная с этой версии, гарантируется обратная совместимость для Rustfmt: отформатированный сегодня код останется неизменным в будущем (только с опциями использованными по-умолчанию), и несёт практическую ценность при использовании с системами непрерывной интеграции (CI; cargo fmt --check). Установить Rustfmt можно следующим образом: rustup component add rustfmt, использовать: cargo fmt.

Поддержка IDE - одна из наиболее востребованных возможностей в Rust. Работы над поддержкой IDE ещё не закончены, но на данный момент уже существуют несколько высококачественных опций:

Tool lints

В Rust 1.30 были стабилизированы атрибуты инструментов, такие как #[rustfmt::skip]. В Rust 1.31 стабилизированы «анализаторы инструментов» («tool lints») наподобие #[allow(clippy::bool_comparison)], у них появилось своё пространство имён и теперь ясно к какому инструменту они относятся. Старые проверки Clippy теперь можно писать следующим образом, вам больше не нужен атрибут cfg_attr:

// old
#![cfg_attr(clippy, bool_comparison)]

// new
#![allow(clippy::bool_comparison)]

Документация

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

Рабочие группы

В этом году было объявлено о создании четырёх рабочих групп в следующих областях:

  • Сетевые сервисы
  • Приложения командной строки
  • WebAssembly
  • Встраиваемые устройства

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

  • Группа сетевых сервисов работает над интерфейсом Futures и async/await, который уже будет доступен в скором времени.
  • Группа командной строки работает над библиотеками и документацией для создания ещё лучших приложений для командной строки.
  • Группа WebAssembly выпустила огромное количество инструментария для использования Rust с wasm.
  • Группа встраиваемых устройств добилась поддержки разработки ARM на стабильной версии Rust.

Новый сайт

Основной сайт получил новый дизайн.

Стабилизация библиотек

Добавлено множество реализаций From:

  • u8 теперь реализует From<NonZeroU8>, то же самое для других числовых типов и их NonZero-эквивалентов
  • Option<&T> реализует From<&Option<T>>, аналогично для &mut

Были стабилизированы следующие функции:

  • slice::align_to и её изменяемый аналог
  • slice::chunks_exact и её изменяемый и r аналоги (такие как slice::rchunks_exact_mut) во всех комбинациях

Подробный список изменений можно посмотреть здесь.

Cargo

Cargo теперь загружает пакеты параллельно, используя HTTP/2. В связи с тем, что extern crate практически больше не требуется, было бы неудобно использовать пакет через extern crate foo as bar; Это можно сделать в Cargo.toml следующим образом:

[dependencies]
baz = { version = "0.1", package = "foo" }

или

[dependencies.baz]
version = "0.1"
package = "foo"

В примере выше, пакет foo теперь может быть использован через baz.

Подробный список изменений можно посмотреть здесь.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Deleted (всего исправлений: 5)

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

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

Для того, чтобы уметь понимать ручное управление памятью, не нужно знать именно C. В каком-нибудь Pascal-е все тоже самое.

Адресная арифметика, например, в большинстве случаев — бесполезный атавизм. Но вот способность человека разобраться с тем, что такое указатель и что означает *(p+1) или **p является отличной лакмусовой бумажкой.

Те, кто не могут разобраться с *(p+1), как показывает мой опыт, программисты так себе. У них мозги как-то по другому работают.

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

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

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

Разве нет? Там же вроде был GIL или как его там, что бы гарантировать безопасность доступа к объектам. Хотя да, противоречие, GIL-а бы не было, если бы не было потоков. Извиняюсь.

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

Можно я вас исправлю s/методы/методологии/g, лады?

Как угодно.

А ну-ка просветите, это вы о какой аппаратной архитектуре речь ведете?

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

А главное, о какой аппаратной команде речь?

Речь, естественно, не об одной команде и даже не о командах вообще, а о том, как взаимодействуют команды, процессорные конвейеры и память: https://homes.cs.washington.edu/~bornholt/post/memory-models.html

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

Как вообще люди используют valgrind?

Как-то умудряемся.

Он же делает программу в 40 раз медленней, ничего серьезного под ним не запустишь.

Ты еще спроси, как люди пользуются программными эмуляторами процессоров, которых еще не существует в железе (или они тупо не доступны), а программы писать надо. И ничего - запускают в эмуляторах даже живые ОС.

Создают тестовую прграмму на каждый чих?

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

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

Еще не так давно человек, который не может разобраться с динамической памятью в C

Писал софт на тикле, пердле, жабе, лиспе и других языках. На сиське мир клином не сошелся же.

Язык С выдвигает серьезные требования к уровню разработчика.

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

Собсна, не работает это все, нет никаких си/кресто-гуру, не выдающих тонны косяков и cve, потому и придумали кресты, а потом раст (потому что без borrow checker жизнь не сильно лучше).

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

А, ну дак и GC ничего не гарантирует, мало ли там внизу ОС долбанулась и доступ к памяти через /dev/random осуществляет, используя адрес как seed. Всем кодить железо на VHDL пасаны, только так гарантируем корректность.

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

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

Первого тру сишник точно не скажет. А те, кто скажет - они ни разу не тру, гоните их, насмехайтесь на ними.

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

потому и придумали кресты

Кресты придумали не для этого.

Писал софт на тикле, пердле, жабе, лиспе и других языках.

Ну с таким говном в анамнезе понятно, откуда познания про причины появления крестов.

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

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

А теперь внимательно читайте статью, обратите внимание на термин sequential consistency и что он значит. И подумайте, свойство ли это аппаратной архитектуры или модели памяти языка. Когда решите, что это свойство аппаратуры, поищите про реализацию sequential consistency на таких прикольных архитектурах как ARM, IBM PowerPC и Dec Alpha. Особо пристальное внимание обратите на IBM PowerPC.

И еще: где там хоть слово про mutex-ы? Самое время потереть/поправить предыдущие ваши комментарии ;-)

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

поищите про реализацию sequential consistency на таких прикольных архитектурах как ARM, IBM PowerPC и Dec Alpha. Особо пристальное внимание обратите на IBM PowerPC.

И еще: где там хоть слово про mutex-ы? Самое время потереть/поправить предыдущие ваши комментарии ;-)

А почему ты искал там слова про мютексы? Я же ясно написал:

tailgunner> Я не веду речи об аппаратной архитектуре. Я веду речь о том, что разумные методы программирования (или, скорее, методы кодирования) скрывают детали аппаратных архитектур

Самое время потереть/поправить предыдущие ваши комментарии ;-)

Да нет, всё нормально.

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

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

https://www.quora.com/Why-did-Bjarne-Stroustrup-create-C

https://bigthink.com/videos/why-i-created-c

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

Я не искал там ничего, ибо прекрасно осведомлен о том что такое модель памяти и что такое sequential consistency.

А почему ты искал там слова про мютексы?
Да нет, всё нормально.

Вот по этому: Rust 1.31.0 (2018) (комментарий)

Извините конечно, но у вас какой-то не последовательный поток сознания.

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

А вот язык Rust эти требования снижает.

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

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

Этот кто-то не сможет написать 3D-движок или сервер, потому что не знает, как компьютер работает. А если знает, то единственное отличие будет в том, что код использует не циклы со счетчиком, а итераторы. И наоборот, умение пользоваться malloc не поможет написать быстрый diff, не зная алгоритмов. Просто есть небольшой шанс, что где-нибудь забудешь прибавить единичку, на этом отличия заканчиваются.

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

Бъерн сам в интервью говорил, что хотел, чтоб было как в симула

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

Это Rust создавали, чтобы устранить проблемы языков C и C++.

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

/trolling-mode: on Не понял. Вы утверждаете, что раст — быстрая и беспроблемная Симула? /lrolling-mode: off

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

А вот язык Rust эти требования снижает.

Написать программу которая хотя бы просто скомпилируется на Расте сложнее, чем на С.

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

Самое время потереть/поправить предыдущие ваши комментарии ;-)

Да нет, всё нормально.

Вот по этому: Rust 1.31.0 (2018)
Извините конечно, но у вас какой-то не последовательный поток сознания.

То, что пост кажется непоследовательным одному анонимусу (да хотя бы и не одному) - не повод что-то удалять.

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

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

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

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

К примеру (вымышленная история): раньше, когда я писал на С++, часто допускал такую ошибку, когда хранил ссылки на элементы контейнера, но не следил за его временем жизни. Из-за этого программа могла упасть (доступ по весящей ссылке и все-такое). Когда попробовал Раст, оказалось что он препятствует такого рода ошибкам на стадии компиляции, потому что информация об областях видимости закодирована в его типах.

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

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

И крики о небезопасном С++ для них звучат как-то не так.

Это вы про тех неадекватов, что рассказывают про безопасный C++11?

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

Ниша Раста еще не определена

Это так. Но, что радует, пихают его во все ниши, в которые еcть. Это как минимум повышает шансы на взлет.

а такое поведение, как у ЛОР-овских Раст-фанбоев, только вредит.

Не думаю. Как минимум это способствует известности.

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

Просто для протокола: я не спорил об аппаратных моделях памяти. Я сказал, что для написания корректных программ поверх этих моделей, можно использовать определенные методы (или, скорее, техники) кодирования, которые форсятся Rust.

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

Я с трудом представляю, как можно пользоваться Си++ хотя бы лет 15 и не знать, что он небезопасен. Даже в «современном Си++», где ехал shared_ptr через unique_ptr, всякое бывает.

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

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

Теперь пройдемся по вашей реплике. Во-первых, почему именно 11-я редакция языка? Во-вторых кто рассказывал вам лично про С++ безопасный в плане памяти? В третьих, вы искренне считаете что Раст безопасен в плане памяти?

Давайте-ка я вам поясню: если вы будете придерживаться современных парадигм в С++, будете использовать санитайзеры, будете слушать советы старших и опытных коллег на код-ревью, то ваш код будет безопасным. Язык нет, но код — да. Теперь внимание: в Раст есть возможность точно так же выстрелить себе в -яйца- ногу. Имя её unsafe. Она делает из «безопасного» Раста опасный. Если вы с этим не согласны, то мне не о чем с вами говорить. Задумайтесь-ка, зачем в безопасный раст добавлять такой опасный инструмент?

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

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

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

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

И? Ты сам недавно написал следующее:

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

Если это не утверждение «Си++ безопасен», то что это?

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

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

Я пояснил (перейдите по ссылке), что любой язык системного уровня так или иначе не безопасен. Безопасным должен быть написанный на этом языке код. То, что вы тут криво лоббируете, должно звучать как «на Раст легче писать memory-safe код», а не «Раст безопасный язык». С такой формулировкой я согласен. Но при этом вы можете писать memory-safe код и на С++.

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

Говоря о уязвимостях, не забывай — эксплуатация memory corruption уязвимостей практически мертва.

Поиск уязвимостей в Си уже давно больше похож на поиск уязвимостей в коде на php — люди ищут логические уязвимости.

А для защиты от логических уязвимостей нужна максимальная прозрачность кода для понимания. Rust, пытаясь избежать memory corruption — упал в пучину языков, код которых читать затруднительно даже в случае его хорошего знания.

Таким образом, в современном мире — даже С++ может быть более предпочтительным для использования, чем Rust. Только за счёт лучшей читаемости кода.

И отмечу, что я под уязвимостью memory corruption понимаю не падение приложения (формально это уязвимость denial of service, но IRL она имеет очень малое значение — такое у тебя никто не купит), а перехват потока управления с последующим вызовом собственного кода.

Подобные вещи незнакомы устаревшим людям, но реальность такова.

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

Можете писать memory-safe код и на С++, вот только узнаете что допустили ошибку и он не memory-safe либо в рантайме(если повезёт), либо с https://nvd.nist.gov/.

Safe Rust гарантирует разрешение memory safety багов в компайл тайме. Чтобы понять почему использовать unsafe блоки всё же безопасней, чем писать код на C, обратитесь к Растномикону.

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

Вы уверены что вы старше меня?

Нет. Но если ты и старше меня, то ненамного. И кстати, я предпочитаю, чтобы ко мне тоже обращались на «ты».

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

Это игра в слова. При желании можно считать небезопасным всё - и любой ЯП, и любой сгенерированный код (и даже всю жизнь, да). Отличие Rust в том, что там на уровне языка (не рантайма, как в Яве/шарпе/whatever) приняты меры для того, чтобы он был безопасным, и он безопасен _по умолчанию_.

Но при этом вы можете писать memory-safe код и на С++

Конечно. Но писать memory-safe код можно и на ассемблере. Но ассемблер в этом не помогает примерно никак, а Си++ помогает нет так, чтобы сильно.

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

Говоря о уязвимостях, не забывай — эксплуатация memory corruption уязвимостей практически мертва.

Живее всех живых. ASLR и stack-canaries усложняют эксплуатирование, но не делают его невозможным.

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

Отличие Rust в том, что там на уровне языка ... приняты меры для того, чтобы он был безопасным, и он безопасен _по умолчанию_

Конечно, особенно когда идет вызов FFI в С/С++ или новичок на проекте пишет unsafe код. Уберите эти два механизма из Раста потом только утверждайте так громогласно что " он безопасен _по умолчанию_".

Нет. Но если ты и старше меня, то ненамного. И кстати, я предпочитаю, чтобы ко мне тоже обращались на «ты».

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

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

код которых читать затруднительно даже в случае его хорошего знания.

Но ведь у вас даже базового знания нет. Откуда вам знать как читается код в случае хорошего знания? Да, синтаксис сильно не привычен, сам привыкал около полугода, сейчас всё довольно просто. Даже проще чем C++, за счёт trait bounds и мув семантики по умолчанию а не костыля для обратной совместимости в виде r-value reference.

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

Говоря о уязвимостях, не забывай — эксплуатация memory corruption уязвимостей практически мертва.

я под уязвимостью memory corruption понимаю не падение приложения (формально это уязвимость denial of service, но IRL она имеет очень малое значение — такое у тебя никто не купит), а перехват потока управления с последующим вызовом собственного кода.

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

Поиск уязвимостей в Си уже давно больше похож на поиск уязвимостей в коде на php — люди ищут логические уязвимости.

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

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

Полностью согласен. Синтаксис не является чем-то запредельным. Читать код на Раст и приблизительно его понимать, ИМХО, может любой программист знакомый с С-derived языками.

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

Во-первых, почему именно 11-я редакция языка?

Спросите у неадекватов.

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

Ключевое слово если.

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

Потому, что он не идеален, и нужны способы срезать углы. И я молчу про FFI.

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

Нет. Большую часть проверок вы линтерами никак не докажите. По крайней мере ни одним из существующих.

Объясняю на пальцах: когда я собираю прогу, cargo собирает и все зависимости. И моя прога, и все её зависимости подчиняются одним и тем же правилам и ограничениям. Санитайзеры и прочий бред - опциональны, гарантии rust - нет.

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

Наглая ложь. Синтаксис rust ужасен, и это подтверждают почти все нормальные разработчики на rust, среди которых не так много фанатиков с ЛОРа.

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

Поиск уязвимостей в Си уже давно больше похож на поиск уязвимостей в коде на php — люди ищут логические уязвимости.

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

Нет: https://go.armis.com/hubfs/ExploitingBlueBorneLinuxBasedIoTDevices.pdf

Это опровергает мои слова или подтверждает их?

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

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

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

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

Тогда и нечего говорить про «мы сейчас мир защитим».

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

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

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

«upcoming release» намекает, что в следующем. Tokio и некоторые веб-фреймворки кажется уже всё умеют

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

Тогда и нечего говорить про «мы сейчас мир защитим».

Окей, я не буду этого говорить. Раньше не говорил, но и дальше тоже не буду.

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