LINUX.ORG.RU

Rust 1.12

 


1

6

Команда разработчиков Rust рада представить релиз Rust 1.12 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода. В этот релиз вошёл 1361 патч.

Новое в 1.12

По словам разработчиков, релиз 1.12 является, возможно, самым значительным с момента выпуска релиза 1.0. Самое заметное для пользователей изменение в версии 1.12 — это новый формат ошибок, выдаваемых rustc. Сообществом была проделана многочасовая работа по переводу вывода ошибок на новый формат. Кроме того, для лучшей интеграции и взаимодействия со средой разработки и другим инструментарием ошибки теперь можно выводить в формате JSON при помощи специального флага --error-format=json.

Самое большое внутреннее изменение — это переход на новый формат внутреннего представления программы MIR. Незаметное сегодня, это изменение открывает путь к череде будущих оптимизаций компилятора, и для некоторых кодовых баз оно уже показывает улучшения времени компиляции и уменьшение размера кода. Переход на MIR открывает ранее сложнодоступные возможности анализа и оптимизации. Первое из многочисленных грядущих изменений — переписывание прохода, генерирующего промежуточное представление LLVM, того, что rustc называет «трансляцией». После многомесячных усилий новый бэкенд, основанный на MIR, доказал, что готов к реальной работе. MIR содержит точную информацию о потоке управления программы, поэтому компилятор точно знает, перемещены типы или нет. Это значит, что он статически получает информацию о том, нужно ли выполнять деструктор значения. В случаях, когда значение может быть перемещено или не перемещено в конце области действия, компилятор просто использует флаг из одного бита на стеке, что, в свою очередь, проще для оптимизации проходов в LLVM. Конечный результат — уменьшенный объем работы компилятора и менее раздутый код во время исполнения.

Другие улучшения:

  • Множество мелких улучшений документации.
  • rustc теперь поддерживает три новые цели MUSL на платформе ARM: arm-unknown-linux-musleabi, arm-unknown-linux-musleabihf и armv7-unknown-linux-musleabihf. Эти цели поддерживают статически скомпонованные бинарные файлы. Однако, в собранном виде они пока не распространяются.
  • Повышена читабельность описаний ошибок в ссылках и неизвестных числовых типах.
  • Компилятор теперь может быть собран с LLVM 3.9.
  • Тестовые бинарные файлы теперь поддерживают аргумент --test-threads для указания количества потоков для запуска тестов, который действует точно так же, как переменная окружения RUST_TEST_THREADS.
  • В случае продолжительности выполнения тестов больше минуты показывается предупреждение.
  • Вместе с выпусками Rust теперь доступны пакеты с исходными кодами, которые можно установить при помощи rustup через команду % rustup component add rust-src. Исходные коды могут быть использованы для интеграции и взаимодействия со средой разработки и другим инструментарием.
  • Ускорено обновление индекса реестра.
  • cargo new получил флаг --lib.
  • Добавлен вывод профиля сборки (release/debug) после компиляции.
  • cargo publish получил флаг --dry-run.
  • Сокеты на Linux в подпроцессах теперь закрываются правильно через вызов SOCK_CLOEXEC.
  • Определения Unicode обновлены до 9.0.

Стабилизация библиотек:

  • Cell::as_ptr и RefCell::as_ptr.
  • IpAddr, Ivp4Addr и Ipv6Addr получили несколько новых методов.
  • LinkedList и VecDeque теперь имеют новый метод contains.
  • iter::Product и iter::Sum.
  • Option реализует From для содержащегося в нём типа.
  • Cell, RefCell и UnsafeCell реализует From для содержащихся в них типах.
  • Cow<str> реализует FromIterator для char, &str и String.
  • String реализует AddAssign.

Возможности Cargo

