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 ()

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

Тебе часом не 15 лет?

наверное, если целыми днями порнуху в интернетах разглядывать, то присытишься, но и то — меня берет сомнение

Я для тебя открою секрет. Можно еще реально заниматься сексом. Надеюсь ты не шокирован

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

Что думаешь чтобы переходить на ReasonML, как синтаксиса для нативных билдов OCaml програм?

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

Абсолютно верно.

Я использую Akka - однако, теперь только под Java.

«Виртовская» система типов неудобна.

Все эти «подмешивания» «типажей» (traits) - просто излишний «синтаксический сахар».

Мода на подобные «сахарные» диалекты Java была пять лет назад.

DSL (предметно-ориентированные языки) затруднительны тем, что непонятно, а что автор кода хотел сказать?

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

Секс это миф придуманный женщинами чтоб женить на себе мужчин. В СССР секса не было и все жили прекрасно.

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

Тебе часом не 15 лет?

Если тебе кажется что я прям из штанов от желания выпрыгиваю — то тебе показалось. Однако, отрицать красоту женского тела я не намерен: после 15 пылу, конечно, поубавилось, но открыто говорить на сиськи «фи» я еще не готов.

Я для тебя открою секрет. Можно еще реально заниматься сексом. Надеюсь ты не шокирован

И что, для тебя это отменяет красоту женского тела? Типа: у меня на этой неделе уже был секс, нахрена любоваться ногами прохожей, мне же не 15...

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

Ну OCaml если что, очень простой. Особого ума не нужно

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

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

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

Ну так я ж говорю, в чем трабла сделать форк где лифтайм не отключается?

Дальше произойдёт одно из двух. Либо этот форк окажется отличным, будет работать без напильника с любым С/C++ кодом, в том смысле что корректный код будет компилироваться, а некорректный выдавать ошибку. Чтоб всегда, даже при подключении внешних либ. Постепенно функционал перекочует в другие компиляторы и Rust окажется ненужным несовместимым почти аналогом популярного языка. Ну как какой-нибудь Pascal давно или Oberon сейчас. Будет группа фанатов, рассказывающих, что лайфтаймы украли из Rust и всё равно код на нём красивее и понятнее чем на C++, но всем кто не из их тусовочки будет пофиг.

Либо эти лайфтаймы будут работать через пень-колоду, и нормальный C++ проект просто не будет компилироваться или потребует дописания 100500 всяких аннотаций к каждой функции. Тогда это уже не будет компилятор C++, язык будет необходимо переименовать в D++, в общем-то и получится аналог D, т.е. никчёмный язык, непонятно для чего нужный, с одной стороны типа совместимый, можно небольшие куски C++ кода со стековерфлоу копипастить, с другой - портирование реального проекта настолько муторно, что в общем переписать на Rust ненамного сложнее.

Судя по существовании инициативы C++ Core Guidelines, реалистичен скорее второй вариант.

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

За D не стоит крупных компаний. Если б не потуги Мозиллы - нафиг бы сдалась ржавчина. Уже C++ последних стандартов выглядит более дружелюбным.

каким образом связаны эти три утверждения? как они опровергают, что D, в сравнении с rust&go - мертв?

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

чтобы перло от выдуманного сюжета где Brazzers-style бабы рассказывают о JavaScript

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

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

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

А что метапрога забанили что ли? Ну тогда есть запасной план, можно в растотемы еще немного хаскеля накинуть и обсудить зачем расту вообще понадобилось притягивать подобие обработки ошибок через своим варианты Maybe(Option) и Either(Result).

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

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

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

В GCC не стали бы впендюривать в 2019 мёртвый язык.

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

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

В хаскелле, кстати, помимо Maybe/Either есть и Exception. А вот в расте кроме паники не завезли подобного, увы. Есть,конечно std::panic::catch_unwind, но его совсем не рекомендуется использовать вместо try-catch.

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

