LINUX.ORG.RU

Rust 1.11

 


1

5

Команда разработчиков Rust рада представить релиз Rust 1.11. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме.

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

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

  • Большая часть изменений касалась пока ещё нестабильных внутренностей компилятора. Началась работа над инкрементальной компиляцей и переходом на MIR. В этом выпуске были заложены основы для этих возможностей.
  • В выпуске 1.10 был введён новый формат контейнеров cdylib, который используется при компиляции кода на Rust для встраивания в другие языки. До этого момента поддержка cdylib была реализована только в компиляторе, теперь эта возможность стала доступна и в Cargo.
  • В стандартной библиотеке изменилась функция хэширования по умолчанию с SipHash 2-4 на SipHash 1-3.

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

  • В BinaryHeap, BTreeMap, и BTreeSet добавлен метод append.
  • В BTreeMap и BTreeSet добавлен метод split_off.
  • Методы to_degrees и to_radians ранее были реализованы для f32 и f64 в libstd, теперь они также доступны в libcore.
  • В Iterator добавлены два новых метода: sum и product.
  • Cell и RefCell получили метод get_mut.
  • assert_eq!, как и assert!, теперь принимает пользовательское сообщение об ошибке.
  • Главный поток теперь называется “main” вместо “<main>”.

Cargo

  • Добавлена поддержка цвета для Windows-консолей, и вы можете теперь конфигурировать цвета для stderr так же, как и для stdout.
  • Скрипты сборки теперь могут выдавать предупреждения.
  • Как было упомянуто выше, добавлена поддержка cdylib-контейнеров.
  • Cargo теперь предотвращает публикацию контейнеров при наличии изменённых файлов или файлов, которые не являются частью рабочего дерева.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Kilte (всего исправлений: 9)
Ответ на: комментарий от RazrFalcon

Не всегда. Однажды я столкнулся с тем, что он в кое-каком случае не может обработать #[derive(Clone)], хотя это вполне реально. В ирке сказали, что надо написать реализацию вручную, несмотря на то, что она тривиальна (обычное и вполне безопасное копирование содержимого структуры).

Deleted
()

Сложно и в целом неоправдано.

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

Bundled dependencies - обычное дело же

Значит ли это, что я могу не утанавливать эти сорцы? Как это вообще разруливается? Опциями cargo install?

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

Для каждого проекта собираются отдельно + статическая линковка = никаких либ

Оу, не знал что статическая

$ du -h racer
34M	racer

Динамическая не подерживается?

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

Не понял. Есть пакеты, которые интерфейсятся к системному sqlite. Если системный sqlite не устраивает - используешь это.

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

Динамическая не подерживается?

Подерживается. Но ABI не стабильный.

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

Пока что на свой страх и риск. К счастью, смысла особо нет, ибо бинарь всё равно не превышает пару МиБ.

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

А, понятно, по-умолчанию динамически связываются с установленным в системе

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

За этим будет следить разработчик. Карго пишет, что он качает и собирает.

$ cargo install game2048
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading game2048 v0.0.5
 ...
error: failed to compile `game2048 v0.0.5`, intermediate artifacts can be found at `/tmp/cargo-install.CdJgvMy4BuVi`

Caused by:
  native library `SDL2` is being linked to by more than one version of the same package, but it can only be linked once; try updating or pinning your dependencies to ensure that this package only shows up once

  sdl2-sys v0.6.2
  sdl2-sys v0.8.1

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

v0.0.5
Build Status: Error в репе

Какие еще претензии?

Ну и в репе у него как раз «*», о которых я писал. Ясное дело, что криворукие всегда будут.

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

Никаких претензий. Просто непонятно было

makoven ★★★★★
()

Вот в джаве, чтобы типу задать строковое представление, достаточно переопределить toString.

public String toString() { return «123»; }

Запоминать практически ничего не нужно. Если совсем туго, то выручит IDE.

Что с этим в расте? Когда пытался его выучить, понял, что быстро писать на нём не получится из-за того, что нужно слишком много держать в голове или постоянно заглядывать в документацию. Вменяемые средства разработки отсутствуют. Ни о какой продуктивности и речи быть не может.

Даже в C++ проще с этим...

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

Повменяемей чем в крестах, местами (автокомплитом, например). Еще там отсутствует десяток дико распространенных и как на подбор невменяемых систем сборок, большой плюс (минус (плюс)).

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

Повменяемей чем в крестах, местами (автокомплитом, например)

Пользуюсь eclipse + racer, не сказал бы что он вменяемей чем в QtCreator + clang. Наоборот, достаточно часто автокомплит для раста фейлит.

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

