LINUX.ORG.RU

Релиз языка программирования Rust 1.39

 ,


1

8

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

Что нового в версии 1.39:

  • стабилизирован новый синтаксис асинхронного программирования, основанный на функции «async», блоке async move { … } и операторе «.await»;
  • разрешено указание атрибутов при определении параметров функций, замыканий и указателей на функции. Поддерживаются атрибуты условной компиляции (cfg, cfg_attr), управляющие диагностикой через lint и вспомогательные атрибуты вызова макросов;
  • стабилизирован «#feature(bind_by_move_pattern_guards)», который позволяет использовать переменные с типом привязки «by-move» в шаблонах;
  • предупреждения о проблемах при проверке заимствования переменных c использованием NLL переведены в разряд фатальных ошибок;
  • в пакетный менеджер cargo добавлена возможность использования расширения «.toml» для файлов конфигурации.

С полным списком изменений можно ознакомиться на сайте разработчика.

>>> Источник

★★★★★

Проверено: cetjs2 ()

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

Проприетарщина тоже не нужна.

Хиппи, скубенты и красноглазики - это хорошо, но (для большинства) временное состояние. А когда/если человек вырастает из этого возраста, и как-то надо кормить семью, выбирается тот язык, который востребован в индустрии. При этом никто не мешает осилить Rust потом. Если он действительно захавает все ниши С++.

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

Если бы Linux был бы написан на Rust, то там было бы полно unsafe и подобных багов.

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

Так сделана стандартная библиотека если что.

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

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

Вполне нормально писать короткие unsafe фрагменты, которые через safe врапер рассказывают остальному миру как ними пользоваться

Процессоры - unsafe, это нельзя обойти. Rust делает unsafe нижний уровень. С делает всё уровни.

vertexua ★★★★☆ ()
Последнее исправление: vertexua (всего исправлений: 4)
Ответ на: комментарий от dinama

а borrow checker это что?

Это часть языка. Синтаксические свойства программы вычислимы. Семантические свойства программы невычислимы (теорема Райса).

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

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

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

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

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

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

Синтаксические свойства программы вычислимы. Семантические свойства программы невычислимы (теорема Райса).

гарантирует некоторые семантические свойства

This.

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

  1. Утверждаешь голословно что все программисты на Rust думают что Rust исправляет все существующие баги на планете, делает волосы шелковистыми и делает чтобы *** стоял до 100 лет.

  2. Говоришь что так как это невозможно, то они идиоты.

Сам придумываешь, сам опровергаешь

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

D более продуктивный

И вот тут уже нужно померяться репозиториями пакетов.

https://code.dlang.org/ vs https://crates.io/.

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

Оба конечно не в лиге NPM

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

Так и представляю название новой книги: «Освой полный курс Теории Вероятностей за 21 день (включает совершенно бесплатный полный курс по стохастическим интегралам, расчитаный на один день)». Картина маслом.

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

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

С делает всё уровни.

Это не так. На С можно запилить какой угодно уровень safe. Однако далеко не все проверки можно выполнить в compile-time, ну просто по определению. А проверки в рантайме чего-нибудь да стоят. Можно запилить абсолютно безопасное решение на сях, но если оно будет шевелиться как ленивый жук на солнышке, то никого это не устроит. Поэтому пишется reasonable-safe, а там как пойдет. Иногда(редко) не прокатывает. Не прокатило - починяем. Вот и вся незамысловатая стратегия.

Подход «тут читать, тут не читать, а тут рыбу заворачивать», как в расте, на практике ничего не дает. Почему? Потому что главное правило инженерии - прочность конструкции равна прочности самого слабого элемента. Есть unsafe? Безопасность всего кода равна безопасности unsafe фрагмента. Тут можно сказать - дык нам же теперь только об unsafe кусочке надо думать, а не обо всем, что мы наколбасили! Ну так и в сишных прогах, в том же ядре, потенциальные уязвимости не рассыпаны по всему коду гроздьями. Каждый кусок кода делает свою небольшую работу, поэтому локализовать проблемный участок кода это не рокетсайнс.

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

