LINUX.ORG.RU

Rust 1.91.0

 ,


0

5

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

Список изменений:

  • aarch64-pc-windows-msvc теперь является платфомой первого уровня поддержки (ранее было второго уровня). По сравнению со вторым уровнем поддержки, первый уровень подразумевает обязательное успешное прохождения всех тестовых наборов на платформе.

  • Добавлена проверка линтера при возвращении из функции «висячего» указателя. Встроенный в компилятор Borrow Checker уже имеет проверку на тот случай, когда возвращается «висячая» ссылка, но это не работало при использовании сырых указателей. Теперь будет сгенерировано предупреждение:

fn f() -> *const u8 {
    let x = 0;
    &x
}
warning: a dangling pointer will be produced because the local variable `x` will be dropped
 --> src/lib.rs:3:5
  |
1 | fn f() -> *const u8 {
  |           --------- return type of the function is `*const u8`
2 |     let x = 0;
  |         - `x` is part the function and will be dropped at the end of the function
3 |     &x
  |     ^^
  |
  = note: pointers do not have a lifetime; after returning, the `u8` will be deallocated
    at the end of the function because nothing is referencing it as far as the type system is
    concerned
  = note: `#[warn(dangling_pointers_from_locals)]` on by default

В разряд стабильного API было переведено:

  • Path::file_prefix
  • AtomicPtr::fetch_ptr_add
  • AtomicPtr::fetch_ptr_sub
  • AtomicPtr::fetch_byte_add
  • AtomicPtr::fetch_byte_sub
  • AtomicPtr::fetch_or
  • AtomicPtr::fetch_and
  • AtomicPtr::fetch_xor
  • {integer}::strict_add
  • {integer}::strict_sub
  • {integer}::strict_mul
  • {integer}::strict_div
  • {integer}::strict_div_euclid
  • {integer}::strict_rem
  • {integer}::strict_rem_euclid
  • {integer}::strict_neg
  • {integer}::strict_shl
  • {integer}::strict_shr
  • {integer}::strict_pow
  • i{N}::strict_add_unsigned
  • i{N}::strict_sub_unsigned
  • i{N}::strict_abs
  • u{N}::strict_add_signed
  • u{N}::strict_sub_signed
  • PanicHookInfo::payload_as_str
  • core::iter::chain
  • u{N}::checked_signed_diff
  • core::array::repeat
  • PathBuf::add_extension
  • PathBuf::with_added_extension
  • Duration::from_mins
  • Duration::from_hours
  • impl PartialEq<str> for PathBuf
  • impl PartialEq<String> for PathBuf
  • impl PartialEq<str> for Path
  • impl PartialEq<String> for Path
  • impl PartialEq<PathBuf> for String
  • impl PartialEq<Path> for String
  • impl PartialEq<PathBuf> for str
  • impl PartialEq<Path> for str
  • Ipv4Addr::from_octets
  • Ipv6Addr::from_octets
  • Ipv6Addr::from_segments
  • impl<T> Default for Pin<Box<T>> where Box<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Rc<T>> where Rc<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Arc<T>> where Arc<T>: Default, T: ?Sized
  • Cell::as_array_of_cells
  • u{N}::carrying_add
  • u{N}::borrowing_sub
  • u{N}::carrying_mul
  • u{N}::carrying_mul_add
  • BTreeMap::extract_if
  • BTreeSet::extract_if
  • impl Debug for windows::ffi::EncodeWide<'_>
  • str::ceil_char_boundary
  • str::floor_char_boundary
  • impl Sum for Saturating<u{N}>
  • impl Sum<&Self> for Saturating<u{N}>
  • impl Product for Saturating<u{N}>
  • impl Product<&Self> for Saturating<u{N}>

Признак const добавлен к следующим функциям:

  • <[T; N]>::each_ref
  • <[T; N]>::each_mut
  • OsString::new
  • PathBuf::new
  • TypeId::of
  • ptr::with_exposed_provenance
  • ptr::with_exposed_provenance_mut

>>> Подробнее

★★★

Проверено: hobbit ()
Последнее исправление: Wizard_ (всего исправлений: 2)
Ответ на: комментарий от mittorn

Все языки с пакетными менеджерами превращаются в неконтроллируемую блоатварь. npm, cargo, pip - везде одна и та же проблема.

Если в rust нужен sha — качаешь пакет с sha. Если такое же нужно в C, качаешь весь openssl. Кажется что первое лучше.

У питона вообще в стандартой библиотеке столько всего, что он просто не имеет права иметь пакетный менеджер

Но имеет же. pip и venv это база для питоновой разработки.

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

Да вот попробовал, если использовать оператор «as», narrowing conversion из float в int происходит без всяких паник.

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

rust без cargo бы не собрал столько хейта

Хренасдва. Во всех срачиках по поводу Раста, про cargo вспоминают в последнюю очередь.

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

Из референса раста:

Integer operators will panic when they overflow when compiled in debug mode. The -C debug-assertions and -C overflow-checks compiler flags can be used to control this more directly.

Более разумное поведение. Потому что если у вас переполнение, одно из трёх:

  1. вы не проверили граничные условия до операции и не вернули ошибку;

  2. вы не используете saturated арифметику;

  3. вы не подумали о выборе правильного диапазона и правильного типа.

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

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

CMake, безусловно, отвратителен; я бы даже сказал, что CMake даже много хуже Cargo (в отрыве от crates.io). Банально, CMake — клинический пример bloatware: у меня gcc быстрее компилируется, чем это канализационно‐инженерное чудо. Не знаю, что там по числу строк кода, но сейчас пошёл и скачал тарболы с исходниками: ≈6 Мб у Cargo, ≈22 Мб — у CMake.

Вот только к CMake не прилагается де‐факто стандартный репозиторий‐помойка. Имел опыт сборки некоторых особо «удачных» в плане dependency‐гигиены Rust‐проектов; ощущения те же, что и от таких же «удачных» проектов на JS, Python или даже Haskell.

Немного упрощает ситуацию с CMake тот факт, что зачастую многие вещи есть в репозитории (в виде dev‐пакетов в Debian’е, например) операционной системы (это же в редких случаях может спасти от взаимодействия с pip, в том же Debian’е полно Python‐пакетов). Всё вместе это даёт возможность в ряде случаев «соскочить» с CMake (или любой другой потрясающей системы сборки). Если это крупный уже существующий проект, то шансы, конечно, стремятся к нулю, но в случае собственного небольшого или даже среднего проекта либо в случае стороннего небольшого проекта шансы определённо ненулевые (сам имею опыт выкидывания CMake после форка).

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

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

везде использовать FetchContent скоро будет не лучше

Потихоньку пилят «убийцу» CMake https://build2.org. :)

build2 | C/C++ Build Toolchain

build2 is an open source (MIT), cross-platform build toolchain that aims to approximate Rust Cargo’s convenience for developing and packaging C/C++ projects while providing more depth and flexibility, especially in the build system.

build2 is a hierarchy of tools consisting of a general-purpose build system, package manager (for package consumption), and project manager (for project development). While the ultimate goal is a universal build toolchain, the current focus is on C/C++ (which is the foundation of every software stack in use today) as well as mixed-language projects involving one of these languages (see bash and rust, for example).

Key features:

  • Integrated build toolchain designed from first principles.
  • Covers entire project lifecycle: creation, development, testing, and delivery.
  • Aims to rebuild the entire C/C++ software ecosystem from the ground up.
  • Uniform and consistent interface across all platforms and compilers.
  • Fast, multi-threaded build system with parallel building and testing.
  • First-class Windows support, including portable build recipes.
  • Archive and version control-based package repositories.
  • Dependency-free, all you need is a C++ compiler.
dataman ★★★★★
()
Ответ на: комментарий от BerlinFall

В python я обычно бандлю нужные модули прямо внутрь проекта. Если они без нативной части - это обычно делается простым копированием в проект, если с нативной - придётся повозитться. Но я в целом не разрабатываю чего-то сложного на python, потому это обычно не требуется - всё же это язык для скриптов
Касательно же C/C++ - обычно использую либо single-header библиотеки, либо те, которые обычно можно найти во всех дистрах (libjpeg, libpng, libz)
Ну и у cmake есть одно положительное свойство: если нужна библиотека на cmake, можно включить её сабмодулем и проинклудить в проект, для небольших библиотек это обычно проблем не создаёт, собираться всё будет в единое целое, с одинаковыми флагами - это очень удобно для сборки portable софта.

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

Ну и да, стоит отметить, что всё описанное касается только текущей ситуации. Как отметил @mittorn чуть‐чуть выше, возможно, в будущем под давлением общих тенденций тучи над CMake сгустятся и к нему станет прилагаться полуобязательный репозиторий. От безумных разработчиков CMake вообще стоит ожидать чего угодно, вплоть до бинарных блобов в самых неожиданных местах. И наоборот, с повсеместным внедрением Rust стоит ожидать упрощение ситуации вокруг Cargo, поскольку вполне вероятно, что наиболее часто используемые Rust‐библиотеки пролезут в репозитории популярных дистрибутивов.

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

Все реально полезные проекты на Питоне, которыми я пользовался, используют venv в том или ином виде. У тебя есть примеры обратного?

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

Страшно представить, что из себя будет представлять C++ с прямыми аналогами Cargo и crates.io. Особенно если всеми любимый комитет по этому поводу решит что‐нибудь вписать в стандарт.

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

Мои мелкие скрипты никакого venv не требуют
waf не то, что не требует venv, а даже не работает с ним (потому что venv - кривое говно кривого говна):
https://gitlab.com/ita1024/waf/-/issues/2420
качалки с дизера не требуют venv
Когда делал бота для дискорда, никакого venv не требовалось
Единственное, где я видел venv, это legacy mozbuild, котоырй давно пора выкинуть целиком. Мало того, этот venv там сломан, из-за чего я не смог собрать браузер под x32 abi
В общем всё говорит о том, что за venv по хорошему надо руки отрывать

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

В «C++ с прямыми аналогами Cargo и crates.io» я имел в виду, конечно, что эти воображаемые прямые аналоги будут фактическим стандартом, как сейчас CMake. А так‐то чего только нет, конечно.

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

Думаю, сильно ничегоне поменяется, для сорвеменного c++ и с STL назад пути уж нет, только гроб гроб кладбище std::
Но никто не запрещает писать код без этого всего

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

К сожалению как и с initializer list сделали бесполезное STL-зависимое говно.
Вообще, после c++17 было очень мало полезных нововведений и возможно, уже и не будет

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

scapy

Не пользовался. и что за такие непотребства оно творит, что ему нужен venv? Срёт в venv рандомными библиотеками из интернета? Если да, то нафиг

NetBox is the leading solution блаблабла

Уже пахнет каким-то буллщитом, дальше читать не хочется.

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

Вообще, после c++17 было очень мало полезных нововведений и возможно, уже и не будет

В голову сразу приходят ренжи, концепты, st::format, многомерный operator[] и std::mdspan. Это из того что я часто использовал и стало приятнее работать

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

если всеми любимый комитет по этому поводу решит что‐нибудь вписать в стандарт

Комитет над этим уже много лет работает (и правильно делает). Впрочем, успехи слабые.

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

Вот есть egui, просто собираете с musl и оно сцуко работает на любом линуксе от ядра 3.0.

А теперь прикиньте сколько надо будет потратить сил с другими фреймворками?

Ну т.е. для начала вам надо будет все зависимости собрать с давно протухшим glibc.

steemandlinux ★★★★★
()

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

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

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

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

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

К примеру, если взять Java, то через runtime reflection программа может обращаться к любому классу любой библиотеки. Поэтому сборщик программы, строго говоря, не может выкинуть вообще ничего, т.к. невозможно заранее предсказать, к чему программа может в будущем обратиться. Это пример дизайна языка, который абсолютно не подходит для подобной оптимизации.

Как я себе это вижу.

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

Ты импортировал функцию и использовал её в программе - при сборке скачался ровно один файл со скомпилированной функцией. После чего скачались файлы с функциями, которые этой функцией используются. Причём должны быть сразу использованы constant propagation. Т.е. когда ты вызываешь функцию с константными значениями, текст этой функции анализируется с учётом этих значений и скачиваются только те зависимости, которые достижимы с учётом этих константных значений, а не все подряд. И вот этот пункт про constant propagation очень важен, на самом деле. Т.к. часто библиотеки такие амбальные именно из-за попытки сделать универсальный интерфейс для всех на свете, а конкретному программисту нужно лишь подмножество этого интерфейса.

И, конечно, это всё должно быть эффективно, не 100500 HTTP запросов, а как-то более умно.

Плюс при разработке должен быть простой способ оценивать объём конкретной функции с её зависимостями. Чтобы программист сразу видел, сколько байтов он добавил, импортировав эту функцию.

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

Но проблема в том, что это никому не надо. Современный модный молодёжный редактор Zed компилируется в 1.5-гигабайтный бинарник, который после strip уменьшается до 400 MB и это никого особенно не напрягает. Поэтому вряд ли это всё когда-либо случится.

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

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

Ну-ну. Освобождает…

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

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

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

А теперь размножить на 8, 16 и т.д. потоков (Ryzen 7 уже не редкость). Построить график зависимости работы от числа ядер.

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

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

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

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

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

format

Идея может и нормальная, но реализация такая, что декомпил лучше читается, чем код (литералли пришлось смотреть декомпил, чтобы понять, как оно работает)

многомерный operator[]

Фактически, сахар, хотя ничего против этой фичи не имею, полезно

std::mdspan

там есть что-то, что проблемно реализовать самому?
Касательно STLовых фич я бы выделил вот это:
https://habr.com/ru/companies/otus/articles/520502/
Думал, что в 20м, но оказалось в 17. Получается, и правда ничего реальоно полезного больше не было

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

Мы про инновации Rust в области управления памятью. И они простираются дальше примитивных синтаксических фич, которые были в древнем Objective C и тривиально реализуются в C++.

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

Мы про инновации Rust в области управления памятью. И они простираются дальше примитивных синтаксических фич, которые были в древнем Objective C и тривиально реализуются в C++.

В области управления памяти в Rust нет вообще ничего нового, там все те же scope’ы и RC.

tinykey
()

u{N}::carrying_mul

мне кажется этот термин не политкорректен.

Унижает бедных животных и причисляющих себя к ним лиц. Напоминает о рабстве и тяжёлом труде

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

Да, чего-то такого не хватает. Ещё из неприятных эффектов таких крупных библиотек - долгая релокация, если это shared, ну и долгая сборка разумеется
У меня старый radv, который не поддерживает рейтрейсинг грузится на холодную примерно на 300мс быстрее, чем актуальный, хотя из vulkan приложений все эти acceleration structure нужны может одной десятой процента. Ещё все эти acceleration structure при работе с кодом мешаются в автокомплите (буква а между прочим) и заставляют IDE тормозить на слабых машинах (там много типов)...
А драйвера vulkan intel чтобы скомпилировать шейдеры для рейтрейсинга вообще llvm требуют (нужен для компиляции .cl), разрабы mesa ничего с этим делать не собираются.
А вроде когда-то в gles драйверах были даже функции, выгружающие компилятор шейдеров, когда он больше не нужен...

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

В своём проекте я могу запретить контриьютить код с STL, либо не работающий с -fno-threadsafe-statics если захочу

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

Если ты про move семантику, то в c++ она ужасна, хотя я до сих пор не уверен, что rust с его постоянной передачей владения лучше

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

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

Всякие примитивные типы, типа bool или u32 же всегда копируются, а не перемещаются и тебе не нужно на них вызывать метод clone(). Это потому что они уже реализуют трейт Copy. Ты можешь и для своих типов данных сделать такое же поведение.

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

Если в rust нужен sha — качаешь пакет с sha.

А с ним еще тонну зависимостей типа какой нибудь rust-crypto итд итп.

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

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

Если в rust нужен sha — качаешь пакет с sha.

А с ним еще тонну зависимостей типа какой нибудь rust-crypto итд итп.

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

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

А с ним еще тонну зависимостей типа какой нибудь rust-crypto итд итп.

rust-crypto это зонтичный проект, рпзбитый на маленькие крейты.

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

И это ОГРОМНАЯ проблема инфраструктуры C.

Кросс-компиляция в Go: GOOS=linux GOARCH=arm64 go build. Адок который нужен пропрыгать с тулчейном, libc, библиотеками и вечно ломающимся crosstool-ng для сишки даже вспоминать не хочется.

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