LINUX.ORG.RU

Rust 1.26

 


5

9

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

Обновить Rust можно с помощью команды:

curl https://sh.rustup.rs -sSf | sh # если у вас еще не установлен rustup
rustup update stable

Основные изменения:

  • Вторая редакция книги «The Rust Programming Language» (почти) готова, и теперь рекомендована по умолчанию для ознакомления вместо первой версии. Также готовится к выходу бумажное издание книги.
  • impl Trait в заголовках функций

    Стало возможно указывать Trait в заголовке функции в качестве типа возвращаемого значения:

    fn foo() -> impl Iterator<Item = i32> {
        // ...
    }
    
    Это позволяет не указывать полный тип в заголовке функции, если с точки зрения API конкретный тип не имеет значения. Такой синтаксис подразумевает статическую диспетчеризацию, в отличие от Box<Trait>.

    Также эта возможность удобна для использования с замыканиями (closures):

    fn foo() -> impl Fn(i32) -> i32 {
        |x| x + 1
    }
    

    Новый синтаксис теперь можно использовать и для типов аргументов фунции:

    // раньше нужно было писать так:
    fn foo<T: Trait>(x: T) {
    
    // сейчас можно так:
    fn foo(x: impl Trait) {
    

  • Неявное разыменование ссылок в сопоставлении с образцом (match, if let, ...)

    Теперь следующий код больше не вызывает ошибку компиляции:

    fn hello(arg: &Option<String>) {
        match arg {
            Some(name) => println!("Hello {}!", name),
            None => println!("I don't know who you are."),
        }
    }
    
    и эквивалентен такому:
    fn hello(arg: &Option<String>) {
        match arg {
            &Some(ref name) => println!("Hello {}!", name),
            &None => println!("I don't know who you are."),
        }
    }
    
    То же работает и для &mut + ref mut.

  • Раскрытие срезов (slice) в сопоставлении с образцом
    fn foo(s: &[u8]) {
        match s {
            [a, b] => (),
            [1, _, _] => (),
            _ => (),
        }
    }
    
  • Закрытые интервалы вида 0..=4, включающие обе границы в диапазон перечисления
        for i in 0..=4 {
            println!("i: {}", i); // выведет 0, 1, 2, 3 и 4
        }
    
  • Новые целочисленные типы i128 и u128
  • Функция main() теперь может возвращать тип Result
    use std::fs::File;
    
    fn main() -> Result<(), std::io::Error> {
        let f = File::open("bar.txt")?;
    
        Ok(())
    }
    
  • Ускорения в работе компилятора
  • Стабилизирована функция std::fs::read_to_string
  • При форматировании через trait Debug теперь можно выводить целочисленные значения в шестнадцатеричном виде:
    assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]")
    
  • Номер версии Cargo, начиная с этого релиза, изменяется синхронно с номером версии Rust

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

★★★★★

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

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

Ну вот 10 задач: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html, и какую ни глянь, везде раст-кода больше или столько же, да и в читабельности он уступает, нет кучи ', &, &mut, mut.

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

В го переиспользование кода — копипаста и кодген. В расте — генерики.

Да вы задрали. Есть в го дженерики, встроенные! И они покрывают чуть менее чем все юзкейсы погопешников.

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

А, на том сайте видимо так принято. Твоя ссылка про С++ мы Раст - и посмотри, где плюсы лучше, они выделены, а где нет - не выделены. Так что это на растоманы виноваты, был неправ.

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

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

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

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

кстати, у кого-то может возникнуть вопрос «а почему бы тогда просто не вкомпилить код плагина в браузер»

отвечаю: плагины могут быть несовместимы друг с другом (например, плагин А окрашивает строку поиска в красный цвет, плагин В в синий цвет), вопрос выбора из несовместимых дается пользователю

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

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

гы-гы, действительно так

но можно подойти к ошибке компилятора без юмора и отметить, что сообщение об одинаковости какой-то части двух разных типов содержит весьма мало информации, примерно как в игре «отгадай число до 100 вопросами да-нет» ответ на 1-й вопрос «это число не 13?» содержит примерно 0.15 бита, т.е. очень мало по сравнению с ответом на вопрос «это число больше 50?», который содержит 1 бит (при условии, что все числа равновероятны)

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

Может, подойдёт что-то вроде

   = note: expected type `impl std::fmt::Debug` (anonymized output type of fn1)
              found type `impl std::fmt::Debug` (anonymized output type of fn2)

во-первых, незачем дважды выписывать одинаковую часть

   = note: expected anonymized type, compatible with result type of fn1
              found anonymized type, compatible with result type of fn2
   = note: both types has the same trait set `std::fmt::Debug` 
 
www_linux_org_ru ★★★★★ ()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от O02eg

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

если вдруг они решили эту проблему — то тогда интересно, а нет — тогда это игрушки

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

нет стабильного API? и не надо

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

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

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

facepalm.jpg

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

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

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

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

да, так почему это мозилле не нужно (ты об этом писал раньше)?

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

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

Или будут собираться, но не будут работать. И, если они не собираются из-за нестабильного API, какой в них смысл?

да, так почему это мозилле не нужно (ты об этом писал раньше)?

Потому что для Мозиллы нет никакого профита в создании API на Rust, которое к тому же будет нестабильным. А вот если ты считаешь, что Мозилле это нужно - обснуй.

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

И, если они не собираются из-за нестабильного API, какой в них смысл?

facepalm.jpg

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

Потому что для Мозиллы нет никакого профита в создании API на Rust, которое к тому же будет нестабильным.

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

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

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

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

Ясно-понятно.

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

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

Это такие же генерики как Box<Trait> в расте.

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

Ясно-понятно.

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

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

Это такие же генерики как Box<Trait> в расте.

емнип у них там есть настоящие дженерики — это каналы; но, как говорил почтальон печкин — для вас посылка, только вам я ее не отдам (С)

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

Я имел ввиду слайсы и мапы — встроенные обобщенные контейнеры. Ну и ЦА (пыхерам, сишникам) не привыкать пробрасывать void если уж припрет.

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

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

Или ты предлагаешь мозилле самой починить плагины перед релизом браузера?

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

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

Мне насрать что там встроено, а что нет, мне не насрать, что я не могу сделать свой генерик-контейнер.

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

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

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

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

1. когда в мозилле возникнет мысль «а давайте сломаем вот этот вот интерфейс» (я в этом ответе не буду употреблять громкое слово апи) мозилле можно будет посмотреть кто его реально использует, не бегая по всему интернету

2. можно будет ломать семантику какого-то интерфейса без несовместимого изменения сигнатур функций, трейтов и т.п. и при этом временно запрещать (в смысле не собирать) плагины, которые это используют

Или ты предлагаешь мозилле самой починить плагины перед релизом браузера?

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

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

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

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

при этом желательно было бы вообще не менять код, использующий каналы; поменял какие-то фразы импорта (или что там у go?) и вуаля — теперь каналы еще и считают трафик

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

И зачем это мозилле, когда они могут выдать стабильный API для WebExtensions и перепиливать движок как им угодно?

невозможно все что хочется юзеру затолкать в стабильный API для WebExtensions и/или в ванильный фокс

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

кстати: мне например хочется, чтобы в браузере вкладок не было вообще, а были только окна, которыми управлял мой wm; WebExtensions такое могут? и смогут ли в будущем?

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

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

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

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

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

и что это может поломать?

А хер его знает. Спроси у Пайка, явно же дженериков нет не потому что не шмогли, а по идеологическому заказу.

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

Спроси у Пайка, явно же дженериков нет не потому что не шмогли, а по идеологическому заказу.

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

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

не понял, это юмор такой?

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

www_linux_org_ru ★★★★★ ()