Самая большая возможность, добавленная в Cargo в этом цикле — «рабочие области». Описанные в RFC 1525, рабочие области позволяют группе пакетов разделять один общий файл Cargo.lock. Это позволяет намного легче придерживаться единственной версии общих зависимостей при наличии у вас проекта, который делится на несколько пакетов. Для включения этой возможности в большинстве мультипакетных проектов достаточно добавить одну единственную строчку [workspace] в Cargo.toml верхнего уровня, более сложным установкам может потребоваться дополнительная настройка.

Другая существенная возможность — переопределение источника пакета. При помощи инструментов cargo-vendor и cargo-local-registry можно переопределять зависимости локально (vendoring). Со временем это станет фундаментом для построения инфраструктуры зеркал crates.io.

>>> Подробный список изменений

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

★★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Falcon-peregrinus (всего исправлений: 10)

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

Создается впечатление, что ты мало знаешь о Rust.

Ты Ванга что ли? У меня впечатление скаладывается из наблюдения за кривым Servo, в который уже неизвестно сколько десятков человеко-лет вбухано, и другими проектами, в том числе этим вот Redox.

Это заключение сделано на основании... чего?

На основании вот этого: https://github.com/redox-os/kernel

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

Создается впечатление, что ты мало знаешь о Rust.

Ты Ванга что ли?

Нет, я Шерлок Холмс.

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

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

Это заключение сделано на основании... чего?

На основании вот этого: https://github.com/redox-os/kernel

А. Ну, окей.

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

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

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

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

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

Знаю, что KHTML был гораздо юзабельнее когда в него и десятка человеко-лет не вбухали

Впечатления 15-летней давности - это важно.

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

Object-oriented programming (OOP) is a programming paradigm based on the concept of «objects», which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of «this» or «self»). In OOP, computer programs are designed by making them out of objects that interact with one another.

А теперь расскажи, что у rust не так с поддержкой ООП. Вскудахт про наследование реализаций можешь поскипать и сразу перейти к чему-нибудь существенному.

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

Прошу извинить, немного некорректно написал и смысл утерялся. Я имел ввиду что у методов трейта нет доступа к объекту который его будет реализовывать :) Т.е. как бы я понимаю звучит глупо просить от интерфейса быть частично объектом, но без этого нельзя мне кажется.

Жду когда закроют вот этот реквест https://github.com/rust-lang/rfcs/pull/1546

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

Ну тебе уже два ответа написали: а) Наследование - не часть ООП; б) Си как-то обошёлся.

Единственная реальная проблема в том что кто-то не хочет переставать мыслить AbstractSingletonProxyFactoryBean-и.

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

Эээм, ну как раз к объекту есть (либо я тебя тоже не понял), нельзя именно хранить данные в интерфейсе. Если прям сильно нужно есть приватные поля в структуре и тд.

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

Ну тебе уже два ответа написали: а) Наследование - не часть ООП;

В представлении фанбоев раста.

б) Си как-то обошёлся.

Ассемблер - тоже.

Единственная реальная проблема в том что кто-то не хочет переставать мыслить AbstractSingletonProxyFactoryBean-и.

Это ты про разработчиков Rust'а? Или каким образом наблюдатели могут помешать написать за несколько лет работающий web-движок?

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

Из-за отсутствия полноценной (а не для галочки) поддержки ООП.

Ядрам всех современных ОС это что-то не мешает.

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

Ну а чего ты ожидал? Что я смогу на вскудах ответить невскудахом? Аргументированно, на вопрос который поставлен ни разу не аргументированно? Это для меня сложновато.

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

Да, ядра это отдельная тема и поэтому я про неё написал отдельно.

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

Си как-то обошёлся.

Ассемблер - тоже.

Ну то есть можно считать доказанным, что ООП не особо нужно.

Это ты про разработчиков Rust'а? Или каким образом наблюдатели могут помешать написать за несколько лет работающий web-движок?

Мне кажется, ты лжешь: http://www.arewewebyet.org/

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

Или каким образом наблюдатели могут помешать написать за несколько лет работающий web-движок?

