LINUX.ORG.RU

Выпуск языка программирования Rust 1.47

 ,


2

8

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

Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.

Основные новшества:

  • Реализована поддержка типажей для массивов произвольного размера. Ранее, из-за невозможности определить generic-функции для всех целых значений, стандартная библиотека предоставляла встроенную поддержку типажей только для массивов, размер которых не превышал 32 элемента (типажи для каждого размера были определены статически). Благодаря созданию функциональности константных дженериков («const generics») появилась возможность определения generic-функций для любых размеров массива, но они пока не включены в состав стабильных возможностей языка, хотя реализованы в компиляторе и теперь задействованы в стандартной библиотеке для типажей массивов любого размера. Например, следующая конструкция в Rust 1.47 приведёт к выводу содержимого массива, хотя раньше привела бы к ошибке:
    fn main() {
        let xs = [0; 34];
        println!("{:?}", xs);
    }
  • Обеспечен вывод более коротких трассировок (backtrace), выводимых при внештатных ситуациях. Из трассировки исключены элементы, не представляющие интереса в большинстве ситуаций, но захламляющие вывод и отвлекающие внимание от первичных причин проблемы. Для возвращения полной трассировки можно использовать переменную окружения «RUST_BACKTRACE=full». Например, для кода
    fn main() {
        panic!();
    }

раньше выводилась трассировка в 23 этапа, а теперь она будет сведена к 3 этапам, позволяющим сразу уловить суть:

thread 'main' panicked at 'explicit panic', src/main.rs:2:5
    stack backtrace:
       0: std::panicking::begin_panic
                 at /rustc/d...d75a/library/std/src/panicking.rs:497
       1: playground::main
                 at ./src/main.rs:2
       2: core::ops::function::FnOnce::call_once
                 at /rustc/d...d75a/library/core/src/ops/function.rs:227
  • Компилятор rustc обновлён до сборки с использованием LLVM 11 (Rust использует LLVM в качестве бэкенда для генерации кода). При этом сохранена возможность сборки со старыми LLVM, вплоть до версии 8, но по умолчанию (в rust-lang/llvm-project) теперь используется LLVM 11. Релиз LLVM 11 ожидается в ближайшие дни.
  • На платформе Windows в компиляторе rustc обеспечена поддержка включения проверок целостности потока выполнения (Control Flow Guard), активируемых при помощи флага «-C control-flow-guard». На других платформах данный флаг пока игнорируется.
  • В разряд стабильных переведена новая порция API, в том числе стабилизированы Ident::new_raw, Range::is_empty, RangeInclusive::is_empty, Result::as_deref, Result::as_deref_mut, Vec::leak, pointer::offset_from, f32::TAU и f64::TAU.
  • Признак «const», определяющий возможность использования в любом контексте вместо констант, применён в методах:
    • new для всех целых, отличных от нуля;
    • checked_add, checked_sub, checked_mul,checked_neg, checked_shl, checked_shr, saturating_add, saturating_sub и saturating_mul для всех целых;
    • is_ascii_alphabetic, is_ascii_uppercase, is_ascii_lowercase, is_ascii_alphanumeric, is_ascii_digit, is_ascii_hexdigit, is_ascii_punctuation, is_ascii_graphic, is_ascii_whitespace и is_ascii_control для типов char и u8.
  • Для FreeBSD задействован инструментарий из FreeBSD 11.4 (FreeBSD 10 не поддерживает LLVM 11).

Взято с opennet.ru

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

★★

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

Как минимум, это зависит от реализации.

Особенность реализации - это не неопределённое поведение. Разработчики рантайма знают особенности платформы под которую пишут.

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

Ничего не имею против данного определения, но пруфцы посмотрел бы.

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

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

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

Можешь сам поизучать: https://foss.heptapod.net/pypy/pypy

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

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

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

Особенность реализации - это не неопределённое поведение

Это зависит от реализации при соблюдении опредленных условий. И этих условий чуть больше, чем нисколько: NULL, разыменование которого все равно UB; правильное значение адреса (вырвнивание, диапазон, например не адреса биоса), и при этом по этому адресу заранее записали значение объекта полученное средствами языка.

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

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

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

Разве он не тупо архив?

Хз. шаги такие:

  1. Пишем что-нибудь на Python.

  2. Генерируем файл: cython --embed -o main.c main.py

  3. Компилируем файл: gcc main.c -lpythonX.X -o main (всякие числа вместо X.X)

libpython может быть и static либой…

Не обязательно использовать cython есть и другие компиляторы…

