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 ()

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

У них же на сайте про тойоту написано: http://www.adacore.com/customers/toyota-itc-japan/

«High-Reliability Vehicle Component Research Project» - это даже не вся Тойота и точно не вся автомобильная индустрия.

http://spectrum.ieee.org/riskfactor/aerospace/aviation/software-testing-probl...

Ну, срыв сроков и перерасход средств - дело обычное: http://www.defensenews.com/article/20110519/DEFSECT05/105190304/F-22-Upgrade-...

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

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

Да чего там, вероятнее на 100% переписан! Даже на 200%, так еще вероятнее!!1

Что там в ядре языка на 90% процентов перепишут по-твоему?

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

он будет изменён приблизительно процентов на девяносто

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

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

у рэптора весь софт был на Аде написана и работал без проблем

Цитирую:

Как сообщает Flight Global, программный сбой на неделю задержал перебазирование новейших истребителей 5 поколения F-22 Raptor из США в Японию. Ошибка была отмечена в навигационном обеспечении самолета.

И это уже на серийном самолёте.
Так что от быдлокода даже Ада не спасёт.

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

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

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

Как-то затянулось всё. Я, конечно, понимаю, они ответственно подходят к этому, но тем не менее.

Safort ()

вы спятили?

Палец об сенсор затер, пока пролистывал этот нердолог.

Any ()

использование старых по умолчанию выдает предупреждения:
...
Camel Case типы;
...
Типы, такие как 'BufferedReader'

(и ещё несколько подобных названий типов, все лень копипастить)

Т.е. они не только указывают другим, в каком стиле надо называть типы данных, но сами же эти указания нарушают? Шикарно!

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

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

не только указывают другим, в каком стиле ... Шикарно!

Единый стиль оформления для всего кода это разве плохо? Скорей бы rustfmt (по аналогии с gofmt) запилили.

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

Единый стиль оформления для всего кода это разве плохо?

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

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

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

Это не уровень языка, а отключаемое предупреждение lint.

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

Умозрительная несостоятельность

В одном месте, ок; если хоть как-то последить за процессом развития go, становится ясно, что ребята больше ударяются в первопричину яп: решают вопросы удобства и скорости компиляции, по части сложилась работа над сборщиком — и тут тоже ожидаются отрадные достижения, если веровать во Вьюкова.

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

anonymous ()
Ответ на: Умозрительная несостоятельность от anonymous

Покуда над перформансом особо не работали

За все 5 ktn после релиза и хрен знает сколько лет до него? Кул стори, бро.

единственной его киллер-фиговиной как таковой разрекламировали легендокапец.

Щито?

P.S. «The performance of code compiled with the Go 1.1 gc tool suite should be noticeably better for most Go programs. Typical improvements relative to Go 1.0 seem to be about 30%-40%, sometimes much more» — ну да, просто вообще никакой работы по увеличению производительности.

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

А тут http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=g... все выглядит лучше)

Вообще это уже поднималось там и сям:

http://www.reddit.com/r/rust/comments/1xcq1q/c_gcc_vs_rust_wtf/cfa5oyv

For a better indication of Rust's performance (i.e. a test that avoids libraries that need dramatic improvement (or just replacement with FFI bindings to the best-in-class library: GMP)), I'll bring your attention to fasta, where Rust is 3rd overall. And, since just being third isn't good enough, the program has no unsafe code in it (even better than the Haskell).

Так вот, если судить по более адекватному в данном случае fasta, то отставаний от си и плюсов ожидаемо нет (при том, что код без unsafe секций):

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=fasta&lang...

с учётом того, что единственной его киллер-фиговиной как таковой разрекламировали легендокапец

Чего?

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

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

Ну ведь это не суть целенаправленное увеличение производительности, это вот те самые, - как сказал анон,- «правильные места и решения». Сравни подход ржавчины и убедись, лiл.

// кто-то другой

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

Ну ведь это не суть целенаправленное увеличение производительности

Это суть оно.

Сравни подход ржавчины и убедись, лiл.

Опиши мне подход Rust к увеличению производительности - я сравню его с тем, что вижу в дискуссиях rust-dev@

tailgunner ★★★★★ ()

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

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

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

Отнеси чушь на место.

tailgunner ★★★★★ ()

Чот пример с сайта не компилится

use std::io;

for line in io::stdin().lines() { print!(«{}», line.unwrap()); }

Выдает это: >rustc main.rc main.rc:3:1: 3:4 error: expected item but found `for` main.rc:3 for line in io::stdin().lines() {

Не подскажет ли кто из знающих в чём причина ошибки? З.Ы. мучаю Раст под шиндошс.

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

Да, точно, что-то сглупил) Спасибо. Но это не сильно помогло, т.к. теперь показывается это:

task '<main>' failed at 'called `Result::unwrap()` on an `Err` value', C:\bot\sl
ave\dist2-win\build\src\libstd\result.rs:187

Похоже, раз я такой криворукий, то мне придётся ждать стабильную однушку ;(

Safort ()
Ответ на: комментарий от Safort
$ cat test.rs 
use std::io;
fn main() {
        for line in io::stdin().lines() {
                print!("{}", line.unwrap());
        }
}
$ rustc test.rs            
$ echo "1\n2\n3\n" | ./test
1
2
3

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

Мне думается, что 1.0 тут не поможет.

Можешь полностью показать код, как ты его собираешь и как ты ты его запускаешь (что идет в stdin)?

ozkriff ()

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

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

С чего там офигевать? Подход немного непривычный, но на деле работает вполне себе хорошо. Особых недостатков я не вижу, просто дело привычки и вкусовщина.

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

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

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

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

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

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

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

Да, сомнительное решение. Кстати, а нафига двоеточие в параметрах функции? По-моему, читабельности это не прибавило.

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

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

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

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

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

Это был тэйлганнер. И его проблема сложной области.

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

Кажется, тут тэйлганнер отвечает сам себе. История развивается, мы следим за событиями.

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

Ну, и че ты там развил, велосипедостроением своим? Умение строить велосипеды? Молодец, че.

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

Вот сам код:

use std::io;

fn main() {

  for line in io::stdin().lines() {
    print!("{}", line.unwrap());
  }

}

А этой командой компилирую: rustc main.rc

Бинарик компилируется, а при запуске выдаёт ошибку, которую я написал выше. Забыл предупредить, я гуманитарий обычно работающий с фронтэндом, мб дело в этом?))

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