LINUX.ORG.RU

Rust 0.12

 ,


5

9

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

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

Обзор обновлений в новой версии:

  • Около 1900 изменений в коде.
  • Основные изменения
    • Вводный документ (и набор сопроводительной документации) был полностью переписан и теперь называется The Rust Guide.
    • Множественные улучшения пакетного менеджера Cargo и его поддержка большим числом библиотек.
    • Большое количество изменений API в стандартной библиотеке std для соответствия текущим стандартам разработки Rust. Все изменения отражены в документации.
    • Ряд библиотек был вынесен из дерева Rust во внешние проекты на Github: uuid, semver, glob, num, hexfloat, fourcc. Они могут быть установлены с помощью Cargo.
    • Новая возможность: lifetime elision - позволяет во многих случаях не указывать явно аннотацию времени жизни (lifetime) в сигнатурах методов.
    • Появилась версия компилятора для Windows 64-bit.
  • Язык
    • Операцию индексации теперь можно перегрузить в своих типах данных с помощью трейтов (trait) Index и IndexMut.
    • Конструкция if let теперь выполняется только при совпадении let-паттерна.
    • Новый синтаксис для срезов (slices), например: [0..4]. Поддержать подобный синтаксис в своих типах данных можно с помощью трейтов Slice и SliceMut.
    • Синтаксис для сравнения с образцом срезов стал постфиксным, теперь он имеет вид: [a, b, c..].
    • При использовании интервалов с включением в сравнении с образцом теперь верхняя границы считается не включенной: вместо 0..3 стоит указывать 0...4.
    • Элементы кортежей и кортежных структур теперь могут быть получены с помощью нового синтаксиса индексации: value.0.
    • Атрибут #[crate_id] теперь не поддерживается, версионирование выполняется исключительно пакетным менеджером.
    • Импорт библиотек с переименованием теперь записывается как extern crate foo as bar вместо extern crate bar = foo.
    • Оператор use с переименованием теперь имеет новый синтаксис: use foo as bar вместо use bar = foo.
    • Добавлен новый, более эффективный тип замыканий: unboxed closures. Со временем текущий тип замыканий будет заменен новым.
    • Добавлено ключевое слово move, которое описывает замыкания, захватывающие переменные по значению.
    • Модификация (mutation) и присваивание теперь не могут использоваться в pattern guards.
    • Параметризованные структуры и перечисления теперь могут быть ограничены (иметь trait bounds).
    • Новый, более гибкий синтаксис указания ограничений типов с помощью ключевого слова where
    • Трейт Share переименован в Sync для того, чтобы термин shared обозначал только shared reference.
    • Для типов динамического размера добавлен трейт Sized. Чтобы указать, что параметр типа не должен иметь строгий размер, стоит использовать ограничение: <Sized? T>.
    • Замыкания теперь могут возвращать !, примеры сигнатур: || -> !, proc() -> !.
    • Границы времени жизни (lifetime bounds) теперь могут быть применены к параметрам типа и типам объектов.
    • Старый тип автоматически автоматически управляемых ссылок со сборкой мусора GC<T> окончательно был удален. В будущем появится новая реализация управления памятью со сборкой мусора.
  • Библиотеки
    • Улучшена документация к ряду библиотек.
    • Обновлены битовые векторы: collections::bitv.
    • Библиотека url признана устаревшей. Рекомендуется использовать http://github.com/servo/rust-url, устанавливаемую с помощью Cargo.
    • Почти все типы данных потоков (stream) ввода-вывода теперь могут быть клонированы и закрыты в других потоках (thread) выполнения.
    • Добавлен тип std::time::Duration для использования в методах ввода-вывода, зависящих от таймера.
    • The runtime I/O abstraction layer that enabled the green thread scheduler to do non-thread-blocking I/O has been removed, along with the libuv-based implementation employed by the green thread scheduler. This will greatly simplify the future I/O work.
    • collections::btree переписана с учетом более эффективного и близкого к Rust проектирования.
  • Утилиты
    • Вывод rustdoc теперь содержит метку об уровне стабильности API.
    • Флаг --crate-name теперь может указывать имя компилируемой единицы кода (crate), что ранее указывалось в коде атрибутом #[crate_name.
    • Флаг -C metadata указывает дополнительные метаданные, хэш которых должен попасть в символьные имена собираемого бинарника.
    • Флаг -C extra-filename указывает дополнительную информацию, добавляемую в имя выходного файла для использования пакетным менеджером.
    • Улучшена генерация отладочной информации, которая теперь лучше совместима при отладке через gdb и lldb.
    • Добавлена экспериментальная поддержка параллельной компиляции с помощью флага rustc -C codegen-units.
    • Компилятор теперь не добавляет по умолчанию в бинарные файлы путь для поиска библиотек (rpath).
  • Прочее
    • Оптимизировано использование стека с помощью аннотаций LLVM.
    • Rust для Linux более совместим со старыми версиями ядер и дистрибутивов.

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



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

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

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