https://github.com/Nuitka/Nuitka и ещё какие-то…

В Nuitka вообще написано:

python -m nuitka --mingw64 hello.py

ещё короче сборка…

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

я в ста строках на питоне 10 ошибок делаю

Напиши себе в профиле это, пожалуйста. Чтобы анон не утруждался читать твои вымтупления на тему программирования.

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

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

anonymous требует пруфов!!!111

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

Особенность реализации

Кстати, если подходить формально, то это и есть расширение языка, которое разрешили самим стандартом.

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

Генерируем .с файл: cython –embed -o main.c main.py

То есть без Си никак.

libpython может быть и static либой…

На каком языке она написана?

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

На каком языке она написана?

На С, как и CPython

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

В принципе можно и на паскале переписать, но зачем?

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

Ассемблеров как говна вообще-то,

Так я и не спорю.

а речь таки про высокоуровневые языки.

Так ты ж про системные языки говорил.

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

она не менее мёртвая чем та, в честь которой её назвали.

Снова ложь 1 2

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

С тобой все ясно - фанатик Си.

Это я фанатик Си? Я скорее противник Си, нужно как минимум использовать подмножество C++. Лично мне больше нравится Оберон. А вообще с разными языками приходится иметь дело.

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

А вообще с разными языками приходится иметь дело.

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

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

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

Я не против использования Си в реализации Python, просто это лишает Python статуса системного языка. На не системных языках тоже можно писать программы приносящие пользу.

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

Я не против использования Си в реализации Python, просто это лишает Python статуса системного языка.

То есть ты хочешь сказать что из-за того что интерпретатор питона написан на С то он не является сис. языком?

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

То есть ты хочешь сказать что из-за того что интерпретатор питона написан на С то он не является сис. языком?

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

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

ДОКАЗАНО

То есть ты хочешь сказать что из-за того что интерпретатор питона написан на С то он не является сис. языком?

А это значит что Rust является сис. языком.

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

Что-то слишком подозрительно. Хотите сказать что я могу любой Python проект в C транслировать? Почему тогда никто этого не делает?

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

Так ты ж про системные языки говорил

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

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

Тогда gcc (реализация си) использует asm (точнее промежуточный язык, похожий на s-exp’ы lisp’a, который однозначно отображается на asm). Что лишает Си статуса системного языка, так как его реализация в лице gcc облажалась на промежуточном языке. Про clang промолчу, там вообще «низкоуровневые виртуальные машины».

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

Тогда gcc (реализация си) использует asm (точнее промежуточный язык, похожий на s-exp’ы lisp’a, который однозначно отображается на asm).

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

libc написан на Си, а libpython написан не на питоне, потому что на питоне написать не возможно.

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

И как это исключает высокоуровневые?

Никак я не исключал, ты приписываешь мне того чего я не писал.

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

Говоря про два, подразумевал их. C, C++ конкретно

Только если не считать ответвления или усовершенствования уже упомянутых тобой C, C++ например Cyclone, ecpp, и даже Arduino

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

Есть TCC, который сразу машинный код генерирует.

Для чистоты эксперимента: какой стандарт языка си там реализован? Также надо показать, что он не генерит промежуточный asm.

потому что на питоне написать не возможно

Говорят, что раньше был PyPy - реализация питона на питоне. Сейчас, говорят, облажался - есть промежуточный этап на Си.

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

А что вы думаете о Nim?

Насколько я понимаю Nim пригоден для системного программирования. Он статически компилируется через Си, но потенциально ничего не мешает прямой компиляции. Есть возможность прямого обращения к памяти. Рантайм языка написан на нём самом.

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

А что вы думаете о Nim?

Недопитон.

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

Я просто не в курсе каким образом оно пакует exe в винде. Мне казалось там тупо архив с сорцами, без компиляции.

RazrFalcon ★★★★★
()

Кстати, вроде rustls прошел первый аудит.

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

Я только за статическую типизацию. Но в вопросах null/не-null считаю модель той же Java вполне достаточной. А Kotlin уже не нравится, например, слишком часто приходится драться с компилятором.

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

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

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

Я просто не в курсе каким образом оно пакует exe в винде.

По крайней мере youtube-dl.exe для Windows - это архив.

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

Говорят, что раньше был PyPy - реализация питона на питоне. Сейчас, говорят, облажался - есть промежуточный этап на Си.

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

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

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

Говорят, еще компилировался в java, .net и javascript. Тоже через Си?

Говорят, сейчас разучился, умеет только компилироваться в си, и интерпретироваться на питон.

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

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

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

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