LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на 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 = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

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

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()

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

Но опыт Java показывает, что аннотации подобных таких задч экономят много сил.

Так разве в джеве «слабые ссылки» в виде аннотаций сделаны?.. По моему, нет:

https://docs.oracle.com/javase/7/docs/api/java/lang/ref/WeakReference.html

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

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

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

А было ли его использование обязательным, когда он был?

Нет.

Можно ли было обойтись без него?

Да.

В Go тоже был GC, в 2011-2012г.г. размен Go на Rust был шило на мыло, так что выпил GC это уже оптимизация под новую нишу.

Необходимые средства, делающие язык годным для ядерного кода (unsafe и ffi) на тот момент уже были.

Кстати, насколько я понимаю ffi в нынешнем виде запилили незадолго после unsafe, не так ли?

А когда именно это произошло?

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

Делать GC частью библиотеки предлагали еще в 2013 до его выпила, и соображения были примерно такие:

  • GC нужен в серве для интеграции с движком JS, а так же для реализации движков различных динамических языков.
  • Для разных применений нужны разные GC, соответственно не стоит оставлять GC частью языка, пусть обезьянка инженер сам выбирает, какой GC ему нужен.
  • Rust дулают на замену C++, из всех фич Rust GC - единственное, что плохо сочитается с концепциями C++;
  • GC сильно усложняет runtime lib, в имбеде иногда нет ресурсов на GC, луше выпилить, а то вдруг фрагментация возникнет...
shkolnick-kun ★★★★ ()
Ответ на: комментарий от anonymous

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

Я бы не сказал, что на Idris'е трудно что-либо написать. Доказать — пожалуй, но это из-за того, что в доказательстве требуется указывать даже тривиальные вещи.
Clean не академический, он просто вымер.

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

Я читал.

В имбеде (во всяком случае в маленьких системах с ограниченными возможностями) C++ используется в основном, как C with classes.

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

Множественное наследование тоже нет (аналогично),

Шаблоны-классы используются (в ScmRTOS, например), но можно и без них обойтись, хоть и не типобезопасно, а можно сделать типобезопасную реализацию шаблонов на С.

Шаблоны функции - используются (видел 1 раз в прошивке для 3D-принтера), без них обойтись еще легче и никакого влияния на типобезопасность не будет.

Так что C или C++ - практически не важно.

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

Это был вольный перевод слов Патрика:

Of these, the only language items that don’t have direct C++ equivalents are the garbage collection primitives. If those were eliminated, then Rust as a language would be every bit as freestanding as C++ is.

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

Так разве в джеве «слабые ссылки» в виде аннотаций сделаны?.. По моему, нет:

В Java слабые ссылки немного не для этого. Там же есть GC, который и так всё делает в плане работы с циклами в графах. Слабые ссылки нужны для интерфейса с ним. С их помощью делаются всякие кэши, которые держат ссылки на кэшируемые объекты. Если на объект уже никто не ссылается (кроме слабой ссылки), его еще можно достать из кэша до пока он не вычищен GC.

Т.е. для графов с циклами компилятору Java ничего нигде расставлять не нужно.

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

Ну а что ему стоит в if() {} его завернуть?

//Психиатр

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

А после этого приходят представители промышленности и пользуются

Немного другая сфера языков под задачу. Я помню про Буран и Пролог.

Я имею в виду «пользуются опробованными идеями», не готовыми языками. Тот же Rust использует идеи Cyclone, но не более. И если в половине созданных языков с линейными типами есть GC - я считаю это проверенной идеей.

«value can be used at most once»

... at the same time

Ы? Вообще за время жизни значения.

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

В Go тоже был GC, в 2011-2012г.г. размен Go на Rust был шило на мыло

Да блин, зачем ты это говоришь? Ты же не знаешь ровно ничего про Rust образца 2011 года. Он был совсем непохож на нынешний.

так что выпил GC это уже оптимизация под новую нишу.

Выпил GC - это обычное «не пригодилось».

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

Кстати, насколько я понимаю ffi в нынешнем виде запилили незадолго после unsafe, не так ли?

