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)

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

Если все это действительно работает без сторонних эффектов, то ты действительно молодец. Ты проверил все?

А самому слабо? Код довольно говорящий и не расто-специфичный.

Что-то я почитал в Вики про быструю сортировку: https://ru.wikipedia.org/wiki/Быстрая_сортировка, — и не понял, где там могли unsafe использовать(?)

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

Благодарю за ответы

Нижняя хорошо читается при беглом чтении, в верхней требуется всматриваться в «::» и «>()».

В Го строгая типизация же? Вроде говорят, что наличие GC в Го не влияет на производительность?

FAT_EXORCIST
()
Ответ на: Благодарю за ответы от FAT_EXORCIST

Нижняя хорошо читается при беглом чтении, в верхней требуется всматриваться в «::» и «>()».

Этот оператор — object.method::<T>(…) — называется «turbofish», или «рыбка». Аннотацией типа, как во втором примере, его не везде можно заменить.

Virtuos86 ★★★★★
() автор топика
Ответ на: Рустофилитики! от anonymous

Ха! Руководители проектов по реализации быстрой сортировки ))))

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

Если все это действительно работает без сторонних эффектов, то ты действительно молодец. Ты проверил все?

Конечно это всё работает, вот playground. Почему кто-то вообще решил, что с реализацией qsort на Rust есть какие-то проблемы?

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

какой ты хочешь ввод-вывод в стандартной библиотеке для bare-metal устройств

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

про всякую специфику вроде named address spaces

Вот кстати да, у классических атмег — как читать FLASH-память, например? В AVR-libc специальные функции есть для доступа туда, подобное можно провернуть в CLang?

one_more_hokum ★★★
()
Ответ на: Рустофилитики! от anonymous

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

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

Ансейф раст для квиксорта нужен чтоб сэкономить на проверке индексов. Внезапно да: отмена проверки индексов в расте небезопасна.

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

От человека, который «практически не пишет на языках программирования», это звучит так веско.

Что поделаешь

Можно начать с того, что высказывать свое авторитетное мнение только о вещах, в которых практически компетентен.

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

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

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

Dark_SavanT ★★★★★
()
Ответ на: Благодарю за ответы от FAT_EXORCIST

Вроде говорят, что наличие GC в Го не влияет на производительность?

к этому заявлению надо прикладывать как минимум пяток ", но ..."

Там GC специфичный и вообще go достаточно специфичный и в некоторых местах ещё неудобнее чем раст ИМХО.

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

Похоже, спорить трудно. Но

Т.е. вопрос истины тебе не интересен, лишь бы похоливарить, да?

как-то немного шире

Ты серьезно? Придраться к тому что функция, которую привел анонимус только потому, что она не шаблонная. Либо ты ну очень толстый тролль, либо настолько профан в рассматриваемой теме, что не понимаешь, что это обобщение делается одной инструкцией.

как обойтись без рекурсии?

Ну наконец-то вопрос достойный ответа. Как же нам решить задачу десятилетия? Это же так сложно. Ну давайте попробуем взять первую попавшуюся рабочую реализацию qsort на том же c++ и переписать ее на раст

fn qsort<T : Ord + Copy>(a : &mut [T]) {  
  let mut lbstack = vec![];
  let mut ubstack = vec![];
  lbstack.push(0);
  ubstack.push(a.len()-1);

  while lbstack.len() > 0 {
 
    let mut lb = lbstack.pop().unwrap();
    let mut ub = ubstack.pop().unwrap();

    loop {

      let ppos = ( lb + ub ) >> 1;
      let mut i = lb;
      let mut j = ub;
      let pivot = a[ppos];

      loop {
        while a[i] < pivot {
          i += 1;
        }
        while pivot < a[j] {
          j -= 1;
        }

        if i <= j {
          a.swap(i, j);
          i += 1;
          if j == 0 {
            break
          }
          j -= 1;
        }
        if i > j {
          break
        }
      }

      if i < ppos {

        if i < ub {
          lbstack.push(i);
          ubstack.push(ub);
        }
        ub = j;

      } else {

        if j > lb { 
          lbstack.push(lb);
          ubstack.push(j);
        }
        lb = i;
      }

      if lb >= ub {
        break
      }
    }
  }
}
О нет! Неужели все таки qsort на раст пишется так же как и на любом другом языке(за исключением ярой функциональщины)

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

Можно начать с того, что высказывать свое авторитетное мнение только о вещах, в которых практически компетентен.

Скажем так, я даю себе право высказываться о тех вещах, которыми пользуюсь я в практическом плане. Я использую Rust безальтернативно его отключить в Firefox. Я использую LLVM безальтернативно его отключить в Mesa DRI. И вижу воочию, что без них было так же, если не лучше. То есть эти технологии лично для меня за время своего существования ничего хорошего и лучшего не принесли, а только добавили время на своё сопровождение. (Кроме Rust, у меня на FreeBSD сейчас ДВА безальтернативных LLVM-5.0.1 - один системный, другой для Mesa DRI и Rust 1.24.1 и ещё один LLVM-6.0.0 в «горячей» готовности для портируемой версии Rust 1.25 на ближайшее будущее).

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

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

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