Я сравнивал с emacs + racer и QtCreator (дефолтный). Когда последний раз включал Clang Code Model он каким-то дико сырым был, а дефолтный хоть и хреново работает (фейлит на простейших темплейтах) хоть не анноил дикими лагами и попытками ВСЕ СПАРСИТЬ ЗАНОВО, с отваливающийся подсветкой и всем таким.

Сейчас включил: вроде получше, но парсит таки медленно (с boost-ом).

Правда я не осилил найти где flycheck вырубить. Он плюется еггогами (и ПОДЧЕРКИВАЕТ КРАСНЕНЬКИМ!!1) на всякое вроде:

const auto args_tuple = hana::make_tuple(args...);
И нет, он осилил найти декларацию make_tuple, но не осилил заглянуть в make, а потом в make_t.
constexpr auto make_tuple = make<tuple_tag>;
template <typename Tag>
constexpr make_t<Tag> make{};
Такое.

Еще он в doxygen не умеет.

P.S. А, это он о флагах компилятора ничего не знает, дописал -std=c++14 - перестал красным светить.

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

И в чем польза ржавого, если оно напичкано unsafe?

Не используй unsafe и будет тебе польза. Очевидно же.

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

Я как раз боюсь, что cargo будет пытаться подменять собой дистрибутивные менеджеры пакетов

В этом нет ничего плохого: вот, допустим, что происходит в Java: в то время как в дистрибутиве будут заниматься всякой фигней типа перепаковывания jar'ов из Maven'а, а потом вообще плюнут на это дело (привет, Fedora!), сам проект будет в Maven стабильно релизиться.

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

Я как раз боюсь, что cargo будет пытаться подменять собой дистрибутивные менеджеры пакетов

В этом нет ничего плохого

Я не разделяю это неправильное мнение.

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

Я не разделяю это неправильное мнение.

Уж извините, но в Fedora «правильное мнение» [при упаковке NetBeans и IntelliJ IDEA CE в репозиторий дистрибутива] разбилось о реальность, поэтому надо еще посмотреть, что на самом деле является «неправильным».

X-Pilot ★★★★★
()

Было бы здорово, если бы GTK на Rust перевели, наверно. И причесали заодно.

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

P.S. А, это он о флагах компилятора ничего не знает, дописал -std=c++14 - перестал красным светить.

Он использует настройки проекта, если ты там не указал стандарт/флаги - то это не его вина. И автокомплит для std::tuple прекрасно работает:

http://i.piccy.info/i9/ed2177a57a219ef2190bd3fa5d4a3051/1471724359/38267/1048...

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

в Fedora «правильное мнение» [при упаковке NetBeans и IntelliJ IDEA CE в репозиторий дистрибутива] разбилось о реальность

Во-первых, у Явы вообще своя атмосфера; во-вторых, правильные вещи не всегда побеждают.

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

И станет он «тулкитом одного языка» как сейчас qt. Пусть уж лучше остается на си, с биндингами для всего и вся

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

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

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

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

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

ABI и API будет нормальный, если писать с расчетом на предоставление биндингов, с этим проблем нет.
Собственно, как и GObject не обязательно юзать при взаимодействии с интерфейсами GTK

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

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

Никто не запрещает сделать и поддерживать дополнительно сишный интерфейс.

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

Этот интерфейс будет просто набором функций. Потеряется вся мощь GObject

Ничего не потеряется. Набор функций нужен будет для создания удобной обертки, которая уже будет вписываться в конкретный язык. Я так скрестил С++/Rust у себя. В обоих языках все выглядит нативно и удобно.

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

например, создать новые виджеты (на основе существующих) на другом языке

напрямую отобразить объектную модель сишной либы на объекты другого языка

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

Пфф, исключительно потому что все прибито гвоздями к GObject. Ты путаешь причину и следствие.
Сишная объектная модель это структуры и коллбэки. Где проблема?

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

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

Что, конечно, не делает Rust Gtk нужным.

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

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

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

Для большинства других задач, структур с функциями достаточно, не спорю

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

например, создать новые виджеты (на основе существующих) на другом языке

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

напрямую отобразить объектную модель сишной либы на объекты другого языка

Круто, но не необходимо.

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

Надо классы и наследование

Как-то со структурами и интерфейсами (трейтами) народ справляется и ничего.
ООП головного мозга?

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

Учитывая, что новые виджеты во всех остальных тулкитах создаются и без GOject

Что за все остальные тулкиты? EFL? Других сишных не припомню. В плюсовых и иных, тулкиты прибиты к языку

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

Что за все остальные тулкиты?

От Athena до USER.DLL или как его там.

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

QT через нигро-прокси на Си. Белиссимо

Да, будет выглядеть отвратительно - прямо как GObject/GTK, но что делать.

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