LINUX.ORG.RU

Rust 1.25.0

 


3

9

Сегодня вышел Rust 1.25.0 (2018-03-29).

Rust это системный язык программирования, нацеленный на надёжность, скорость и параллельное выполнение.
Если вы имеете предыдущую версию Rust, установленную через rustup, для получения версии 1.25.0 достаточно ввести в терминале:

$ rustup update stable

Что нового в 1.25.0 stable

Синтаксис

Компилятор

Библиотека

Стабилизированные API

  • Location::column;
  • ptr::NonNull;

    Наиболее значимое событие — это std::ptr::NonNull<T>. Этот тип похож на *mut T, но является ненулевым (non-null) и ковариантным. Если вкратце, NonNull<T> гарантирует, что никогда не будет равен null, а это означает, что Option<NonNull<T>> имеет тот же размер, что и *mut T. Если вы создаете структуру данных с небезопасным кодом, NonNull<T> зачастую будет правильным выбором для вас.

    Следующие функции теперь могут быть использованы в константных выражениях, т.е. например, static MINUTE: Duration = Duration::from_secs(60);:

  • Duration::new;
  • Duration::from_secs;
  • Duration::from_millis;
  • Duration::from_micros;
  • Duration::from_nanos.

Cargo

Разное

Примечания по поводу совместимости

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

★★★★★

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

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

Сортировка характеризуется сложностью

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

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

Сортировка характеризуется сложностью. Для квиксорта примерно O(n log n). И нефик загонять про настоящие и ненастоящие елочные игрушки.

В теоретической Computer Science - да. На практике - «плебейские константы» тоже внезапно очень важны. Иначе бы ваш компьютер перемножал 8*9 методом Карацубы, числа на простоту проверялись бы с помощью AKS, и т.д.

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

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

Квиксорт на расте без унсейфа будет в X раз медленнее квиксорта с унсейфом на данных любого размера. Устраивает ли такая цена за статические гарантии или нет - каждый решит сам.

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

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

Не вижу смысла плодить левые сущности там где можно четко сформулировать граничные условия.

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

Квиксорт на расте без унсейфа будет в X раз медленнее квиксорта с унсейфом на данных любого размера. Устраивает ли такая цена за статические гарантии или нет - каждый решит сам.

Ровно об этом я и говорил несколько сообщений назад. Только вот это X осталось тайной за семью печатями, так как никто из авторов safe-qsort не захотел его протестировать и сравнить с unsafe. Или же захотел, протестировал, но не стал делиться удручающими результатами :)

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

IMHO было бы достаточно померять эту константу и успокоиться. Тем, кого это волнует, естессна. Лично мне побоку :)

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

Апофеоз чего, в виде Rust-а, мы сейчас и наблюдаем.

Раст-то тут при чём? Какие языки, созданные за последние 20-30 лет допускают segfault?

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

Какие языки, созданные за последние 20-30 лет допускают segfault?

А какие из них являются нативным и не имеют GC?

Когда в языке есть GC и куча проверок в Run-time, сделать segfault нужно постараться. Но вот не для всех прикладных ниш такие языки подходят.

А Rust — это как раз логичное (или не логичное, не знаю как расценивать) стремление перенести безопасное программирование в ту нишу, где использование GC и повсеместных run-time проверок недопустимо.

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

Ну так меня смутило слово «апофеоз» в отношении раста. Сейчас все языки с GC, поэтому появление раста - это скорее отклонение от нормы.

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

Или же захотел, протестировал, но не стал делиться удручающими результатами :)

Дык разница будет только на bound-checking. Тестить нечего. А бенчей в инете полно.

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

А какая тебе разница анонимус пишет или noname со звездами?

Noname — это анонимус. А юзера (совсем необязательно со звездами) можно оценить по контенту, который он создаёт, потому что тот идентифицирован с ним.

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

Нафига оценивать юзера? Оценивай конкретное сообщение. Юзер может троллить, нести ахинею с бодуна, гнать дурочку от некомпетентности. А ты будешь думать: раз username там и сям несет пургу, значит он в принципе не может ничего дельного сказать. И наоборот, если юзер запомнился тебе какими-то умными речугами, ты будешь ошибочно считать все его посты адекватными. Это называется репутация, и она очень мешает объективному восприятию.

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

Нафига оценивать юзера? Оценивай конкретное сообщение.

Одно другому не противоречит. Имя пользователя - первая стадия фильтра.

Это называется репутация, и она очень мешает объективному восприятию.