А где рекомендуют в С? Ошибки они и есть ошибки, просто где-то они приведут к крешу, а где-то к испорченным данным.

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

Честно вам скажу: пробовал, но не смог. Писал на Pascal/Object Pascal, Fortran 90/95, Python 2/3, D2, немоног на Java, Go и С99 (в основном OpenCL). За C++ два раза брался, так и не смог.

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

По-моему, именно с концепцией они определились - «memory safety without GC». Проблема в том, что _практически юзабельных_ языков на этой концепции никто пока не построил.

Ну это требование не только очень общее, но и очень сложное. Я имею в виду всякие проектные вещи. Например, в плане синтаксиса, в плане процедурности/модульности, ООП, функциональщины и прочего. Типа PEP. Например, заявили бы, что синтаксис должен быть максимально близок к C++, либо заявили бы, что для встроенных операторов максимально будут использовать спец. символы, а не слова типа тех же box или as. Или сказали бы: мы будем реализовывать функцию map и будем стараться сделать так, чтобы она работала так же быстро, как и цикл. А если не получится, выкинем map. А у них полный бедлам.

Vudod ★★★★★
()

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

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

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

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

Внезапно в расте пытаются собрать лучшие возможности и черты множества языков:

У меня очень большие сомнения в нормальном результате и вот почему:

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

Вот, кстати, вот хороший пример сравнения реализации куска алгоритма на Haskell и на C++: http://www.youtube.com/watch?v=b9FagOVqxmI&feature=youtu.be&t=47m37s

2. Сложность языка. То же, что и предыдущее, но с точки зрения девелопера. Чтобы нормально пользоваться языком придется учиться. Звучит смешно? А теперь давайте вспомним сколько программистов проходят нормальное обучение перед тем, как начать что-то делать и писать свое «фе» на форумах.

Недавно я открыл для себя исключения в C++. Нет, про try ... throw ... catch я знал очень давно, и даже как-то их использовал. Кстати, слышал не раз, что некоторые не рекомендуют использовать исключения, так как иногда приводит к феерическим проблемам. Но потом я посмотрел вот это: http://www.youtube.com/watch?v=N9bR0ztmmEQ (ну, и еще почитал немного) и все стало на свои места. При кажущейся простоте и очевидности, исключения просто нужно уметь использовать.

Это я к тому, что, Rust либо придется выбрать основную парадигму, чтобы снизить порог вхождения, но пожертвовать «универсальностью», либо терпеть критику в стиле «неудобно» и «феерические проблемы», как это терпит C++.

ИМХО.

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

либо терпеть критику в стиле «неудобно» и «феерические проблемы», как это терпит C++

да ему не нужно будет терпеть, критическую массу он не наберет

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

Недавно я открыл для себя исключения в C++

Когда Вы покодите еще немного лет, то поймете, что кидание экзепшенами не панацея, а путь в пропасть. Что полезного Вы можете сделать по экзепшену «не могу выделить память»? А использовать его для «не могу открыть файл» - по меньшей мере глупо.
P.S. Если Ваша программа выкинула экзепшен, то самое плохое - показать пользователю MessageBox с номером ошибки :)

