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)
Ответ на: комментарий от ozkriff

Обратная совместимость - штука хорошая, только надо же какие-то рамки ставить. 30 лет это слишком.

Дык, они даже решались на «ломающие изменения» (типа auto). (:

Но вообще ситуация когда проект живёт годами не редкость. И в таких проектах просто бы зафиксировали версию компилятора и всё. Консерваторов и так хватает (и не без причин), так что пусть хоть как-то новые фичи проникают.

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

variant (как и enum в Rust) - это просто конструктор ADT; совершенно необязательно конструировать тип «значение | ошибка».

Я понимаю. Речь как раз о том, что если «везде» принято возвращать <результат/ошибку>, то это удобнее, чем если каждый свой велосипед сочиняет. Ведь Result в расте именно для этого, если я правильно понял.

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

Да там какое-то УГ:

maybe a better example would be avoiding monadising the «pure» operations and just chain them directly:

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

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

А... естественно, наличие разумных соглашений - это хорошо.

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

Нигде не надо шариться. Большая программа на плюсах - поле с UB-граблями.

Не надо мне детские страшилки рассказывать, пожалуйста. Если не хакерствовать и прочитать хотя бы один учебник, то UB надо именно искать. Разумеется, язык сложнее, чем хотелось бы. Но не так, чтобы ужасы на каждом углу ожидали.

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

Даже не похожий %)

Ну он чуть-чуть убирает лишнюю писанину. do-макрос, конечно, лучше.

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

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

Я бы не назвал это детскими страшилками.

Проглядел указатель на умерший объект и бам! неопределенное поведение.

Прочитал из неинициалированной переменной - бам! сам дурак.

Еще, например:

http://stackoverflow.com/questions/367633/what-are-all-the-common-undefined-b...

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

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

Проглядел указатель на умерший объект и бам! неопределенное поведение.

Ну если ТАКИЕ вещи учитывать, то да. (%

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

Большая часть убирается просто просмотром предупреждений компилятора.

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

Потому что теги в Emacs не работают :)

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

DarkEld3r ★★★★★
()

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

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

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

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

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

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

Подскажите, кто в теме, к какому из ML-ей сабж ближе? SML, [O]Caml, Haskell, ...?

Далек от всех. Грейдон Хоар, первый автор языка, окамльщик.

А Haskell вообще не из семейства ML.

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

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

Go для других задач вообще. Он медленней (в недалекой перспективе) и небезопасный.

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

А? Какие «ТАКИЕ»?

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

Вот анализатор времени жизни объектов в Ржавчине и концепция владения объектом на уровне языка - это реально работает.

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

Не на 100%, само собой, но все-таки намного эффективней.

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

Можно в таком случае тебя попросить: ты попробуй поддерживать мысль не отрицательными, а положительными аргументами. Я не питаю лишних иллюзий насчёт ржавого, но если ты пошлёшь ту правильную категорию размышлений — лояльность мне известна.

Да, я знаю для чего Go, мы с ним работаем полтора года и некоторые аспекты не так очевидны. И я примерно догадываюсь для чего ржавый: в том смысле — почему он не нужен.

Он медленней (в недалекой перспективе) и небезопасный.

Чушь. То, что происходит с go сейчас, разработчики называют косметическим ремонтом (я общался с Димой В.), — их задача стабилизировать синтаксис до крайнего предела простоты, а потом уже работа под капотом; там-то есть с чем работать.

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

Не, ну ML тут издалека чувствуется, чуть ли не больше чем си, значит не так уж далек. А в сети витают фразы типа «C meets Haskell».

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

разработчики говорили что к ocaml

Спасибо, так и думал почему-то.

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

Не, ну ML тут издалека чувствуется

От ML там let и match (ключевые слова, даже не синтаксис).

в сети витают фразы типа «C meets Haskell»

«C and haskell spent the night together which they both want to forget» (ц)

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

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

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

лишь бы помастурбировать

Фу, от одной мысли стошнило

я общался с Димой В.

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

Можно в таком случае тебя попросить: ты попробуй поддерживать мысль не отрицательными, а положительными аргументами. Я не питаю лишних иллюзий насчёт ржавого, но если ты пошлёшь ту правильную категорию размышлений — лояльность мне известна.

Вообще не могу понять, что ты тут написал. Не мог бы ты перефразировать?

... почему он не нужен.

И почему это сразу тут не написать?

Чушь. ...

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

Но к очевидной повышенной безопасности кода на Ржавчине, относительно Go, у тебя какие претензии?

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

От ML там let и match

Ну сходу, от ML там ADT, pattern-matching, вывод типов, иммутабельность по умолчанию, ФВП, expression-oriented syntax.

«C and haskell spent the night together which they both want to forget» (ц)

Речь о каком-то неудачном языке?

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

ML там ADT, pattern-matching, вывод типов, иммутабельность по умолчанию, ФВП, expression-oriented syntax.

Это общие фишки статически типизированных функциональных языков. Всё есть и, например... в Scala %) |А сложных вещей, отличающих именно современные ML и Ocaml - сигнатур, например, в Rust нет.

Речь о каком-то неудачном языке?

Просто шутка, которую я читал в около-Rust твиттере.

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

Понятно. Я не настолько их знаю, для меня они все ML, и Scala тоже )

Собственно, я и хочу поучить что-то из классики, отчасти - чтобы перейти к сабжу ближе к релизу.

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

Какие «ТАКИЕ»?

Нулевые указатели. Которые могут встречаться даже в менеджед языках... В расте удобно сделано, не спорю. Но как только мы сталкиваемся с «unsafe» фигнёй (сторонние либы, в том числе), то всё становится точно так же.

