LINUX.ORG.RU

Rust 1.14

 


1

6

Представлен релиз Rust 1.14 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода. В этот релиз вошли 1230 патчей.

Самое большое изменение в Rust 1.14 не связано с языком или компилятором: rustup достиг версии 1.0 и теперь является рекомендуемым способом установки Rust. Rustup предоставляет такие возможности, как установку Rust из официальных каналов, возможность обновления и переключения между стабильным, бета и ночным версиями компилятора, упрощение кросс-компиляции с бинарными сборками стандартной библиотеки под распространенные платформы. И, конечно, rustup работает на всех платформах, которые поддерживает Rust, включая Windows. Подробнее о rustup можно прочитать в официальном блоге или на странице GitHub.

Другая интересная новинка, это экспериментальная поддержка WebAssembly в качестве новой цели сборки, wasm32-unknown-emscripten. Поддержка находится на раннем этапе, поэтому разработчики просят помочь в тестировании и сообщать им о найденных ошибках. С установленным emscripten компиляция кода на Rust в WebAssembly выглядит следующим образом:

$ rustup target add wasm32-unknown-emscripten
$ echo 'fn main() { println!("Hello, Emscripten!"); }' > hello.rs
$ rustc --target=wasm32-unknown-emscripten hello.rs
$ node hello.js
Сообщество экспериментирует и делает интересную работу в этой сфере: некоторые примеры можно посмотреть на слайдах (Jan-Erik) с семинара Rust Belt Rust или классический проект TodoMVC (Tim Ryan) как пример, построенный на библиотеке webplatform (позволяет работать с DOM в Rust).

Касательно платформ, большое количество платформ получило дополнительную поддержку:

Для rustc:

  • mips-unknown-linux-gnu
  • mipsel-unknown-linux-gnu
  • mips64-unknown-linux-gnuabi64
  • mips64el-unknown-linux-gnuabi64
  • powerpc-unknown-linux-gnu
  • powerpc64-unknown-linux-gnu
  • powerpc64le-unknown-linux-gnu
  • s390x-unknown-linux-gnu

И для std:

  • arm-unknown-linux-musleabi
  • arm-unknown-linux-musleabihf
  • armv7-unknown-linux-musleabihf

Если вы используете одну из вышеперечисленных платформ, то следуйте инструкции по установке на сайте или добавляйте цели к текущей установке при помощи команды rustup target add.

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

Как и в примере работы сообщества над новой целью WebAssembly, в Rust на подходе другие, не менее примечательные, кроме вышеперечисленных, цели. Например, xargo упрощает кросс-компиляцию Rust для работы на голом железе. Если вы пишете операционную систему на Rust, или делаете что-то интересное на микроконтроллере, xargo может очень сильно облегчить вашу жизнь.

С появлением поддержки MIR в последних релизах, также продолжается работа над улучшением времени компиляции.

В языке появилось маленькое улучшение: поддержка RFC 1492. При помощи этого маленького улучшения увеличились места, где можно использовать ... Допустим, у вас есть структура:

struct Point {
    x: i32,
    y: i32,
    z: i32,
}
В любом контексте, где вы делаете сопоставление с образцом, вы могли использовать .., чтобы проигнорировать места, которые вам не интересны. Например:
let p = Point { x: 0, y: 1, z: 2 };

match p {
    Point { x, .. } => println!("x is {}", x),
}
.. игнорирует y и z.

Рассмотрим похожий Point, но в качестве структуры кортежа:

struct Point(i32, i32, i32);
Ранее, вы могли использовать .., чтобы проигнорировать все три элемента:
let p = Point(0, 1, 2);

match p {
    Point(..) => println!("found a point"),
} 
Но вы не могли использовать его, чтобы игнорировать часть кортежа:
let p = Point(0, 1, 2);

match p {
    Point(x, ..) => println!("x is {}", x),
}
Это привносило противоречивость, и теперь, когда RFC 1492 стабилизирован, в этом релизе всё замечательно компилируется. Это относится ко многим ситуациям кроме кортежей; для подробностей смотрите RFC.

