LINUX.ORG.RU

Rust 0.10

 ,


2

8

Вышла новая версия Rust, языка программирования разрабатываемого Mozilla. Релиз несет в себе около 1500 изменений и исправлений ошибок.

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

  • Язык:
    • новый процесс RFC для изменения языка;
    • паттерны с '@'-указателями удалены из языка;
    • паттерны с '~[T]'-векторами удалены из языка;
    • паттерны с '~str'-строками удалены из языка;
    • '@str' удален;
    • '@[T]' удален;
    • '@self' удален;
    • '@Trait' удален;
    • заголовки, содержащие '@'-boxes для подсчета ссылок внутри типа, при '~'-аллокациях удалены;
    • семантика времени жизни временных выражений (temporary expressions) изменена. Подробнее в #3511, #11585;
    • добавлен новый cross-crate синтаксис расширений (доступен через feature gates). Подробнее в #11151. Эта возможность включает в себя макросы 'macro_rules!' и 'format!' как синтаксические расширения;
    • добавлены новые режимы lint, использование старых по умолчанию выдает предупреждения:
      • лишние скобки;
      • static в верхнем регистре;
      • Camel Case типы;
      • переменные в верхнем регистре;
      • приватные типы с публичной видимостью;
      • '#[deriving]' с raw-указателями.
    • unsafe-функции больше не преобразуются к замыканиям;
    • некоторые макросы с неясными названиями, например 'log_syntax!', теперь доступны через feature gates;
    • атрибут '#[simd]' теперь доступен через feature gates;
    • запрещены инструкции 'extern crate' в настройках видимости, модификатор 'priv' запрещен к использованию вместе с 'use' инструкциями;
    • замыкающие запятые запрещены в списках аргументов и шаблонах кортежей;
    • ключевое слово 'do' теперь является резервированным ключевым словом;
    • добавлены параметры типов по умолчанию, доступно через feature gates;
    • изменен механизм захвата borrowed-переменных в замыкания;
    • 'extern mod' изменен на 'extern crate';
    • удален 'Freeze' trait;
    • добавлен 'Share' trait для типов которые могут разделяться между потоками;
    • labels в макросах теперь гигиенические;
    • вызовы макросов теперь могут ограничиваться через '{}';
    • добавлен возможность перегрузки операторов '*' и '.' через 'Deref' и 'DerefMut' traits;
    • '~Trait' и 'proc' больше не реализуют 'Send' по умолчанию;
    • добавлена поддержка partial type hints через маркер типа '_';
    • введен тип 'Unsafe' для внутренней мутабельности. Преобразование '&T' в '&mut T' без использования 'Unsafe' является неопределенным;
    • реализован атрибут '#[linkage]' для внешних функций;
    • внутренний синтаксис атрибутов изменен с '#[foo];' на '#![foo]';
    • 'Pod' переименован в 'Copy'.
  • Библиотеки:
    • 'libextra' более недоступна. Она была разделена на более мелкие компоненты. Подробности в документации;
    • 'std::condition' удален. Все ошибки I/O передаются через тип 'Result'. Изменена работа макроса 'try!', подробности в #12039;
    • std: модуль 'vec' переименован в 'slice';
    • std: добавлен новый тип 'Vec<T>' для DST. В будущем это будет единственный вектор с изменяемым размером;
    • std: увеличено число публичных reexports 'std::io'. Типы, такие как 'BufferedReader' доступны через 'std::io::BufferedReader' вместо 'std::io::buffered::BufferedReader';
    • std: 'print' и 'println' более не доступны в prelude, используйте вместо них макрос 'println!';
    • std: 'Rc' теперь имеет 'Weak' указатель для прерываемых циклов и больше не пытается статически предотвращать циклы;
    • std: в стандартной поставке используется политика обработки ошибок пользователем вместо падения в библиотеках. Многие функции, такие как 'slice::last()' теперь возвращают 'Option<T>';
    • std: 'fmt::Default' переименован в 'fmt::Show', добавлен новый deriving mode: '#[deriving(Show)]';
    • std: 'ToStr' реализован для всех типов, реализующих 'Show';
    • std: trait для форматированного вывода принимает '&self' вместо '&T';
    • std: метод итераторов 'invert()' был переименован в 'rev()';
    • std: добавлена возможности вывода backtrace при падении task'a, если выставлено значение переменной 'RUST_BACKTRACE';
    • std: стандартизованы соглашения по наименованию для итераторов. Подробнее в wiki;
    • std: 'eof()' удален из 'Reader';
    • std: сетевые типы (networking types) теперь cloneable, разрешено одновременное чтение/запись;
    • std: 'assert_approx_eq!' удален;
    • std: добавлены спецификаторы форматирования 'e' и 'E' для вывода чисел с плавающей точкой в экспоненциальном формате;
    • std: удален 'Times';
    • std: добавлен тип 'std::kinds::marker' для выборочного вывода встроенных привязок (bounds);
    • std: 'hash' был переписан, 'IterBytes' удален, доступен '#[deriving(Hash)]';
    • std: 'SharedChan' был удален, 'Sender' теперь cloneable;
    • std: 'Chan' и 'Port' были переименованы в 'Sender' и 'Receiver';
    • std: 'Chan::new' заменен на 'channel()';
    • std: реализован новый тип синхронных каналов;
    • std: макрос 'select!' доступен для выбора 'Receiver'-ов;
    • std: 'hashmap' и 'trie' были перемещены в 'libcollections';
    • std: 'run' перемещен в 'io::process';
    • std: 'assert_eq!' теперь использует '{}' вместо '{:?}';
    • std: реорганизованы механизмы сравнения и проверки на равенство trait-ов;
    • std: 'rand' перемещен в 'librand';
    • std: 'to_{lower,upper}case' реализован для 'char';
    • std: функциональность логгирования перенесена в 'liblog';
    • collections: 'HashMap' переписана для увеличения производительности и уменьшения потребления памяти;
    • native: в качестве рантайма по умолчанию используется 'libnative'. 'libgreen' доступен для загрузки вручную, подробнее в документации;
    • native: реализована весь I/O функционал, за исключением сигналов;
    • green: оптимизировано создание task-ов в 'libgreen';
    • green: task-и, создаваемые через 'libgreen' используют unmapped guard page;
    • sync: модуль 'extra::sunc' был обновлен на современный rust, перемещен в библиотеку 'sync';
    • sync: добавлен новый тип 'Barrier';
    • sync: реализованы эффективные мьютексы для нативных и зеленых task-ов;
    • serialize: улучшен модуль 'base64';
    • fourcc: добавлен макрос 'fourcc!';
    • hexfloat: реализован макрос 'hexfloat!';
  • Инструментарий
    • 'rustpkg' объявлен устаревшим и удален из основного репозитория. Его замена ('cargo') в разработке;
    • доступны ночные сборки;
    • значительно улучшено использование памяти 'rustc';
    • отключена поддержка rpath для rustc в процессе сборки;
    • улучшен механизм кодогенерации;
    • восстановлена совместимость debuginfo с lldb на OSX;
    • флаги вывода централизованы в один флаг '--emit';
    • флаги crate типов централизованы в один флаг '--crate-type';
    • флаги кодогенерации объединены через флаг '-C';
    • улучшены сообщения об ошибках возникающих при линковке с устаревшими crates;
    • сообщения об ошибках с временем жизни теперь часто показывают как объявить функцию чтобы исправить ошибки;
    • значительно расширена документация;
    • улучшения в 'rustdoc':
      • подсветка синтаксиса и блоки кода;
      • генерация standalone markdown файлов;
      • флаг '--test' проверяет все блоки кода по умолчанию;
      • отображение экспортированных макросов;
      • reexported типы имеют встроенную документацию в месте первого reexport;
      • результаты работы по поиску в crate-ах теперь генерируется в выходную директорию.

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

