Привет в 2016-м году! Мы рады объявить первый в этом году релиз Rust — 1.6. Rust — системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.
Как всегда, вы можете установить Rust 1.6 с соответствующей страницы нашего сайта, а также посмотреть подробный список изменений для версии 1.6 на Github. Этот релиз включил в себя 1100 патчей.
В этот релиз вошли ряд небольших доработок, одно большое нововведение и изменение на Crates.io.
Самое большое нововведение в 1.6 — стабилизация библиотеки
Стабилизация
Около 30 библиотечных функций и методов стабилизированы в 1.6. Самые заметные улучшения включают в себя:
Семейство функций
Несколько реализаций типажа
Ну и наконец, метод
Можете также посмотреть на подробный список изменений.
Если вы поддерживаете контейнер на Crates.io, то возможно уже заметили предупреждение: новые контейнеры более не могут использовать шаблон
Вместо этого вы должны указать конкретную версию или диапазон версий, используя одно из множества ограничений на версию из контейнера
Звёздочка означает, что вы можете работать с любой версией данной зависимости. Скорее всего это не правда, и только добавляет лишние проблемы с совместимостью в экосистеме. Предупреждение о запрете звёздочки в качестве версии уже довольно давно выводится при публикации контейнера на Crates.io, а теперь оно станет настоящей ошибкой.
Хочу выразить благодарность defuz, Revertis, D101101 и всему русскоязычному сообществу Rust за помощь в переводе.
Как всегда, вы можете установить Rust 1.6 с соответствующей страницы нашего сайта, а также посмотреть подробный список изменений для версии 1.6 на Github. Этот релиз включил в себя 1100 патчей.
Что вошло в стабильную версию 1.6
В этот релиз вошли ряд небольших доработок, одно большое нововведение и изменение на Crates.io.
Стабилизация libcore
Самое большое нововведение в 1.6 — стабилизация библиотеки
libcore. Стандартная библиотека Rust состоит из двух слоёв: маленькая базовая библиотека libcore и полная стандартная библиотека libstd, которая построена на основе libcore. Сама libcore полностью платформенно-независимая и требует, чтобы было определено несколько внешних функций. Полная библиотека libstd основана на libcore и добавляет поддержку выделения памяти, операций ввода-вывода и многопоточность. При использовании Rust во встроенных средах и при написании операционных систем часто отказываются от libstd и используют только libcore.Стабилизация
libcore — важный шаг к возможности написания самого низкоуровневого кода на стабильной версии Rust. Однако, работа ещё не закончена. Стабилизация позволит вырасти экосистеме библиотек вокруг libcore, но её использование в приложениях пока ещё не поддерживаются полностью. Ожидайте новостей из этой области в будущих релизах.Стабилизация библиотек
Около 30 библиотечных функций и методов стабилизированы в 1.6. Самые заметные улучшения включают в себя:
Семейство функций
drain() для коллекций. Эти методы позволяют вам перемещать элементы из коллекций, при этом сохраняя память, в которой они размещены, тем самым в некоторых случаях уменьшая необходимость в выделении памяти.Несколько реализаций типажа
From для конвертирования между типами из стандартной библиотеки, в основном между целочисленными числами и числами с плавающей точкой.Ну и наконец, метод
Vec::extend_from_slice(), ранее известный как push_all(). Он значительно быстрее, чем более общий метод extend().Можете также посмотреть на подробный список изменений.
На Crates.io запрещено использовать звёздочки вместо версий зависимостей
Если вы поддерживаете контейнер на Crates.io, то возможно уже заметили предупреждение: новые контейнеры более не могут использовать шаблон
* в качестве номера версии в зависимостях. Другими словами, так больше сделать нельзя:[dependencies]
regex = "*"
Вместо этого вы должны указать конкретную версию или диапазон версий, используя одно из множества ограничений на версию из контейнера
semver: ^, ~ или =.Звёздочка означает, что вы можете работать с любой версией данной зависимости. Скорее всего это не правда, и только добавляет лишние проблемы с совместимостью в экосистеме. Предупреждение о запрете звёздочки в качестве версии уже довольно давно выводится при публикации контейнера на Crates.io, а теперь оно станет настоящей ошибкой.
От переводчика
Хочу выразить благодарность defuz, Revertis, D101101 и всему русскоязычному сообществу Rust за помощь в переводе.
erlyvideo
крутая тема с запретом на открытую зависимость
kstep
В этом плане крейт cargo-edit очень удобен: не нужно лезть на crates.io проверять какая последняя вресия крейта, который хочешь добавить в зависимости.
potan
В cabal (это такой cargo для haskell) с зависимостями от конкретных версий твориться ужас. Собрать что-то с зависимостями от двух пакетов редко просто так удается, посколько они зависят от конкретной версии третьего.
mynameisdaniil
Это не проблема конкретных версий, это проблема того как происходит работа с зависимостями. В том же npm(который в моей вселенной —образец пакетных менеджеров для языка) разные пакеты могут зависеть от разных версий и ничего страшного не произойдет так как каждый пакет будет видеть только свою версию.
В компилируемых языках с этим всегда сложнее, но это, разумеется, не повод указывать * вместо версии. Версии всегда должны указываться максимально конкретно, иначе есть риск попасть в другой ад: вчера собиралось а сегодня, после обновления модулей, перестало.
potan
Две версии библиотеки водной программе — лишний расход ресурсов. Особенно это неприятно в языке, претендующим на максимальную эффективность и использование во встраиваемых системах.
Лично я считаю, что разработчики библиотеки обязаны заботится об обратной совместимости и правильно ориентироваться на самую свежую стабильную версию. Конечно, жизнь не идеальна, но стремиться к этому надо.
mynameisdaniil
Ну встраиваемые системы это совсем другое, к тому же раст, насколько я знаю, пока не очень с ними дружит, нужно попыхтеть чтобы собрать вся для АРМа, например. А во всех остальных случаях, я предпочту чуть больший расход ресурсов, чем ад совместимости. Вы ведь хаскеллер? Тогда чего я вам объясняю? :) Слава богу, песочницы появились — и на том спасибо.
Насчет обратной совместимости, вы это серьезно? Даже в собственном проекте это не всегда возможно, и почти всегда нужно прилагать непропорционально растущие с размером проекта усилия. А сторонние разработчики, разумеется, никому ничего не должны и не будут.
В конце концов, если будет нужно, всегда можно форкнуть проблемные модули и адаптировать их для использования с какой то конкретной версией третьего модуля. Но я совершенно точно не хочу делать это всегда. По умолчанию, пусть все просто работает и каждый собирается с теми версиями третьих модулей, с которыми ему хочется.
potan
Ну для встроенных систем и на С собраться нетривиально. Просто в интернетах больше информацииб как проблемы решать.
Хотя в cabal часто указывают точные версии, я несколько раз скачивал исходники библиотек, правил им зависимосим на более свежие и все прекрасно работало. Уж на языках со статической типизацией заботится об совместимости.
Был бы язык и менеджер пакетов, где интерфейс библиотеки отделен от реализации и в зависимостях указывался интерфейс, а при сборке выбиралась бы предпочитаемая реализация…
defuz
Rust не допустит ситуации, когда в одном проекте у вас одновременно одна и та же библиотека разных версий просто потому, что необходимо гарантировать, что структуры, порожденные этой библиотекой, будут совместимы с этой же библиотекой. Представте себе ситуацию, что библиотеки A и B зависят от библиотеки C разных и не совместимых версий. Если вы подключите одновременно библиотеки A и B, а затем получите данные из библиотеки A (которая в свою очередь получит их из С), которые вы передадите в библиотеку B (которая в свою очередь делегирует задачу С), то у вас вылезет просто несовместимость библиотеки с самой собой на уровне ABI.
Чтобы избежать подобного ада, в экосистеме Rust активно насаждается semver. Если вы пишете, что ваша библиотека зависит от библиотеки C версии 1.2, то на самом деле это означает, что вам подойдет любая версия C, совместимая с 1.2, вполть до версии 2.0 не включительно.
ozkriff
Это только если данные между библиотеками-зависимостями передаются, к сожалению.