У тебя какая-то мания на unsafe. Но, поскольку unsafe в каком-то виде был уже в rustboot, его запилили раньше, чем «современный FFI», что бы ты этим термином не называл.

Кстати, вот тут Патрик рассказывает

Делать GC частью библиотеки предлагали еще в 2013

Спасибо, я знаю.

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

Был бы благодарен за конкретную ссылку

Конкретной ссылки нет. Это впечатление, сложившееся от регулярного чтения.

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

https://doc.rust-lang.org/std/io/index.html

А это «because they are traits, Read and Write are implemented by a number of other types, and you can implement them for your types too.» означает, что маразм iostream из цепепе крепчает? :-) Что сложнее, реализовать потомка std::streambuf из цепепе или вот это в русте? :-)

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

Я не совсем понял, что тебя не устраивает.

Меня не устраивает маразмо-дизайн iostream в цепепе :-) И не только меня :-) Интереса ради, хочется узнать как с этим в русте :-)

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

Read это одна функция, которая читает в предоставленный буффер байты из твоего источника. Write, соответственно, пишет. Чтобы реализовать, надо написать реализацию этой одной функции. Всё крайне просто.

Legioner ★★★★★ ()

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

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

Тем более, Rust легко встраивать в другие языки

? Как например дернуть код на Rust из Python.

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

С помощью ffi.
https://doc.rust-lang.org/book/rust-inside-other-languages.html

Так это наоборот, крайне неудобно, топорно и масса ручной работы. Так все умеют. А удобно, это, например, так:

char const* foo() { return "foo"; }
char const* bar() { return "bar"; }

object choose_function(bool selector)
{
    if (selector)
        return python::make_function(foo);
    else
        return python::make_function(bar);
}

BOOST_PYTHON_MODULE(make_function_test)
{
    def("choose_function", choose_function);
}
>>> from make_function_test import *
>>> f = choose_function(1)
>>> g = choose_function(0)
>>> f()
'foo'
>>> g()
'bar'
anonymous ()
Ответ на: комментарий от anonymous

Не так давно видел пример вызова кода на rust'e из node.js. Работа в данном направлении ведется очень активная.

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

Ну а что ему стоит в if() {} его завернуть?

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

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

В Java слабые ссылки немного не для этого.

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

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

Это не часть ядра языка, это часть стандартной библиотеки, в Rust был специальный тип указателей @.

То есть С++ рантайм не включает в себя GC в обязательном порядке, a рантайм Rust должен был включать.

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

Выпил GC - это обычное «не пригодилось».

It might be possible to create a language that presents only a simple, fully automatic memory management system at first, and which surfaces the machinery of safe manual memory management* only when the programmer requires it for maximum performance. This would ease the learning curve, as programmers would be able to write many, perhaps most programs without ever learning how to manage memory at all.

Пригодилось!

А потом, когда обезъянки хипстеры лисперы члены ЦА научились писать на Rust, сообществу провели по губам сделали вот так:

In short, I think that Rust as a language should focus on roughly the same application domain as C++ does.†

Important to this effort is to have as small of a runtime as possible, just as C++ does, leaving higher-level abstractions to libraries. And, in fact, we are almost there already.

Ну то есть сообщество сообществом, а цели и интересы чёрного властелина спонсора превыше всего.

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

Ну, я же не виноват, что глобус выполнен в форме дилды, а сова явно ведет распутный образ жизни. XD

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

Пригодилось!

В мысленном эксперименте.

Ну то есть сообщество сообществом, а цели и интересы чёрного властелина спонсора превыше всего.

Какого нах спонсора, это интересы прямого заказчика - Мозиллы. Перестань уже бредить.

глобус выполнен в форме дилды

А, окей. Ты не можешь перестать.

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