★★★★★

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

Дженерики тоже являются «средством генерации». Не таким гибким, но вполне средством.

Нет, не являются.

Да, являются.

При описании generic-типа задается ровно один тип(поэтому никакой генерации нет)

Какой бред. Почему мифологическое отсутствие генерации увязано с заданием однго типа? Откуда вообще взялся «ровно один тип»? Вот тебе два типа:

https://github.com/mozilla/rust/blob/master/src/libcollections/btree.rs#L25

pub struct BTree<K, V> {

дженерики дороговаты для системного языка

Чем же?

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

Это прямая ложь. Хотя... может быть и обычным невежеством.

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

Да, являются.

Покажи мне генерацию

Какой бред. Почему мифологическое отсутствие генерации увязано с заданием однго типа? Откуда вообще взялся «ровно один тип»?

Дженерик описывает тип.

Вот тебе два типа

Нет, тут один тип BTree<K, V>.

Шаблон template<typename K, typename V> struct BTree

Позволит генерировать разные типы, которые не будут иметь ничего общего. BTree<int, int> и BTree<string, string> будут иметь абсолютно разные и вообще никак не связанные между собой типы.

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

Это прямая ложь. Хотя... может быть и обычным невежеством.

Ошибся. Именно в расте они сделали генерацию как в С++

The Rust compiler compiles generic functions very efficiently by monomorphizing them. Monomorphization is a fancy name for a simple idea: generate a separate copy of each generic function at each call site, a copy that is specialized to the argument types and can thus be optimized specifically for them. In this respect, Rust's generics have similar performance characteristics to C++ templates.

Тогда да, все будет как в С++ в плане производительности. Я говорил вообще о дженериках, без учета особенностей Rust. Впрочем, тогда встает вопрос о раздельной компиляции и пр. фишках, надо смотреть, как в расте это сделано. Странно тогда, что они не дают специализировать.

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

А что не так, аргументы кончились? Впрочем, после прочтения части доки касаемо реализации дженериков, у меня создается впечатление, что в раст попытались скрестить ежа с ужом, фактически сделав шаблоны и искусственно навесив на них ограничения дженериков. Тогда да, мои рассуждения будут неверными в случае «дженериков» раста.

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

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

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

аргументы кончились?

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

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

Просто есть два варианта реализации обобщений — с генерацией кода, и с обёртками на каждый тип. И оба имеют свои недостатки: у одних — раздутые бинарники и медленная компиляция, у других — медленное выполнение.
Поэтому, кстати, обобщений в го до сих пор и нет.
Можешь почитать это: http://research.swtch.com/generic

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

И где, кроме раста такие дженерики? В статье про обобщенные структуры данных, а не дженерики/параметрический полиморфизм и пр.

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

Как везде дженерики сделали, кроме раста. И в D и в C++ - шаблоны.

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

Нет, там как раз такая модель дженериков/полиморфных типов, о которой я говорю. В Haskell BTree<K, T> из примера выше был бы именно одним типом, а его kind'ом был бы * -> * -> *

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

Никто не виноват, что в расте свои собственные суждения, отличные от всей отрасли. Да, по поводу раста я ошибся.

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

Никто не виноват, что в расте свои собственные суждения, отличные от всей отрасли.

Как уже сказано, они не отличные от всей отрасли. Добавлю, что в C# для не-референсных типов тоже делается мономорфизация.

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

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

Как уже сказано, они не отличные от всей отрасли.

Ну так где еще так же, как в расте.

Добавлю, что в C# для не-референсных типов тоже делается мономорфизация.

Я писал об этом выше. Для нативных языков такая схема не подходит.

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

Это скорее относится к тебе.

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

Мои суждения полностью соответствуют работе полиморфных типов в языках семейства ML, а так же в Haskell. Так же оно подходит для дженериков Java и Scala, например. Не подходит для «дженериков» раста и шаблонов в D и C++.

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

Вы, видимо, невнимательно следили за дискуссией. Вы говорите о реализации, а не типизации.

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

Мои суждения полностью соответствуют работе полиморфных типов в языках семейства ML, а так же в Haskell

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

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

По делу-то сказать тебе нечего? Сравнение шаблонов и дженериков некорректно, как и сравнение bound'ов с concept'ами. И жаль, что ты не хочешь даже попытаться понять это.

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

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

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

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

в Go? orly? Ты про const или про указатели? И то, и другое есть.

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

То, что есть нулевые указатели - плохо.

«const» в Go, насколько я знаю, служит для объявления константы. А, например, передать в функцию указатель на данные только для чтения (вроде «const Type*» в Си) нельзя. А в Ржавчине даже писать «const» не надо, все неизменяемое по-умолчанию.

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

Нулевые указатели в Go не так опасны, как в С/C++, в худшем случае - паника. Зато в Rust больше вероятность утечек памяти, плюс, как язык Rust сложнее, что само по себе увеличивает вероятность ошибок.

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

Нулевые указатели в Go не так опасны, как в С/C++, в худшем случае - паника.

В сети легко найти много обсуждений этого вопроса, как минимум вот: http://programmers.stackexchange.com/questions/12777/are-null-references-real... .

«в худшем случае - паника» - ну да, тогда и частое использование interface{} не очень плохо, тоже может привести только к панике :) . И не важно, что это все вообще-то можно во время компиляции проверить :)

