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

Предпочитаешь match? Тоскуешь по инопланетному ?:? Или что-то более странное? :)

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

Ну например вернуть 500 на попытку соединения на веб-сервере

У Вас нет свободной памяти, чтобы создавать объекты.
P.S. И я бы хотел не вдаваться в детали, а в целом показать, что механизм экзепшенов - совсем не серебряная пуля.

void_ptr ★★★★
()

Кстати, о.
Поднимая старую тему Go vs Rust можно посмотреть свежие результаты и увидеть, что почти во всех случаях Rust обгоняет Go
Плюсы он конечно ещё не догнал Но тенденция намечается.

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

Ну почему же, это круто. Кто бы запилил язык, где бы всякий математический мусор ('<', '>', '{', '}', '+', '(', ')', '%' etc.) не был бы частью языка. Математика уже давно по факту используется ну может в 0.001% софтварных проектов, и то, на уровне базовой алгебры, и казалось бы, не должно это быть это частью языка (стандартной библиотеки — может быть, но не частью синтаксиса), ибо делает код нечитабельным, ан нет тащат везде, как священную корову.

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

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

Я рекурсивные числа фибоначчи считал недавно. На C получилось почти в 2 раза быстрее. С одной стороны это хорошая скорость, с другой стороны если они так близки к железу, чего это примитивная рекурсия так тормозит? Там же особо оптимизировать нечего, return n <= 1 ? n : f(n - 1) + f(n - 2), по сути тестируется адекватность выдаваемого кода.

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

Rust:

fn fib(n: int) -> int {
    if n <= 1 { n } else { fib(n - 1) + fib(n - 2) }
}
fn main() {
    let n = 45i;
    println!("fib({}) = {}", n, fib(n));
}
% rustc -O fibrs.rs
% time ./fibrs
fib(45) = 1134903170
./fibrs  10.00s user 0.01s system 99% cpu 10.017 total

C:

#include <stdio.h>

int fib(int n) {
    if (n <= 1) { 
      return n; 
    } else { 
      return fib(n - 1) + fib(n - 2);
    }
}

int main(void) {
    int n = 45;
    printf("fib(%d) = %d\n", n, fib(n));
    return 0;
}
% clang -O2 -o fibc fibc.c
% time ./fibc
fib(45) = 1134903170
./fibc  7.97s user 0.00s system 99% cpu 7.979 total

Про 2 раза соврал, извиняюсь, вчера компилировал без оптимизации, оказывается. 25% разница, это уже неплохо.

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

Про 2 раза соврал, извиняюсь, вчера компилировал без оптимизации,

~$ rustc --opt-level 3  a.rs
~$ time ./a
fib(45) = 1134903170

real    0m7.739s
user    0m7.727s
sys     0m0.004s

~$ gcc-4.9 -march=native -Ofast a.c
~$ time ./a.out 
fib(45) = 1134903170

real    0m3.951s
user    0m3.947s
sys     0m0.000s
anonymous
()
Ответ на: комментарий от anonymous

А что не так?
То что они там напрямую в коде вызывают GMP?
Ну так видать нет в стандартной библиотеке поддержки, вот и пользуют сишную.
Кстати неплохой пример использования сишных функций.

WatchCat ★★★★★
()
Ответ на: комментарий от anonymous
$ rustc -O fibrs.rs
$ time ./fibrs
fib(45) = 1134903170

real    0m12.110s
user    0m12.117s
sys     0m0.001s
$ gcc -O3 -march=native -ofibc fibc.c
$ time ./fibc
fib(45) = 1134903170

real    0m7.229s
user    0m7.233s
sys     0m0.000s

rustc 0.13.0-nightly (adb44f53d 2014-10-12 00:07:15 +0000)
gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)

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

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

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

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

а что нет к ней удобного интерфейса,

А чем имеющийся неудобен?
Вызов сишных в блоке unsafe?
Или тем что в либе на самом деле нет никакой mpn_mul, а есть макро разворачивающееся в __gmpn_mul?
Ну так тут особенности сишечки и данной либы.

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

А чем имеющийся неудобен?

Ты серьезно? На С++ с gmp, например, можно написать так:

abs( a ) * ( b + 10 ) / sqrt( c ) + log( d )

А тут сплошное:

self.tmp1.mul_ui(&self.num, nth);
self.tmp2.add(&self.tmp1, &self.acc);
self.tmp1.tdiv_q(&self.tmp2, &self.den);
anonymous
()
Ответ на: комментарий от anonymous

Ну почему же, это круто.

Дело вкуса, по всей видимости.

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

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

На С++ с gmp, например, можно написать так:

Теоретически, в Rust тоже. Почему так не сделали - не понимаю.

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

В Ржавчине оно есть - http://rustbyexample.com/ops.html, просто в данной программе не реализовали перегрузку операторов для Mpz. В конце концов, это же не полноценная библиотека-обертка для gmp и математики с этим Mpz тут на десяток строчек всего.

А вообще, перегрузка операторов - очень спорная штука. Как по мне, кстати, я бы не то что перегрузку операторов, я бы вообще математические операторы из языков общего назначения нафиг выкинул, нечего синтаксис загрязнять.

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

В конце концов, это же не полноценная библиотека-обертка для gmp и математики с этим Mpz тут на десяток строчек всего.