Тылгуннер, скажи ка, вот эта порнография fn - это сообщество так захотело? Не могу представить, чтобы на трезвянку кто-то желал такого синтаксиса. Открываешь первый же хеловорд и уже нужен рвотный пакетик. Для консистентности надо бы еще trt, strct, tp и прочие рептилоизмы. Или вот синтаксис лайфтаймов - из всех закорючек выбрали парный символ, уже семантически занятый. В результате в любом редакторе сразу слетает подсветка, если его специально не научить расту. Вот на ЛОРе, например, вся копипаста - нечитаемый мусор. Впечатление, что это специально мин понакидали на уровне простейшего синтаксиса, чтобы сразу закрепить репутацию вырвиглазного говна. А то вдруг кто-то начнет на этом писать даже. Ну и чем дальше в лес, тем толще партизаны. Из-за обилия сущностей натуральный комбинаторный взрыв при их описании с использованием всех возможных скобок, стрелок, закорючек. Обработка ошибок в стиле callback hell. Макросы так просто феерия в жанре «кот на клавиатуре». Ну просто дали оторваться ученым-маньякам по полной, чтобы обычный кодер в ужасе убегал (тут то мы ему и покажем Го, будут слезы счастья).

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

callback hell

Вижу нравится тебе это выражениe. Ну хорошо хоть не dll hell. А что? Настолько же «похоже».

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

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

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

вот эта порнография fn - это сообщество так захотело?

Нет. Тараканы в голове Грейдона заставили его сделать это.

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

А это сделало сообщество. И это блестящее решение.

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

Хватит с нас и одной Ады.

Обработка ошибок в стиле callback hell. Макросы так просто феерия в жанре «кот на клавиатуре». Ну просто дали оторваться ученым-маньякам по полной, чтобы обычный кодер в ужасе убегал (тут то мы ему и покажем Го, будут слезы счастья).

Чушь.

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

Pyramid of doom не в Rust появилась.

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

Нет, им покажут не Го, а F#, сейчас главный спонсор некрософт же!

anonymous ()

Ну, кажется, тема выдохлась. Давайте что-ли подведем итоги, кто хочет.

Я лично, и многие мои знакомы плюсовики, испытывают сложные чувства к С++. Мы любим этот язык и ненавидим отновременно (всё, как в реальной жизни). Поэтому испытываем живой интерес к возникающим немногочисленным пока что альтернативам. Я за Rust слежу давно, но серьезно принюхался к нему только сейчас. И он мне, в целом, нравится.

Что есть хорошего, с моей колокольни.

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

Платформа выглядит консилидированной и построена над LLVM со всеми его батарейками. Можно барть и кастомизировать.

Программирование в большом гораздо проще на Rust, чем на С++. К нашим услугам единообразно оформленные модули, макросы и пакетный менеджер. Привет, Maven! Нет никакой необходимости вводить такие драконовские стайл-гайды, как гугловский. И это большой плюс Rust перед C++ уже сейчас.

Наконец, афинные типы. Их наличие как решает проблемы, так и создает. Они будут в первую чоередь полезны для управления жизненным циклом разделяемых ресурсов OS (память, сокеты, ...), но это мы так же имеем и в C++. Еще они могут использоваться для предотвращения нежелательного разделения ресурсов между потоками. Но сама по себе эта возможность будет интересна только писателям библиотек и фреймворков. Общая тенденция такова, что разделяемого состояния должно быть очень немного, и усредненный прикладной программист не должен сталкиваться с ним напрямую вообще. Компилятор тут на самом деле не сильно-то большой помощник, санитайзеры времени выполнения всё равно нужны. В С++ они есть, в том числе очень мощные (но эти за хорошую денежку).

Теперь минусы.

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

Короче, я для себя мотивации дальше углубляться в Rust не нашел. С++ lock-in :) Последний так же хорошо развивается, и проблемы программирования в большом (модульность) обещают решить в ближайшие 2-3 года. Это не так уж и много. В остальном, библиотеки рулят.

//Психиатр

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

Удаление исключений — вещь спорная, но я записываю скорее в плюсы. Так как в модели С++ исключения очень сложно реализовать эффективно и с ними легко убивается производительность.

Ага, а ещё если исключение генерирует деструктор, то легко может убиться и программа :-) Но главная проблема исключений - это неизбежная раскрутка стека, что в оппозит сигнальному протоколу Common Lisp делает исключения C++ лишь серенькой возможностью отделять код обработки ошибок от основного кода :-) Ну да ладно, ведь C++ чуть-чуть более высокоуровневый язык по сравнению с C :-)

