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 ()
Последнее исправление: Klymedy (всего исправлений: 6)
Ответ на: комментарий от anonymous

Покажи мне тех кто может. А лучше передай им, пусть уже хоть какие-нибудь программы напишут.

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

Прыще C++14

А вот это было обидно!

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

Они постигли дзен.

Нет. У них либо перерыв в лечении, либо дозировку пора усиливать.

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

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

То же пожелание растофанам. Вот тылгунер написал хоть тыщу строк хеловордов на расте (не говорю уж о чем то полезном)? Очень сомневаюсь, а ведь он фанатеет уже года 4. Кого ни спросишь, виляют: что-то пишу, но что не скажу. Один только признался, что пытался в продакшн и зафейлился.

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

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

Нет.

а ведь он фанатеет уже года 4

Походу, у тебя там год за три идет.

Кого ни спросишь

Попробуй спрашивать в другом месте.

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

Очередной неосилятор.

Вот скажи, что сложного в цепепе? :-) Чего там можно не осилить? :-)

Прыще C++14 только Git.

Git, в отличии от цепепе, - хорошо спроектированная система, в которой о недоразумениях и костылях большинство и не догадывается :-) Есть ли кто-нибудь, кто недоволен Git? :-) А вот о недоразумениях и костылях цепепе, в свою очередь, известно каждому, кто имеет немного мозга :-)

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

Полно. Поспрашивай у любителей меркуриала.

Не имею возможности :-) Причина банальна - ни одного любителя меркуриала не знаю :-) И почти все нынче выкладывают свои поделки на github/gitlab :-) Честно говоря, если бы ты не напомнил, я бы и не вспомнил о том, что существует какой-то там меркуриал :-)

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

А вот о недоразумениях и костылях цепепе, в свою очередь, известно каждому, кто имеет немного мозга

Ну это городские легенды, в основном. Мало кто на С++ может программировать так, чтобы ему эти костыли серьезно начали жить мешать. Так что большинству остается только страшилки друг-другу пересказывать о великом и ужасном, на котором написана его любимая node.js.

Идеальных языков не бывает и быть не может. Разрабатывать такой язык — это всё равно, что вечный двигатель строить. Вот обобщенное программирование на прекрасном Хаскеле просто песня по сравнению с С++2003. Но таки хаскеллеры иногда нервно посматривают в сторону последнего и запиливают комиляторы, выполняющие полную мономорфизацию кода. Правда, это им не особо сильно помогает. Обобщенное программирование на С++14 — это уже совсем другая история, полная приятных неожиданностей. После появления концептов (и перегрузки на основе концептов) преимущества Haskell над C++ будут эээ... вопросом ожесточенных споров, чем они никогда еще не были. Будут появляться библиотеки обобщенных структур данных и алгоритмов, которые на других языках просто так не сделать. А не просто никто делать не захочет. Библиотеки — это наше всё.

Rust относительно С++2003 просто прекрасен. Относительно С++14 тоже очень хорош (не везде). Но проблема библиотек его погубит, как мне кажется.

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

Ничего конструктивного эти фанатики не скажут.

Это справедливо про любых фанатиков.

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

После появления концептов (и перегрузки на основе концептов) преимущества Haskell над C++ будут эээ... вопросом ожесточенных споров, чем они никогда еще не были.

Мне не совсем понятно, чем концепты особо отличаются от типажей/классов типов с ассоциированными типами.

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

Мне не совсем понятно, чем концепты особо отличаются от типажей/классов типов с ассоциированными типами.

Сами по себе — ничем, кроме выразительности самого языка ограничений системы типов. Всё дело в том, (1) как реализован вывод типов на основе этих ограничений и (2) в типе генериков — полиморфные/мономорфные. Если генерики полиморфные, то вся информация о типах существует и используется только на этапе AST, а при кодогенерации она ужимается до минимума. Существует только одна версия функции для всех наборов типов, а отсюда потери производительности на боксинге. Зато имеем раздельную компиляцию модулей и, в принципе, произвольно сложный вывод типов. В качестве микрооптимизации может быть доступна частичная момноморфизация генериков.

Если генерики изначально мономорфные, как в С++, и это поддерживается на уровне языка, то мы можем делать произвольные специализации алгоритмов и, в случае С++, раскладок данных по памяти через шаблонный Value. И знать, что компилятор сделает именно то, что обещает, а не на своё усмотрение. Ни о чем таком в Haskell/ML лучше и не мечтать. Минус — отсутствие раздельной компиляции модулей и потенциально большой размер кода. На практике вполне приемлемо, но «очень большую» обобщенную структуру не создать. Плюс — наивысшая эффективность кода и использования памяти.

Короче, с появлением специализации на основе концептов многие вещи будут делаться еще проще. Их и сейчас можно запилить, но уж очень многословно получается. Даже для С++.

В Rust генерики пока слабоваты относительно С++. Специализации нет.

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

Хуже обстоит дело с HKT, этот вопрос пока отложен на будущее.

И даже пока не обещают? Печаль. Без HKT-шек жить, конечно, можно. Но грустно. Как коту без тестикул.

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

После появления концептов

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

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

любимая node.js

Игрушка, которая хорошо годится для сервера WebSockets и всяких там чатов :-)

Но таки хаскеллеры иногда нервно посматривают в сторону последнего и запиливают комиляторы, выполняющие полную мономорфизацию кода.

Ну и сравни Parsec и Boost.Spirit :-)