Они видимо угорели по низкуровневым оптимизациям. Хотя конечно странно видеть в одной функции переход к unsafe указателям, рекурсию и постоянные «[i as usize]». Может, конечно, я чего-то не знаю. Энивей комьюнити им судья.

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

новые версии Фуррифокса собирать самому с недавних пор приходится, пачкая руки об Раст

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

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

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

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

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

Подозреваю что полуавтоматически переводили с другого яп.

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

Обычный, в UART по умолчанию

Не проблема. Реализуешь fmt::Write для своего юарта, и вперёд.

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

Вот кстати да, у классических атмег — как читать FLASH-память, например? В AVR-libc специальные функции есть для доступа туда

В avr-libc это реализовано на инлайн-ассемблере.

подобное можно провернуть в CLang?

В LLVM такой же инлайн-ассемблер, как и в GCC. Соответственно, в Rust тоже.

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

Надо внимательно посмотреть в доки idrisа, запомнить его фишки, стереть нафик сорцы и написать его заново. Потому что Эдвин - тот еще говнокодер и мудак.

q0tw4 ★★★★
()

Как выберется у меня лет 10 свободного времени, напишу нормальный rust с нормальными хаскелевыми type classes

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

напишу нормальный rust с нормальными хаскелевыми type classes

Через 10 лет они там и так будут. Но ты можешь присоединиться.

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

Зачем? Один Хаскель, который усложняется ради усложнения, уже есть.

лет 10 свободного времени

По стопам Ганса Рейзера?

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

Они видимо угорели по низкуровневым оптимизациям.

Они видимо не хотят, чтобы их продукт называли тормозилой. Вот вы свои клёвые реализации тестировали на сколько-нибудь значительных объемах данных? Вопрос риторический.

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

Они видимо не хотят, чтобы их продукт называли тормозилой. Вот вы свои клёвые реализации тестировали на сколько-нибудь значительных объемах данных?

Так обсуждение плавно ушло от «на safe Rust невозможно написать quicksort» к «докажите, что ваш quicksort быстрый».

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

Я могу ошибаться, но даже большинству Rust-оманов не будет нужен Rust, в котором quicksort тормозит по сравнению с quicksort из C, C++ или Ada. Что уж говорить про C-шников и C++-ников, которые смотрят на Rust как на единственную реальную альтернативу. В том числе и из-за высокой скорости работы Rust-овского кода.

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

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

Вот это дичь. Хотя бы статистику по уязвимостям глянь, для начала. Определённый класс уязвимостей (double free/use after free, buffer overflow, …) становится крайне маловероятно допустить случайно и не трогая unsafe. Благодаря маркеру unsafe, если это и просочилось, вовремя найти и обезвредить становится так же проще — не нужно сканировать глазами весь код, внимание концентрируется где надо.

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

Я могу ошибаться, но даже большинству Rust-оманов не будет нужен Rust, в котором quicksort тормозит по сравнению с quicksort из C, C++ или Ada

У меня нет причин сомневаться, что на Rust можно написать quicksort ровно той же производительности, что и в Си++. Если для этого придется писать unsafe код - жаль, но все разумные люди с самого начала понимали, что unsafe код неизбежен. Вопрос в объеме и локализации unsafe кода. В Си++ он СУКА ВЕЗДЕ (ага, я только что исправил затирание памяти из-за неправильного индекса массива).

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

Я вообще не про это, а про то, что фраза:

Так обсуждение плавно ушло от «на safe Rust невозможно написать quicksort» к «докажите, что ваш quicksort быстрый».

Не совсем правомочна. Т.к. если написанный на safe Rust-е quicksort не будет quick, то обсуждение никуда и не ушло, а идет вокруг одного и того же вопроса.

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

Т.к. если написанный на safe Rust-е quicksort не будет quick, то обсуждение никуда и не ушло

Окей.

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

но все разумные люди с самого начала понимали, что unsafe код неизбежен. Вопрос в объеме и локализации unsafe кода. В Си++ он СУКА ВЕЗДЕ (ага, я только что исправил затирание памяти из-за неправильного индекса массива).

В чём проблема использовать std::vector.at()? А если используете свои контейнеры, то определяйте для них operator[] сразу с проверкой границ. Конкретно в вопросе индексации я особой разницы между Rust и C++ не вижу.

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

Так обсуждение плавно ушло от «на safe Rust невозможно написать quicksort» к «докажите, что ваш quicksort быстрый».

Для начала нужно хотя бы продемонстрировать, что safe-qsort имеет правильную асимптотику, иначе это вообще ни о чём. Помните драму с qsort на Haskell?

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