void_ptr ★★★★
()

Синтаксис с каждым релизом всё лучше и лучше

Box<> и box вместо ~

Всё правильно сделали. Перловку жрите сами.

use foo as bar вместо use bar = foo

Всё правильно сделали. До этого была люта наркомания. Во-первых, написано use bar, а на самом деле используетсся foo! Во-вторых, символ = и так перегружен смыслами. Чем меньше он используется не по делу, тем лучше.

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

Что полезного Вы можете сделать по экзепшену «не могу выделить память»?

Исключение - это просто один из способов возврата кода ошибки. С ним можно делать всё то же, что и с кодом ошибки.

А использовать его для «не могу открыть файл» - по меньшей мере глупо.

Ну так не надо поступать глупо.

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

Ну, что будет если я еще покодю - посмотрим. Но пока я в корне не согласен.

Что полезного Вы можете сделать по экзепшену «не могу выделить память»?

1) Показать нормальное user-friendly сообщение вместо того, чтобы просто вывалиться как при сегфолте.
2) Выгрузить какие-то данные для освобождения памяти и продолжения нормальной работы, если это возможно в программе.

А использовать его для «не могу открыть файл» - по меньшей мере глупо.

Глупо каждый fopen и другие 100500 функций оборачивать в что-то типа if (result==-1) ... ; если любая ошибка должна привести просто к выходу из функции. А еще интересней, если при выходе из функции нужно не просто return, а еще какой-то delete или fclose. А если это еще происходит в какой-то f5(), вызванной из f4(), вызванной из f3()..., и вышеупомянутая ошибка должна привести к завершению всей цепочки вплоть до f1(), то if (result==-1){...} становится самой частоиспользуемой конструкцией и не сильно сказывается на читаемости кода. Ну и т. п.

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

Глупо каждый fopen и другие 100500 функций оборачивать в что-то типа if (result==-1) ... ; если любая ошибка должна привести просто к выходу из функции. А еще интересней, если при выходе из функции нужно не просто return, а еще какой-то delete или fclose. А если это еще происходит в какой-то f5(), вызванной из f4(), вызванной из f3()..., и вышеупомянутая ошибка должна привести к завершению всей цепочки вплоть до f1(), то if (result==-1){...} становится самой частоиспользуемой конструкцией и не сильно сказывается на читаемости кода. Ну и т. п.

Вам надо на Яве кодить тога, если у вас такие необходимости. Или по крайней мере использовать какие-нибудь языки со сборкою мусора типа D или Go.

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

Вам надо на Яве кодить тога, если у вас такие необходимости. Или по крайней мере использовать какие-нибудь языки со сборкою мусора типа D или Go.

Зачем? В C++ есть для этого все необходимые и удобные инструменты.

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

А если это еще происходит в какой-то f5(), вызванной из f4(), вызванной из f3()..., и вышеупомянутая ошибка должна привести к завершению всей цепочки вплоть до f1(), то if (result==-1){...} становится самой частоиспользуемой конструкцией и не сильно сказывается на читаемости кода.

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

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

C++ повязан совместимостью с C

Нет.

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

Поэтому растовые концепции владения и заимствования (основная фишка rust, IMHO) реализовать в ядре C++ невозможно

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

IMHO C++ самый практичный язык из всех существующих. Он идет по пути практической полезности для решения реальных задач, а не пытается воплощать самые (единственно) «правильные» концепции, заложенные авторами. Он не пытается скрыть от программиста реальную машину, на которой он работает. Разные виртуальные машины, чистая функциональщина и другие сборщики мусора в попытке создать для программиста безопасное окружение все равно работают на реальном железе и в какой-то момент ограничения, которые они накладывают, начинают больше мешать, чем помогать, при этом обойти их крайне сложно - закон дырявых абстракций в полный рост.

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

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

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

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