Стабилизация библиотек

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

Более подробный список изменений.

Возможности Cargo

В Cargo был реализован RFC 1721. Cargo теперь будет передавать значение вывода команды rustc --print cfg сборочным скриптам. Мотивацией для этой функции послужила возможность Cargo компилировать объекты для статической компоновки с msvcrt под платформой MSVC.

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

Cargo теперь будет игнорировать конфигурацию panic для профилей test и bench. Это важно, так как человек запустивший тесты полагается на панику как непрошедший тест, и со значением panic=abort, непрошедший тест отменит весь набор тестов.

Более подробный список изменений.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: dotcoder (всего исправлений: 1)

Кто пробовал писать сайты на Rust — удобней, чем на JavaScript? Уже можно и фронтэнд и бэкэнд писать.

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

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

можно и фронтэнд
Другая интересная новинка, это экспериментальная поддержка WebAssembly

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

Вообще пишут, вроде не жалуются. У самого есть один проект, сейчас вот ещё один пилю. Брат жив, зависимость есть.

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

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

Почему? Не встречал ситуаций, в которых мне был бы удобней динамический язык. Чем веб-разработка тут может выделяться?

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

Очень толсто. А выделяется она тем, что здесь нyжно иметь возможность раз-раз и быстро что-то подправить. А не ждать полчаса перекомпиляции.

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

А выделяется она тем, что здесь нyжно иметь возможность раз-раз и быстро что-то подправить. А не ждать полчаса перекомпиляции.

И для чего эта возможность нужна (и не нужна в других областях)? GUI-приложения, например, пишут в основном на C, C++, C#, а не на JavaScript и как-то переживают.

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

Legioner ★★★★★
()

А вот интересно мнение самих Rust-оманов: а настолько частые релизы вам нравятся или нет? Создает ли это какие-то проблемы?

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

Дурак? В .NET на лету все компилируется. Файлы менять можно прямо на сервере.

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

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

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

А вот интересно мнение самих Rust-оманов: а настолько частые релизы вам нравятся или нет? Создает ли это какие-то проблемы?

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

А тем, кому пообсуждать, частые релизы — благо. Пережёвывать одни и те же темы каждый раз как в первый раз.

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

Пока фичи добавляются, а старый код не ломается, не о чём и флеймить.

Ну вот, например, ситуация. Вася Пупкин делает модуль X, используя Rust-1.10. И в модуле X использует модуль Y от Феди Иванова. А Федя Иванов для Y уже перешел на Rust-1.13. Причем перешел так, что и баги фиксит, и новую функциональность добавляет исключительно в новых версиях, которые на Rust-1.13. А на более старые версии Rust-а Феде насрать.

Как быть Васе, если у него по каким-то причинам нет возможности пересесть на Rust-1.10?

Или на Rust-е пока не так много написано, чтобы это стало проблемой?

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

Как быть Васе, если у него по каким-то причинам нет возможности пересесть на Rust-1.10?

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

Я вижу две. Вася пользуется каким-то багом старой версии компилятора, устраненной в новых. Вася использует сторонний компонент (не с crates.io), требующий бинарной совместимости со старой версией раста.

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

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

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

Или на Rust-е пока не так много написано, чтобы это стало проблемой?

(Я кроме «Hello, world!» ни строчки на Rust не написал.)

Подозреваю, что можно сделать бинарную сборку компонента, завернув всё в статическую или динамическую библиотеку, а API сделать через адаптер. Исходник адаптера навряд ли будет использовать какие-то новомодные фичи. По крайней мере, я бы делал так, я привык к такому в C/C++.

i-rinat ★★★★★
()
Ответ на: комментарий от red75prim

Какие, кстати, причины могут быть?

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

eao197 ★★★★★
()
Ответ на: комментарий от i-rinat

Extended Support Release, по аналогии с Firefox ESR.

И чем это поможет Васе, если он будет на ESR, а Федя на самых свежих релизах?

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