А сейчас есть хоть один движок, написанный полностью с нуля, а не постепенно развивавшийся из исходников старых проектов? С нормальным распаралеливанием, рендерингом на GPU и тд?

Это ты про разработчиков Rust'а?

Это про людей пишущих что без него никак.

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

А сейчас есть хоть один движок, написанный полностью с нуля, а не постепенно развивавшийся из исходников старых проектов? С нормальным распаралеливанием, рендерингом на GPU и тд?

А зачем? Это только мозиле понадобилось написать именно с нуля, да ещё изобрести для этого специальный язык (ну, чтобы уж точно с нуля).

Это про людей пишущих что без него никак.

Пока что без него у раста результат именно никакой.

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

Можно же просто два метода добавить, вместо

trait Trait {
    field: usize
}
будет
trait Trait {
    fn get_field(&self) -> usize;
    fn set_field(&mut self, field: usize);
}
правда реализация сама собой не появиться. Уж лучше так и просить аналог ![derive(...)] для таких методов. Будет как в яблочном objective c.

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

Некоторые также утверждают что и Си объектно-ориентированный.

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

Тут некоторые утверждают, что из-за отсутствия наследования он уже не поддерживает парадигму ООП. При этом написать зачем - видимо, сложно. Или написать зачем именно системному языку оно -

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

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

Т.е. такое вобще возможно?

public abstract class Widget {
    private Theme _theme { get; set; }
    private int _fontSize { get; set; }
    public int GetFontSize() {
        return (_fontSize < 0) ? _theme.GetStandardFontSize() : _fontSize;
    }
}

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

trait Widget {
    fn font_size(&self) -> i32 {
        if self.font_size < 0 { //compiler error
            return self.theme.get_standard_font_size(); //compiler error
        } else {
            return self.font_size; //compiler error
        }
    }
}

цитата того перевода (https://habrahabr.ru/post/309968/)

Я походу отстал чет от жизни...

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

Кхм, ну наверное это то, чего я хочу

А вот в статейке прочитал про проблему хранилища в котором хранимые объекты имеют информацию о самом хранилище (т.е. дети знают о родители, а родитель о детях). Это правда проблема?

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

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

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

Если бы оно не работало, я сильно сомневаюсь, что ты бы это здесь вообще написал)

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

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

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

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

Это, пожалуй, сойдет в качестве иллюстрации про костыли (из обсуждаемого выше).

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

Там человеку странного хочется. Макросы для того и есть.

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

Так я и не писал что не работает, я писал что работает только с костылями. Отвечу тебе твоей же цитатой: «учи слова».

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

Что-то я пропустил. По учмолчанию все структуры и их поля в модуле приватные - это что такое?

Это, пожалуй, сойдет в качестве иллюстрации про костыли (из обсуждаемого выше).

Лучше рассказал бы про какое нибудь виртуальное наследование или деструкторы - крайне очевидные и ни разу не костыльные решения, и самое главное всегда предсказуемое поведение - зачем же вообще раст-то нужен? Недавно был тред где у человека std::move работал как std::swap - сразу видно, качественно сделано.

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

Будто тест того как быстро отдаётся одна строчка информативен. В продакшене всё равно будет перед этим стоять какой-нибудь nginx.

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

Что-то я пропустил. По учмолчанию все структуры и их поля в модуле приватные - это что такое?

На фоне отсутствия наследования - почти бессмыслица. Но это ещё что. Прилепляемые сбоку трейты - гораздо более серьёзная проблема.

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

Действительно. А с деструкторами то что не так?

Недавно был тред где у человека std::move работал как std::swap - сразу видно, качественно сделано.

Это ничего не нарушает.

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

изобрести для этого специальный язык

Она его не изобретала, а взяла уже готовый.

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

меня от го отпугивает тот факт, что написанное на этом языке можно переиспользовать только в этом языке.

Уже больше года как эта возможность появилась. Go 1.5 Release Notes (19.08.2015):

Linker

[...]