Зато в Rust больше вероятность утечек памяти

Почему ты так думаешь?

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

Сложность Ржавчины по отношению к Go сильно преувеличивают, как по мне.

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

Почему ты так думаешь?

Так ведь GC опциональный, емнип и сами авторы ржавчины это признавали.

как по мне

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

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

Так ведь GC опциональный ...

В Ржавчине и без сборщика мусора утечек не будет. Ты ничего про Ржавчину не знаешь толком, да? Почитай, как там с памятью работают.

... баг-трекер уже почти вдвое толще гошного ...

Это тут вообще причем? Оно не связано напрямую со сложностью языков. Проекты, мягко говоря, на разных этапах развития.

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

Вопросы:

1. что происходит, когда мы меняем в функции данные, отмеченные как иммутабельные? Получаем панику? 2. Что происходит, когда для функции переменная read-only, но изменяется вне её? В процессе обработки цикла по каждому элементу в ней, напримен.

«Секурно»? Возможно. Но вообще спорно. Насколько я понимаю, Go way для вашего юзкейса — channels (они могут быть r/o или w/o)

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

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

Ошибку компиляции

2. Что происходит, когда для функции переменная read-only, но изменяется вне её? В процессе обработки цикла по каждому элементу в ней, напримен.

Это как? Из другого потока что ли? Можешь пример кода показать?