Вообще rust тут по сути только мешает, т.к. решение на С в три раза меньше по коду. А чтоб он не мешал - и нужна «полноценная библиотека-обертка», которую заодно можно и замерять, вместо кода сишной библиотеки.

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

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

Пользуйся схемкой, чо.

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

А чтоб он не мешал - и нужна «полноценная библиотека-обертка»

Гугл выдал https://github.com/thestinger/rust-gmp, она даже регулярно обновляется. Там есть перегрузка операторов.

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

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

На С++ с gmp, например, можно написать так:

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

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

Ты в курсе, что на плюсах всего лишь интерфейс к libgmp?

Несомненно, он, кстати честно и меряется, а ведь можно было скопипастить сишный код и просто собрать g++.

Тебе никто не мешает написать

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

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

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

Нука-нука.
Покажи ка как в твоём случае должен выглядить такой вот код:

xn = fmod( 4.5236020 - 9.2422029e-4 * ( epoch + 18261.5 + tc / 1440.0 ), twopi );
Без арифметических операторов, только на вызовах функций.

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

Какой-то поток бессознательного от анонимуса.

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

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

Идите в жопу со своим лиспом.

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

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

Я-то всё понял.
Суть твоих претензий к Rust'у в том, что у него в стандарте нет интерфейса к libgmp.
Так вот, мой недалёкий анонимный друх, в стандарте плюсов тоже нет интерфейса к libgmp.
Более того, libgmp не входит в стандарт C.
А твоё поведение всего лишь способ до2.7182ться, не имея обоснованных претензий.

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

Я-то всё понял. Суть твоих претензий к Rust'у в том, что у него в стандарте нет интерфейса к libgmp.

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

Так вот, мой недалёкий анонимный друх, в стандарте плюсов тоже нет интерфейса к libgmp.

Я тебе даже больше скажу, honey, в плюсах из стандартной библиотеки зачастую используется лишь небольшая часть, а остальное (даже контейнеры и строки) подбирается под задачу.

А твоё поведение всего лишь способ до2.7182ться, не имея обоснованных претензий.

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

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

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

Перестань пороть чушь и натягивать сову на глобус.

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

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

Это по типу «Сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать.», да?

Тебя случайно не Кличко зовут?

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

Хм, а почему это было обращено анонимному, а не мне, раз цитата моя? )

Покажи ка как в твоём случае должен выглядить такой вот код

xn = fmod( 4.5236020 - 9.2422029e-4 * ( epoch + 18261.5 + tc / 1440.0 ), twopi );

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

let xn = fmod(
    mul(
        sub(4.5236020, 9.2422029e-4),
        add(epoch, 18261.5, div(tc, 1440.0)),
    ),
    twopi
);

Ну или лиспообразное чего-нибудь, да:

(set! xn (fmod
    (mul
        (sub 4.5236020 9.2422029e-4)
        (add epoch 18261.5 (div tc 1440.0)))
    twopi)

Чего ты так агришься на упоминание (л(и)сп(())а)? Он тебе плохо сделал?

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

Я б не сказал, что это верх удобства:

Сделают когда-нибудь Mpz::new_int

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

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

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

Но конкретно про эти строчки - это к создателям библиотеки.

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

Чего ты так агришься на упоминание (л(и)сп(())а)? Он тебе плохо сделал?

Из всех фанбоев лисперовские самые упоротые.
Кроме того, мне лисп не нравится.
Он оскорбляет моё чувство прекрасного.

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

Хм, а почему это было обращено анонимному, а не мне, раз цитата моя? )

Не туда ткнул.

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

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

Ты хочешь с этим посморить? Или не понимаешь, что твое «никто не мешает написать» не делает частное конкретное решение хоть сколько-нибудь лучше?

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

Из всех фанбоев лисперовские самые упоротые.

Думаешь, в этом языке что-то магическое, что привлекает особенно «увлеченных»?

Он оскорбляет моё чувство прекрасного.

Скобками? Блин, никогда этого не понимал. Это же из категории:

«На петухоне песать штоле? Там нет фигурных скобок, буэ, никагда»

«Ой, я не хочу учить C++ или Java, там эти скобки неприятные, я лучше на дельфи дальше лабать буду.»

«Lua? Фуу фу фу, это же как паскаааль! Я не могу песать на языке, в котором везде end и нет моих прекрасных {}!»

Как синтаксис может быть фатальным недостатком языка? Я прекрасно понимаю, как можно ненавидеть языки, но не только за синтаксис же, блин. Это как-то настолько поверхностно, что у меня о человеке сразу очень плохое мнение складывается.

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

Думаешь, в этом языке что-то магическое, что привлекает особенно «увлеченных»?

Не знаю, но факт остаётся фактом.

Скобками?

И ещё префиксностью.
Вернее возведением её в абсолют.

Как синтаксис может быть фатальным недостатком языка?

А почему бы тогда не писать на брейнфаке?

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

Как синтаксис может быть фатальным недостатком языка? Я прекрасно понимаю, как можно ненавидеть языки, но не только за синтаксис же, блин.

Потому что мне писать программы и я не хочу продираться через тучи скобок.

Это как-то настолько поверхностно, что у меня о человеке сразу очень плохое мнение складывается.

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

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

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

С тобой, кто не может внятно выразить свою мысль?

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

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

Я тебе ответил по существу.

Без проблем, главное не переживай по этому поводу, все хорошо.

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