Платформа выглядит консилидированной и построена над LLVM со всеми его батарейками. Можно барть и кастомизировать.

Сочувствую :-)

Программирование в большом гораздо проще на Rust, чем на С++.

В чём же это? :-)

К нашим услугам единообразно оформленные модули, макросы и пакетный менеджер. Привет, Maven!

Нафиг оно надо? :-) Пока, Maven! :-)

Нет никакой необходимости вводить такие драконовские стайл-гайды, как гугловский.

Нет никакой необходимости следовать таким драконовским стайл-гайдам, как гугловский :-) Или основная масса цепепешников такие ярые догматы, что никак не могут программировать вне установленных лысыми теоретиками рамок? :-)

И это большой плюс Rust перед C++ уже сейчас.

У джавы есть преимущества перед C++, это очевидно :-) (См. Tiobe.)

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

Java появилась когда на це и цепепе уже были тонны хвалёных библиотек, но это не помешало раскрутить этот язык, написав на нём не меньше тонн софта, чем на це или цепепе :-)

Короче, я для себя мотивации дальше углубляться в Rust не нашел. С++ lock-in :) Последний так же хорошо развивается, и проблемы программирования в большом (модульность) обещают решить в ближайшие 2-3 года. Это не так уж и много. В остальном, библиотеки рулят.

Ну и правильно :-) С мейнстримом как-то безопаснее :-)

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

Ну да ладно, ведь C++ чуть-чуть более высокоуровневый язык по сравнению с C :-)

Немного не так. С++ такой же низкоуровневый, как и С. Но с добавлением достаточно развитых «дешевых» абстракций. И только «дешевых». Дорогие «абстракции» ломают парадигму и функциональную нишу этого языка. Зачем нам скрещивать ежа и ужа? У С++ есть своя немальнькая ниша где он и только он (плюс его аналоги) эффективен. Все попытки протащить какие-то другие языки в эту нишу с треском провалились. Хочется развитых абстракций, за которые согласен платить в рантайме, используй Haskell, Lisp, да что угодно. Можешь даже Mercury, если задача требует.

//Психиатр

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

В Java слабые ссылки немного не для этого. Там же есть GC, который и так всё делает в плане работы с циклами в графах. Слабые ссылки нужны для интерфейса с ним. С их помощью делаются всякие кэши, которые держат ссылки на кэшируемые объекты. Если на объект уже никто не ссылается (кроме слабой ссылки), его еще можно достать из кэша до пока он не вычищен GC.

Тогда это не WeakReference, а SoftReference. Если на объект не осталось ни одной strong ссылки, то weak протухает. Soft же протухает при GC, если не удаётся обычным образом вычистить достаточно памяти.

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

я бы даже сказал statically. Но это видимо отголоски опыта с RTOS.

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

Справедливости ради, есть real-time GC, которые позволяют уменьшить недетерминизм и время остановки до некоторой заданной величины.

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

суровые embedded-щики будут писать на одном подмножестве Rust-а со своим набором библиотек...

Я тут zinc.rs кумарнул для stm32l*. Требуется напильник, но в общем и целом получается прикольно. Мне на первый взгляд нравится гораздо больше чем коцаный C++ или всё делать на С.

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от shkolnick-kun

Я себе запиливал шаблонную обёртку над портами контроллера, которая на основе дефайнов из sdk инстанцировала экземпляры для условно PORTA PORTB и т.п. Соответственно если ты пытался заюзать несуществующий порт, ну там, портировал прошивку с одного на другой контроллер в рамках семейства, получал ошибку компайлтайма. Не то, что бы особо нужно или важно, но мне было удобнее писать что-то типа Port<A>.Set(i), нежели *(PORTA_OFFSET) |= (1 << i);

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

На вкус и цвет, как говориться, я обычно делаю нижний уровень, который абстрагирует всякие там порты, пины, UARTы и т.д., а дальше просто пишется что-то вроде dbg_port_send(«Hello world!», 13);

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