Так Rust ничего не скрывает - он вносит новую парадигму работы с памятью. Думаю Вам стоит сперва почитать немного документации, прежде чем так огульно отзываться о Rust. Ведь в нем предпринята попытка сделать революцию в работе с памятью.

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

Свою систему сборки пилят сейчас, Cargo: https://github.com/rust-lang/cargo

Самая бесполезная вещь.

плюсирую. лучше бы к cmake плагин сделали

Сargo - это прежде всего пакетный менеджер, а не система сборки.

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

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

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

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

Я постоянно использую C++ и могу сказать, что это действительно гибкий и мощный инструмент. Только вот необходимость понимать тысячи различных особенностей (и уметь обходить столько же всевозможных ловушек), связанных с самим языком, а не с решаемой задачей, несколько напрягают.

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

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

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

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

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

А где рекомендуют в С? Ошибки они и есть ошибки, просто где-то они приведут к крешу, а где-то к испорченным данным.

Всё равно не понимаю логику. В С и С++ точно так же можно игнорировать ошибки. Даже сегфолт можно попытаться «обработать». Раст тут ничего не меняет.

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

Что полезного Вы можете сделать по экзепшену «не могу выделить память»?

Освободить кеши и попробовать выполнить операцию ещё раз.

А использовать его для «не могу открыть файл» - по меньшей мере глупо.

Ничего глупого.

P.S. Если Ваша программа выкинула экзепшен, то самое плохое - показать пользователю MessageBox с номером ошибки :)

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

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

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

Почему ты рассматриваешь exception именно именно как ошибку? Это не ошибка, а просто механизм ветвления, аналогично с if.

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

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

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

Сargo - это прежде всего пакетный менеджер, а не система сборки.

Очередной убийца portage, rpm и пр.?

Нет. Даже непонятно, что вообще заставило тебя так подумать.

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

тем не менее все компиляторы так или иначе дают читать регистры и закреплять регистры за переменными. гцц даже дает закрепить регистр за глобальной переменной
int eax asm(«eax»);

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

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

Я знаю о встроенных ассемблерах. А ты знаешь о том, что встроенный ассемблер - это не Си++?

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

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

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

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

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

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

Ясен хрен придется, сложности хаскеля вроде не намечается, поэтому массы должно осилить.

Rust либо придется выбрать основную парадигму
либо терпеть критику

Совсем не очевидно, ну вижу проблемы.

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

C++ самый практичный язык из всех существующих. Он идет по пути практической полезности для решения реальных задач, а не пытается воплощать самые (единственно) «правильные» концепции, заложенные авторами.

Угу, никаких концепций там нет, верно подмечено. Дохлый страус просто прикрутил классы (как он их понимал) к сишечке. И весь остальной ад и израиль прикручен умельцами всё к той же убогой сишечке. Это можно было понять и простить 15-20 лет назад. Можно понять и простить инерцию индустрии. Но дрочево на кресты сегодня?! Неее, даже хачкелята и липсоеды и те симпатичнее.

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

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

Нуну. template <float f> во все поля. Или частичное чего-то там, template <> void func <42> {траливали, это нам не задавали}, в которую что бы заработала, надо вводить структуры с value, прамо как в книжке Александреску, ёпта.

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

Так что не надо пть про „самый практичный язык из всех существующих“. Это кусок говна, а не язык.

И да,

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

нормальные люди используют С.

А вот это

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

я даже коментить нехочу, ибо от этого настолько сильно несёт пьяным угаром, что просто жах. Ключевое слово „просто“.

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

Тебе что-то не нравится?

Да, обилие несовместимых друг с другом программ, выполняющих одно и то же.

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

выполняющих одно и то же

Нет. Дистрибутивные пакетники привязаны к дистру, а языковые - к языку. Очевидненько, не правда ли? Разрабы сидят на самых разных дистрах и осях, но система доставки у них одна. Когда изобретешь и внедришь универсальный и простой пакетный менеджер, умеющий в многоверсионность, приходи поговорим.

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

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

Дурное дело нехитрое. Или встроенный ассемблер не есть часть инструмента с++?

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