There are several other changes. The most significant is the addition of a -buildmode option that expands the style of linking; it now supports situations such as building shared libraries and allowing other languages to call into Go libraries. Some of these were outlined in a design document.

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

Действительно. А с деструкторами то что не так?

С ними всё в порядке, в отличие от чьего-то умения читать. Я писал про виртуальный деструктор. Да, про него все знают и тд., но я клоню к тому что предсказуемое поведение в плюсах как таковое отсутствует, а очевидные вроде бы вещи делаются непонятно как с лозунгом:

Это ничего не нарушает.

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

На фоне отсутствия наследования - почти бессмыслица. Но это ещё что. Прилепляемые сбоку трейты - гораздо более серьёзная проблема.

Эмм, почему бессмыслица-то? Тебе резко расхотелось сокрывать детали реализации друг от друга, или без наследования сакральный смысл сего паттерна резко обнуляется? Почему же трейты «прилеплены сбоку»? Потому что они сделаны максимально простыми и чистыми, дабы не уходить в порнографию с возрастной категорией «C++»?

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

Почему же трейты «прилеплены сбоку»?

«Прилепляются сбоку». Реализуются не в классе (структуре), а в другом месте (модуле).

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

Какое есть адекватное решение сделать дефолтную реализацию некоторых методов для трейта. Хотелось бы получить нечто похожее на абстрактные классы из c++

типа такого? https://doc.rust-lang.org/std/io/trait.BufRead.html

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

Вот пишу я свою коллекцию, переместил где-то в объект и жду себе в каком-то алгоритме что его источник у меня будет пуст,

Даже не знаю что это. Дислексия возможно.

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

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

У вас, мусью, синдром утёнка в терминальной стадии, вы требуете инкапсуляцию как в c++, и наследование как в c++, при том, что как раз в крестовой реализации эти 2 принципа сделаны через жопу и потому противоречат друг другу. В реальности всё ровно наоборот, в расте ООП (если под ООП подразумевать практичную, но ограниченную реализацию, как в c++) реализован правильно. Собственно все бест практики по ООП твердят «наследуйте интерфейс, а не реализацию», «расширяйте композицией, а не наследованием», относительно новые языки программирования по этому поводу придумали возможность запретить наследование от класса, концепцию защищённых полей и методов критикуют третий десяток лет, как нарушающую принцип инкапсуляции, но избавиться не могут, так как без подобных полуоткрытых потрохов ничего сделать невозможно. И вот появился раст. Первым делом добавили варианты, что позволило избавиться от «ООП» на дайнемик кастах. Вторым делом чётко разделили ООПшный указатель от конкретного. Третьим сделали человеческую инкапсуляцию, что решило все проблемы с доступом и лишними зависимостями. Внутри модуля видно всё, не нужно открывать потроха. Снаружи - только публичный интерфейс. Хочется расширить готовую чужую реализацию-кладите внутрь и перенаправляйте методы. Не очень удобно, зато без зависимостей от защищённых членов из чужого модуля и без неожиданно появляющихся методов, при обновлении библиотеки. Хочется, чтоб несколько реализаций внутри одной библиотеки делили часть данных и кода? Ну так, в модуле могут сидеть приватные функции и структуры, пихайте всё общее в них.

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

в одном из десяти случаев ещё как нарушает

переместил где-то в объект и жду себе

Нарушает ожидания анонимуса, вот же собака!

PS Не то чтобы плюсы были сделаны по-человечески, но именно с move через swap всё в порядке.

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

именно с move через swap всё в порядке.

То, что moved-out объект может спокойно и безошибочно использоваться - это тоже «в порядке»?

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

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

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

То, что moved-out объект может спокойно и безошибочно использоваться - это тоже «в порядке»?

В С++ это не moved-out, это цепляние бирки с надписью «делайте что хотите, мне оно больше не надо». Да, это костыль, а не механизм как в Rust, например, но смотреть на него надо именно так.

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