Go. Леммингов много по обе стороны баррикад, но у Go на порядки ниже порог вхождения.

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

Потому что главное правило инженерии - прочность конструкции равна прочности самого слабого элемента. Есть unsafe? Безопасность всего кода равна безопасности unsafe фрагмента.

Полная ерунда. Когда чистил зубы последний раз - час или месяц назад, есть разница. Все на спектре.

Баг можно допустить в каждой точке кода. Если сделать так чтобы целый класс ошибок стал невозможен в 95% кода, то это строго лучше. В каждой из этих функций можно было проморгать указатель или утащить что не нужно в другой поток без сихронизации.

Или ты о просто чустве паранойи? Да, у тебя в 10000 строчках safe кода есть один unsafe, то если быть поехавшим, то ты не будешь спокойно спать, ожидая как этот unsafe прийдет к тебе в постель с ножом. Но это иррациональный страх. Этот кусок был написан с полным осознанием как он работает и в нем соблюдаются нужные инварианты. Когда этот код будут менять, то unsafe будет серьезным тригерром чтобы перепроверить все 5 раз.

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

Что более смузишное: Rust или Go?

WebAssembly Rust NPM модуль. С враппером в ReasonML и статьей на Medium как вы в миллиард раз ускорили какую-то хрень

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

Вполне нормально писать короткие unsafe фрагменты, которые через safe врапер рассказывают остальному миру как ними пользоваться

Нарисовал картинку к твоему сообщению

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

Поэтому пишется reasonable-safe

Ага. И раст позволяет поднять порог этого reasonable-safe в условиях конечных ресурсов.

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

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

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

Следить за отсутствием инвалидации итераторов

Как и в Rust. Там невалидный итератор вызовет или неправильный результат или панику. А если это оптимизированный контейнер (а unsafe хватает в реализациях), то и креш.

отсутствием выхода за границы в operator []

В Rust это небесплатно, хотя, согласен, в 99% случаев важнее проверить индекс. И в С++ по-хорошему надо бы сделать at и [] паритетными в этом плане, плюс добавить at_unsafe.

отсутствием data races

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

Который помогает, в том числе, с race conditions (которые в Rust ес-но тоже есть), что гораздо важнее и сложнее отследить.

отсутствием UB.

Rust построен на llvm и от UB в общем и целом также не защищает. Тут уже был топик про это с конкретными примерами.

Таких несложно много набирается.

Да, но при этом С++, при всех его недостатках (во многом связанных с возрастом), все-равно удобнее Rust’a. Многое можно списать на привычку, но Rust объективно слаб и в ООП и в ФП. Зато императивщину на нем писать легко и приятно, тут он отличная замена С (был бы, но нет стандартизированного ABI).

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

И вот тут уже нужно померяться репозиториями пакетов.

Можно, конечно. Но зачем? Я всего лишь поправил человека в его заблуждении. А так да, у Rust пакетов больше чем у D.

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

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

Хорошо быть теоретиком.

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

Ну я к тому что вот это голословно

D более продуктивный

Рассматривается сферическая нестрогость языка на каком-то участке кода. Но продуктивность зависит от экосистемы тоже

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

Аргумент уровня «спердобейся». Знаем. Не первый день на ЛОРе

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

Как и в Rust. Там невалидный итератор вызовет или неправильный результат или панику. А если это оптимизированный контейнер (а unsafe хватает в реализациях), то и креш.

Только неправильно написанный итератор, использующий unsafe. Но к случаю for(auto v: vec) { vec.erase(std::remove(vec.begin(), vec.end(), v), vec.end()); } это не имеет отношения.

Использование правильно написанного итератора в расте не может привести к его инвалидации. for v in &vec { vec.remove_item(v); } не скомпилируется, как и все остальные вариации на тему инвалидации итераторов.

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

Рассматривается сферическая нестрогость языка на каком-то участке кода. Но продуктивность зависит от экосистемы тоже

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

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

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

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

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

А добавить проблемный участок кода - как два пальца.

Теоретически. Ну, теоретически двухколесный велосипед источник эпических опасностей. Только три колеса спасут человечество!

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