После появления концептов (и перегрузки на основе концептов) преимущества Haskell над C++ будут эээ... вопросом ожесточенных споров, чем они никогда еще не были.

Толку то с концептов :-) Ну будет специализация более изощрённой, а нормального метапрограммирования как не было так и нет :-)

Библиотеки — это наше всё.

Да, только вот с наворотами в цепепе-14 на все библиотеки уже смотришь с ещё большей опаской, чем на либы цепепе-03, потому что стили и подходы настолько разрознены, что пахнет бардаком :-) Создаётся ощущение NIH-синдрома, что лучше писать всё самому :-) Потому что надежды на хипстеров мало :-)

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

поддерживается только лишь разработчиками эпла

ftfy

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

Уже два хейтера не могут в азы языка на котором разговаривают,совпадение? Не думаю:)

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

И даже пока не обещают?

Ну как... обешают «когда-то». По последним новостям, в течении этого года - вряд ли.

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

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

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

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

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

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

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

Ну вот опять набор городских легенд, передаваемых из уст в уста. Шаблоны на отладку кода практически никак не влияют. Всё мономорфизировано. Отладка раскрытия самих шаблонов не невозможна, просто до недавнего времени небыло средств для этого, кроме всяких мелких трюков. Но всё меняется, встречаем Metashell. Пробовал, работает.

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

Ну и сравни Parsec и Boost.Spirit :-)

Врядли кто-то будет спорить, что программировать на Haskell где-то проще, чем на С++03. Практичная выразительность системы типов повыше будет. Я говорил о том, почему нет-нет, да запилят в Haskell/ML копилятор, выполняющий полную оптимизацию программы. Потому что скорости хочется. Абстракции Haskell/ML не бесплатны, в отличие от.

Толку то с концептов :-) Ну будет специализация более изощрённой, а нормального метапрограммирования как не было так и нет :-)

Ну, это кому как. По мне так метапрограммирование в С++14 уже вполне зрелое. Пусть и всё еще довольно многословное относительно других языков. Ну и, как я писал уже выше, у обобщенного программирования на С++ есть возможности, которых нет у других, как их называют, правильных языков: возможность делать не только обобщенные алгоритмы, но и обобщенные раскладки данных по памяти через шаблонный Value. Rust и D сюда же. Про Nim не знаю. И всё.

пахнет бардаком

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

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

Причем уже надублировали по самые помидоры!

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

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

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

Покажи что ли.

Хотя я говорил немного о другом.

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

Ага, просто сказка когда не пользуешься «мокрыми письками без СМС».

Э, дарагой, ты на год посмотри, а? 2008-й. А на дворе уже 2016-й! Есть Eclipse CDT с очень хорошо интегрированным отладчиком и прекрасный CLion. Всё отлаживается, точки останова ставятся, проблемы минорные.

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

не невозможна, просто до недавнего времени небыло средств для этого, кроме всяких мелких трюков.

Этого не было в цепепе :-) А в Лиспе уже лет как 30 всё это есть :-)

Но всё меняется, встречаем Metashell. Пробовал, работает.

Жалкая попытка слизать ещё интерактивные возможности Лиспа в поле цепепе :-) Вообще, те, кто хорошо знаком и с Лиспом и с цепепе могут заметить очень много таких вот заимствований :-) Но встать в ровень с Лиспом у цепепе никогда не получится в силу своей «замечательной» семантики :-)

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

next_u32 и next_u64? Ну да, копипаста. Но если сделать их не-копипастой, будет тупо больше кода - ХЗ, стоит ли оно того.

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

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

Вот ведь красота какая, вот ведь она, возможность метапрограммировать :-) При этом строчку в компайл-тайме как цепепе генерить не умел, так и не умеет :-)

Boost Hana уже унифицировала уровень типов и значение в одном фреймворке

Ну всё, хана :-)

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

Eclipse - тормозной комбайн, за что его и не люблю.

Я тебя понимаю. Eclipse 4.5 у них получился не просто тяжелым, я тяжеленным. Сам сижу на 4.4. Но если твой любимый текстовый редактор не умеет интегрироваться с gdb, это не проблема С++. Кстати, CLion мне показался очень хорошим. Проекты на cmake засасывает с ходу и умеет правильно работать с исходниками. Навигация по коду LLVM — просто песня. Одна беда, на моем коде CLion намертво виснет через 5 секунд. Что-то тяжелое анализирует делает в GUI-потоке. Да, у меня суровый код.

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

При этом строчку в компайл-тайме как цепепе генерить не умел, так и не умеет :-)

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

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

Да, очень хочется их иметь.

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

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

Кодируйте шаблоны с концептами :-) Гг :-)

Я тебя умоляю! Не «кодируйте что-то с чем-то», а «разрабатывайте эффективные системы с тем-то и тем-то». Кодируют что-то с чем-то в университетах. Для этого дела Haskell/OCaml вне конкурренции.

Пока что DSL-ки будем делать внешними средствами, не умрем.

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

Почитал тред:

ненависть к С/C++
HKT,DSL,Выразительность
Lisp,Haskell

ЖирБорщ сочится из монитора и заливает клавиатуру...

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

Еще один не может в русский язык.

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

Прописываю тебе мономорфизацию полиморфных генериков

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

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

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

А вы как думали, в сказку попали? Тут человек должен понимать, что делает, а не использовать комп как подставку под борщ :)

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