А вот интересно мнение самих Rust-оманов: а настолько частые релизы вам нравятся или нет? Создает ли это какие-то проблемы?

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

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

Допустим, Вася пилит приложение на C++ 11, и хочет использовать компонент Феди, который на OCaml. Как поступит Вася?

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

i-rinat ★★★★★
()
Ответ на: комментарий от red75prim

В плюсах не так быстро все меняется и развивается, как в Rust-е. Далеко не все бегут впереди паровоза и используют C++17. А уж если посмотреть в мир Java, там все еще суровее. Но и проще, отчасти.

eao197 ★★★★★
()
Ответ на: комментарий от i-rinat

Допустим, Вася пилит приложение на C++ 11, и хочет использовать компонент Феди, который на OCaml. Как поступит Вася?

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

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

Понятно.

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

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

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

А какие могут быть проблемы? Разве что сломают обратную совместимость, но это редкость.

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

Или на Rust-е пока не так много написано, чтобы это стало проблемой?

this

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

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

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

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

Там все сложнее. Мы, например, одним проектом занимались, там C++14, но в объеме, доступном в gcc-5.4. В другом проекте C++11, но в объеме, доступном в gcc-4.8.

Ну и да, есть случаи, когда на C++11 не переходят. Но там просто заказчику объясняешь, что это дороже, а будет и еще дороже.

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

Ну вот в Ubuntu 16.04 - rust 1.7. Все кто в 1.13 перешел с try! на ? уже убили совместимость.

Меня это мало волнует, ибо проще собрать статичный бинарь с musl, но тем не менее.

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

Они гибче, приходится писать меньше кода. Ну и как уже сказали, ненужно компилять, что значительно упрощает по крайней мере отладку.

Это какие-то абстрактные аргументы. Почему весь мир не перешёл на JavaScript? Всем хочется быть гибче, писать меньше кода, значительно упрощать отладку.

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

Результат — не код, а работающий продукт. Этот результат не всегда достигается минимумом кода. Ты можешь написать 1000 строк на JS за 20 часов и потом 40 часов их отлаживать или написать 1200 строк на Java за 24 часа и потом 12 часов их отлаживать. Результат будет быстрей достигнут во втором случае.

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

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

Вы стенографистка? Скорость написания больших объемов кода не имеет никакого отношения к разработке.

RazrFalcon ★★★★★
()

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

это так, к слову про оптимизацию раста - там еще есть куда расти

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

extern crate num;

То есть, библиотека сторонняя. И тем не менее, претензии не к реализации конкретной библиотеки, а к самому языку. Л — логика!

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

То есть, библиотека сторонняя.

да мне без разницы, сторонняя это библиотека или не сторонняя
я добавляю в dependencies
num = «0.1

и раст - сам - закачивает и собирает эту библиотеку

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

и раст - сам - закачивает и собирает эту библиотеку

Ого! Не иначе как новогоднее чудо!

Safort
()

зачем ты вытащил это говно?

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

Сорцы вы конечно же не предоставите.

лехко
гоу:

    a := big.NewInt(0)
    b := big.NewInt(1)
    var limit big.Int
    limit.Exp(big.NewInt(10), big.NewInt(20900), nil)
    for a.Cmp(&limit) < 0 {
        a.Add(a, b)
        a, b = b, a
    }

extern crate num;
use num::{BigUint, Zero, One};
use std::mem::replace;
extern crate time;
use time::PreciseTime;

// Calculate large fibonacci numbers.
fn fib(n: usize) -> BigUint {
    let mut f0: BigUint = Zero::zero();
    let mut f1: BigUint = One::one();
    for _ in 0..n {
        let f2 = f0 + &f1;
        // This is a low cost way of swapping f0 with f1 and f1 with f2.
        f0 = replace(&mut f1, f2);
    }
    f0
}

// This is a very large number.

fn main() {
    let start = PreciseTime::now();
    println!("fib(100000) = {}", fib(100000));
    let end = PreciseTime::now();
    println!("{} seconds ", start.to(end));
}


kto_tama ★★★★★
()
Последнее исправление: kto_tama (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.