Насколько я понимаю, Go way для вашего юзкейса — channels (они могут быть r/o или w/o)

Эээээм, не очень понял при чем тут каналы? Не передавать же все аргументы через каналы)

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

2. Да, из другого потока. Смысл: передача рид-онли поинтеров — полумера, const или message passing в многопоточных программах работают предсказуемее. Хотя, юзкейс выше — удобная конвенция для программиста в виде «мы передаём поинтер, а ты его не изменяешь», именно необходимостью это представить сложно.

3. channels и variables — способы передачи данных между процедурами. Есть эрланг, есть жаваскрипт, это разные концепции. Да, есть сферы, где эрланг не блещет производительностью, но, будем честны, большинство прикладников в это не упирается. Пока у меня сложилось впечатление, что у руста на данный момент больше проблем с производительностью, чем у эрланга несмотря на ченнелы и вот это всё.

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

2. ...

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

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

Ржавчина для системного программирования.

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

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

Тут вот: http://stackoverflow.com/questions/9339560/erlang-versus-go-versus-rust-compa... brson говорит, что «Rust very often looks to Erlang when making decisions about concurrency».

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

Ржавчина для системного программирования.

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

Почему именно у тебя сложилось такое впечатление?

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

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

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

http://www.rust-lang.org : «Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races.»

http://en.wikipedia.org/wiki/System_programming_language#Major_languages

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

Ты уверен, что фаерфокс под андроид имеет отношение к Ржавчине? Сыылкой не поделишься?

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

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