Товарищ-вентилятор, ты совершенно не в теме, в haskell тоже есть исключения. Для них есть свои throw, catch и finally.

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

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

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

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

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

Ну это же коллекция компиляторов, коллекционеры вообще любят всякие мертвые вещицы, страсть у них к собирательству…

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

В rust тоже по факту есть исключения, но они представлены одной паникой (зависит от настроек паники). Причем, в случае безопасного Rust по идее должны выполняться базовые гарантии безопасности, т.е. грубо говоря, сегфолта или какого другого фатального сигнала быть не должно. Правда, это еще зависит от того, как написаны части unsafe, которые используются из такой «безопасной» части.

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

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

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

В GCC не стали бы впендюривать в 2019 мёртвый язык.

там и фортран есть и ада, а у ады недавно новый релиз вышел.
мне суть спора не понятна. я что - сказал, что руст хороший ?
оратор заявил, что d популярней rust и go. это ложь.
если сравнивать по популярности, то d - нигде.

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

И что, Ада тоже мертвая? Мне тоже не понятна суть ваших заявлений. Если вы что то не используете, это не значит, что этого нет. D стабильно развивается, регулярные релизы, ежегодные конференции, коммерческие компании его используют, некоторые вообще строят на нем всю свою инфраструктуру. И тут на тебе, приходит dinama и все расставляет на своих местах. Еще и Аду хоронит. А мужики то не знали! Другое дело, что go конечно более распространен чем rust или D - это да. Причем у Rust именно много хайпа, в отличие от go или D.

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

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

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

объем головного мозга человека действительно уменьшился

Если судить только по объёму мозга, то миром должны были править киты, ну или как минимум слоны.

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

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

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

А вот в расте кроме паники не завезли подобного,

Есть `Result<T, E>` и сахар в виде `?`. В принципе хватает. И при этом быстрее исключений.
Плюс ещё думают над try-блоком.

Т.е. без исключений вполне можно обходится и не особо над этим страдать.

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

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

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

Ну так и есть, естественный отбор не работает, все как в Слепом часовщике

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

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

Сказал человек, экстраполирующий собственное мнение на всех.

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

И при этом быстрее исключений.

Спорно. Скорее на оборот.

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

На большой вложенности, на x86_64, исключения должны быть быстрее. Как минимум это верно для C++.

Result далеко не бесплатный. И если у нас 100500 проверок внутри функции, может ощутимо влиять на производительность.

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

Пока не дошло до измерений у самого, но пишут в тырнетах, что именно так. Имеется в виду C++, конечно.

А в растишке эти Error еще надо бывает приводить к другу другу, чтобы по типу совпадало.

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

Потом, Result отжирает стек чуточку больше.

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

И если у нас 100500 проверок внутри функции,

Ну разве что 100500.

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

Как причем? Из таких мелочей и складывается эффективность часто, когда все остальное на одном уровне. В C++ есть даже связанное с этим понятие «пессимизация» - как бы в укор Кнуту :)

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

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

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

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

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

Result медленнее исключений? С чего бы это?

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

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

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

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

Ещё раз, ты можешь показать как большее использование стека влияет на производительность?

Как будет падать скорость если вместо `struct res` я буду возвращать `struct{ enum rtype; union{ struct res; struct err; }; }`?

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

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

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

Как будет падать скорость если вместо struct res я буду возвращать struct{ enum rtype; union{ struct res; struct err; }; }?

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

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

Ну дык выравнивание ещё специально отключать надо.
Так-то все структуры выравниваются по умолчанию. Даже в сишечке.
Просто я к тому что большее использование стека совсем не равно меньшей производительности.

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

Не стану приводить. Обойдешься! Причем, для себя я это делал при тестировании.

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

Технически правильно, но если ошибок мало, branch predictor будет редко ошибаться. Какой-то оверхед будет, но насколько заметный - сильно зависит от кода, который в разных языках будет, естественно разным.

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