Репутация помогает фильтровать муть. Да, потери возможны, но оно того стоит.

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

Может воду на Марсе нашли, да доказать не могут

На Марсе воду давно нашли

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

https://3dnews.ru/966972

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

Имя пользователя - первая стадия фильтра.
Статус: 5 звезд (модератор)

Фильтр на основе имени пользователя. Модератор - ариец.

Да, потери возможны, но оно того стоит.

А до исправления было

Бгг

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

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

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

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

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

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

Это называется репутация, и она очень мешает объективному восприятию.

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

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

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

Исключение из правила. У этих ребят в крови attention whoring, их можно считать неадекватами в буквальном смысле.

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

и не понял, где там могли unsafe использовать(?)

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

MyTrooName ★★★★★
()

У меня тут возник вопрос насчет проверки ошибок в расте. Я правильно понял, что функции обычно возвращают Result, но возможности автоматически прокинуть ошибку выше нет?

То есть, будет как в ноде с колбеками, где после каждого вызова писали «if (err) { callback(err); return; }». Код довольно прилично засирался. Сейчас с async/await ошибка автоматически пролетает в виде эксепшена (вызывающего фейл промиса). А может там и без эксепшенов фейлится, не вникал.

Есть ли в расте какие-то соглашения, как определить дефолтный фейл, чтобы не загаживать код?

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

То есть, будет как в ноде с колбеками, где после каждого вызова писали «if (err) { callback(err); return; }».

Для этого есть оператор '?'.

как определить дефолтный фейл

Это как?

RazrFalcon ★★★★★
()

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

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

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

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

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

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

А в конструктивном диалоге не привести ни одного аргумента, и когда аппонент приводит свои, просить справку о том, что он не верблюд, не приводя никаких контраргументов, это тоже принято «у взрослых»?

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

Квиксорт на расте без унсейфа будет в X раз медленнее квиксорта с унсейфом на данных любого размера.

С хренали?! В unsafe отключаются только проверки на уровне компилятора, скомпилированный код практически ни чем не отличается. Соответственно, нет предпосылок быть медленнее. Или есть пруфы об обратном?

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

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

А каких тебе там оптимизаций не хватает?

рекурсивная реализация квиксторта

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

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

Аргумент простой: в safe-qsort будут проверки индексов, чтобы не допустить выхода за пределы массива. Поскольку компилятор не умеет элиминировать такие проверки, даже если можно доказать, что они не потребуются. В оригинальном алгоритме (не коде из servo, а именно алгоритме) такие проверки не требуются. Имплементации на Rust с unsafe, а равно как и на C++, можно написать без проверок. Содержательный вопрос такой: а на сколько такие проверки замедляют работу qsort? Я не знаю, а вы? Для этого я и предлагал провести тестирование.

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

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

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

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

С чего бы этого? llvm вполне умеет выкидывать это.

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

С чего бы этого? llvm вполне умеет выкидывать это.

<Crocodoom>Включена ли такая оптимизация по умолчанию?</Crocodoom>

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

В общем случае такая элиминация делается при поддержке proof assistant, другого пути пока не придумали. В LLVM ничего подобного, конечно же, не встроено. И не может быть встроено принципиально - слишком низкий уровень. В сам Rust - теоретически возможно добавить.

Но если в LLVM научились выкидывать проверку в тривиальных случаях, и это срабатывает для qsort — отлично. Тогда осталось наконец-то закоммитить safe-qsort в servo :)

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

А каких тебе там оптимизаций не хватает?

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

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

А каких тебе там оптимизаций не хватает?

Ну во-первых рекурсия, во-вторых ансейв.

Гм, если это «оптимизации под реалии раста», то LLVM действительно не развитый компилятор заточенный под ФЯП типа GHC, чтобы шутя рекурсию заменять циклом, но unsafe к оптимизации напрямую никак не относится.

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

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

Ансейф даёт ровно три возможности:

  • Доступ и изменение изменяемой статической переменной (глобальная переменная).
  • Разыменование raw указателя.
  • Вызов unsafe функций.

Конкретно в серво'вском квиксорте использовано разыменование указателя, который определен в той же функции, что минимизирует возможные риски. А безопасность в случае использования unsafe обычно обеспечивают «созданием безопасного API» использования небезопасного кода, но опять же, в рассматриваемом квиксорте безопасность разыменования указателя легко доказывается умозрительно.

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

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

4.2

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

Ну завязывай желтить, напьются, а потом чушь несут.

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