А причина падений с велосипеда в чем? В конечном счете в том, что велосипедист едет. Отрубить велосипеду педали по самый руль!

Руль?! Точно, руль! Рулит - значит зарулит не туда! Долой руль!

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

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

Использование правильно написанного итератора в расте не может привести к его инвалидации.

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

for v in &vec { vec.remove_item(v); } не скомпилируется, как и все остальные вариации на тему инвалидации итераторов.

Не все, вот тут, например, люди не согласны:

https://docs.rs/mdbook/0.3.1/mdbook/book/struct.Book.html#method.for_each_mut

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

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

Аргумент уровня «спердобейся».

Уровня «сперва познакомся с предметом обсуждения». Хотя кому это надо - «Знаем. Не первый день на ЛОРе» (с).

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

Проиграл. И че мешает сделать сафе на плюсах? Напоминаю кста что в расте утечка памяти это совсем не ошибка.

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

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

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

+1, смотрел пару либ для раста, там унсейф на унсейфе, даже там где можно без него. Кривые руки ништо не выпрямит.

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

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности встречается?

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

Кстати не гарантирует что это runtime eval, может все еще компилироваться

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

Define в сях тоже компилится. Что не делает его менее опасным и нечитабельным

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

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности?

Это точно не опасней вот этого:

https://doc.rust-lang.org/1.5.0/book/compiler-plugins.html

И точно удобнее. Особенно учитывая состояние реализации в Rust.

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

И? Падаем с одноколёсного велосипеда без сиденья и будем падать, пффф?

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

В руст нужно специально заморочиться чтоб его сделать. А в плюсцах это как водички попить

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

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

Полностью согласен

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

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

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

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

В одном из прошлых тредов ананимус приносил D в виде метода map!, принимающего аргументом строку, содержащую код. Прям вот так, в кавычках, код.. В D много такой зашкаливающей безопасности встречается?

А что там не так с безопасностью-то? Это просто напросто небольшой DSL, ничего критичного для безопасности там нет от слова совсем. Не надо показывать так открыто, что не понимаете о чем речь идет.

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

Знаю что можно, вопрос был, как часто такое в обычном коде в D? Настолько часто, что это стандартный метод у массива? Довольно странно как мне кажется

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

Странно было, что чувак решал рядовую задачу (лямбду) через это. Оттого и вопрос, в Дэ это обычное явление или чувак – затейник?

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

как часто такое в обычном коде в D?

Я использовал миксины для генерации кода, очень удобно. А вот вместо лямбд вряд ли их кто-то использует. Вероятно автор просто хотел выписать пример покомпактнее.

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

including PHP, Java, JavaScript, Ruby, .NET, C and C++, Microsoft Classic ASP, Android, iOS, and COBOL, scanning hundreds of thousands of applications over the last 18 months.

в той же строке. Формулировки у автора статьи те еще, но к исследованию Veracode это отношения не имеет.

Само исследование тут

https://www.veracode.com/sites/default/files/Resources/Reports/state-of-software-security-focus-on-application-development.pdf?mkt_tok=3RkMMJWWfF9wsRovua3NZKXonjHpfsX96%2B4pUKC0lMI%2F0ER3fOvrPUfGjI4ATctiNa%2BTFAwTG5toziV8R7fMLM160cIQWRjj

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

А что там не так с безопасностью-то? Это просто напросто небольшой DSL

Краткое описание tcl

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

А что там не так с безопасностью-то? Это просто напросто небольшой DSL

Краткое описание tcl

Понятно. Классическое «Не читал, но осуждаю». Ну очевидно, что вы не понимаете о чем говорите, но представляете это как будто это что-то ужасное. А там ничего ужасного то и нет в помине.

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

По факту сходные по производительности языки типа go и D оказались существенно популярнее, потому что меньше заморочек.

популярнее

D

Это шутка?

Ну и Rust быстрее по определению, ибо GC не может быть zero cost.

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

Ну очевидно, что вы не понимаете о чем говорите

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

На лишпе так вообще наворотить такого можно, что патологоанатом потом не разберется

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.