В чём проблема использовать std::vector.at()?

В том, что это был не вектор.

А если используете свои контейнеры

И не контейнер.

Для начала нужно хотя бы продемонстрировать, что safe-qsort имеет правильную асимптотику, иначе это вообще ни о чём.

Дискуссия плавно поворачивает к «ваш quicksort - не quicksort».

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

если написанный на safe Rust-е quicksort не будет fast

поправил

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

только что исправил затирание памяти из-за неправильного индекса массива

В чём проблема использовать std::vector.at()?

В том, что это был не вектор.

А если используете свои контейнеры

И не контейнер.

А что у вас там, голые си-массивы?

Дискуссия плавно поворачивает к «ваш quicksort - не quicksort»

Правильно, потому что это предметный разговор. Тема статических гарантий корректности тех или иных алгоритмов — это cutting edge современного CS.

На всякий случай уточню: я не растохейтер, а даже наоборот. Но не терплю фанбойства. Если Rust уже сейчас позволяет написать настоящий qsort, предоставляя статические гарантии отсутствия UB — я первый порадуюсь. Или хотя бы позволит в будущем. Это будет большой прорыв по сравнению с C++. Если нет — не нужно заниматься головотяпством.

UPD: def настоящий qsort = qsort такой же быстрый, как на языке без статических гарантий отсутствия UB, т.е. C, C++. А полумер типа «ну хоть какой-то qsort, пусть тормозной, зато safe» нам тут не надо.

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

Ансейф раст для квиксорта нужен чтоб сэкономить на проверке индексов.

Нахрена? Там тупой цикл по сплайсу с известной длиной, всё должен выкинуть оптимизатор. Если не выкинет, то это явно баг в оптимизаторе и его нужно просто зарепортить.

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

например, всё ещё ищут воду

На Марсе воду давно нашли, сейчас ищут доказательства того, что в той воде была жизнь.

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

А что у вас там, голые си-массивы?

В том месте - да.

Тема статических гарантий корректности тех или иных алгоритмов это cutting edge современного CS

Не понял, причем здесь это, поэтому просто для протокола: Rust не доказывает корректность алгоритмов. И асимптотику не проверяет.

Если Rust уже сейчас позволяет написать настоящий qsort, предоставляя статические гарантии отсутствия UB — я первый порадуюсь

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

def настоящий qsort = qsort такой же быстрый, как на языке без статических гарантий отсутствия UB, т.е. C, C++

А, понятно. Тогда вердикт не нужен.

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

Если Rust уже сейчас позволяет написать настоящий qsort, предоставляя статические гарантии отсутствия UB — я первый порадуюсь

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

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

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

Странный код ссылается на первоисточник, а не скопирован с примера из Сети :). isize использован, очевидно, потому, что для реализации алгоритма нужны числа знакового типа.

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

настоящий qsort = qsort такой же быстрый, как на языке без статических гарантий отсутствия UB, т.е. C, C++

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

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

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

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

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

Может, если невыход за границы можно доказать статически.

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

Тема статических гарантий корректности тех или иных алгоритмов это cutting edge современного CS

Не понял, причем здесь это, поэтому просто для протокола: Rust не доказывает корректность алгоритмов. И асимптотику не проверяет.

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

Если Rust уже сейчас позволяет написать настоящий qsort, предоставляя статические гарантии отсутствия UB — я первый порадуюсь

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

Алгоритм qsort лежит на википедии. Выше лежат некие программные коды, заявленные авторами как qsort. Бремя доказательства лежит на утверждающем, напоминаю. Это база. Я к этим кодам никакого отношения не имею, и тестировать их не собираюсь. Но могу подсказать, что именно нужно делать, если у них возникнет такое желание, благо опыт имеется.

def настоящий qsort = qsort такой же быстрый, как на языке без статических гарантий отсутствия UB, т.е. C, C++

А, понятно. Тогда вердикт не нужен.

и вынеси вердикт.

У вас раздвоение личности? Так нужен вердикт или не нужен? :)

И да, я часто видел баззворд «zero-cost» применительно к Rust - ну вот тогда именно «zero-cost» safe qsort я и хочу увидеть. Это должна быть хотя бы А) правильная асимптотика, а лучше Б) сравнимый множитель в асимптотике. Ну просадку по множителю в 10-15% ещё можно списать, но не больше. Как только такая имплементация будет предъявлена - бегом коммитить в servo, и в остальные места.

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

Не может код с проверками границ и т.п. быть быстрее, ну хоть усрись

Ну а вдруг там проверка границ даёт незначительную просадку по скорости, скажем 10-15%. Это ещё приемлемо.

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

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

Код ваш - вы асимптотику и считайте. И заодно константу. Так принято «у взрослых». Результат выкладывайте на https://gist.github.com/.

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