но на практике это только от поверхностых спасет.

Да ладно, далеко не только от поверхностных. Плюс если подключить статические анализаторы кода, то всё становится ещё лучше.

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

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

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

Что плохого в функциях типа «to_string»? Обобщённое программирование - это удобно.

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

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

Что там непонятного? Все логично и просто.

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

Значит плохо плюсы знаешь или мало на них писал, как мне видится.

Да постоянно пишу. Лет 15 примерно. Другие языки тоже активно использую, на языках вообще не зацикливаюсь, подбираю, что удобнее под задачу.

у меня аллергия на все эти java, c# и подобное.

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

Допустим, вот зачем (ссылка уже была но она тут подходит, как мне кажется)

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

Ты не можешь просто так взять и сказать «я не использую исключения, моя жизнь теперь прекрасна».

Делал так для ряда проектов. Но там же я отказывался еще от некоторых вещей(не из-за исключений).

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

Не прошло и 30 лет... хотя, до появления в стандарте может пройти и больше.

Ну а твой rust даже не вышел еще=)

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

сам дурак.

Видишь, ты сам все понимаешь=) Если серьезно, такие ошибки в нормальном коде сейчас крайне редки. Нужно набирать грамотную команду просто.

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

http://static.rust-lang.org/doc/master/std/fmt/trait.Show.html

Если я правильно понимаю, то «классы» должны будут внутри себя иметь интерфейс под это дело. Снаружи его расширить можно? То есть есть готовая структура/интерфейс, менять нельзя. Хочу добавить to_string. Возможно это?

Формат - это немного не то.

Ну и не вижу чем плоха возможность создавать, например, функции сложения («operator+(A, B)» в терминах С++).

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

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

Да постоянно пишу. ...

Ну тогда мы с тобой под «сложностью» понимаем разные вещи, раз ты не согласен, что С++ сложный до одури.

Ну scala совсем другая.

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

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

Ты статью не осил прочитать статью и хочешь краткое содержание? )

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

Религиозная ахинея. Есть инструмент и его нужно правильно использовать.

Не, я говорю не без толики фанатизма, конечно. Но стараюсь более-менее аргументировать свою точку зрения, если это не вопрос вкуса.

С++ - инструмент, да. Он худо-бедно справляется со своими задачами. Где-то лучше, где-то хуже. Так вот Ржавчина тоже инструмент, пускай и не настолько зрелый и доработанный, только лучше. И с теми же задачами она, как мне кажется, сможет справляться лучше и будет существенно проще в обращении.

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

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

Можно расширить снаружи (для типа из другого модуля), но только в рамках одного crait`а (до сих пор не знаю, как это по-русски называть, не «ящик» же :) ).

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

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

только в рамках одного crait`а

crate-а

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

Общепринято «крейт».

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

милаша Go

А генерики туда запилить так и не осилили, да?

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

Что там непонятного?

Кто говорил о «непонятном»?

Все логично и просто.

Брейнфак тоже логичный и простой.

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

Да как она может справится с теми же задачами, если там нет ни полноценного ООП(с нормальным наследованием, хотя бы), ни исключений, ни шаблонов, ни совместимости с Си? Язык-то может и неплохой, может даже найду и сам для него задачи, когда выйдет. Но заменить плюсы он не в состоянии. Сравни со скалой, которая может все, что может java, но гораздо лучше, плюс ещё имеет ряд возможностей.

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

наследование

Активное использование наследования это спорная штука. У тебя есть trait`ы - берешь и используешь их.

исключений

Берешь и работаешь с Option и Result, никаких проблем.

шаблонов

В ржавчине есть нормальные дженерики, причем с ограничениями. В С++ это давно хотят затолкнуть, но не могут. Есть нормальные макросы, а не нечто, доставшееся от Си. И есть процедурные макросы, которые дают возможность сделать что угодно во время компиляции.

ни совместимости с Си

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

Пример:

https://github.com/mozilla-servo/rust-stb-image/blob/master/stb_image.c

https://github.com/mozilla-servo/rust-stb-image/blob/master/stb_image.rs

как она может справиться ... ?

Из всех применений плюсов больше всего меня интересуют игры. Там плюсы - стандарт для низкоуровневого кода. Я потихоньку пишу небольшую игру - github.com/ozkriff/marauder - на Ржавчине. И почему я не смогу этого сделать? Почему меня ждут непреодолимые сложности?

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

В низкоуровневом языке вполне может быть нормальная модульность, сборка мусора и много чего ещё. Это доказал пример Оберона, на котором вполне себе написали ОС, современную и производительную для своего времени.

Нихрена он не доказал. Вот на Java тоже операционка написана, и чо, сильно она низкоуровневая? http://ru.wikipedia.org/wiki/JavaOS

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

Вот на Java тоже операционка написана ...

Разве у java ноги не из Оберона растут?

... разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона и, в частности, исходные коды обероновских сборщиков мусора. Потом они испортили Оберон синтаксисом Си и назвали получившееся словом Java» ...

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

Твои «спорные штуки» - это то, что давно и с пользой использует индустрия. Я не вижу причин отказываться от наследования, исключений и пр. Я знаю, что можно использовать что-то другое и даже использую, когда надо. И в плюсах и в скале есть и исключения и option-типы.

Дженерики шаблонами никогда не станут. Ограничения там совсем другие, чем в плюсах вести хотят(концепты), сравнивать некорректно.

Игру свою пили на ржавчене. Сейчас и на явах/шарпах с питонами игры пишут, никаких проблем у тебя не будет, скорее всего. Вряд ли ты пишешь такую игру, где тебе понадобился бы C или C++.

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