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)

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

метапрограммирование доберётся до мейнстрима

Мне думается, что количество задач, где есть реальная выгода от метапрограммирования, несколько преувеличивается.

Тем более, что в ряде языков эти проблемы решаются за счет рефлексии.

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

Если для клея, то пофиг;

Для клея, конечно же. У динамически-типизированных языков есть своя надежная ниша, в которой они незаменимы, — это быстрое прототипирование и всякий ad-hoc. Всё это над библиотеками, написанными на сильно-типизированных языках. Если кто-то пытается всё-всё-всё писать в динамической типизации, то это от избытка энтузиазма, порождаемого недостатком опыта.

//Психиатр

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

Тем более, что в ряде языков эти проблемы решаются за счет рефлексии.

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

//Психиатр

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

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

Дык в том-то и дело, что нативные языки вроде C и C++ в этом отношении стоят несколько особняком. Тут не так просто сгенерировать код прямо в run-time и дергать его по мере необходимости.

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

Тут выше пеняли на качество Firefox. Покажите аналог на CL, сравним

Этот продукт пишут десятилетия за зарплату многомиллионными корпорациями.

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

Тут не так просто сгенерировать код прямо в run-time и дергать его по мере необходимости.

Кому как :-) Сишнику - не проблема :-) Basic JIT :-) А для мастеров vector<map<string, list<string>>> - проблема :-)

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

Этот продукт пишут десятилетия за зарплату многомиллионными корпорациями.

ЕМНИП, CommonLisp появился задолго до Netscape. И уж тем более до Mozilla. Что помешало выбрать для реализации браузера такой замечательный язык, как CommonLisp?

Ведь, если верить адептам, там и скорость разработки выше, и сама разработка проще, и качество не сравнить...

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

Этот продукт пишут десятилетия

Лиспы гораздо старше С++.

за зарплату

trollface.png

многомиллионными корпорациями

Netscape был основан, что называется, на коленке, Firefox его наследник, в коде до сих это отчетливо видно.

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

Дык в том-то и дело, что нативные языки вроде C и C++ в этом отношении стоят несколько особняком.

Давай я попробую объяснить. Вот я, например, многоязычен. Мой основной язык - Java. Я читаю Scala и еще много пишу на С++. Еще немного специфической маргинальщины, по мелочи.

И вот, работая с Java/Scala, я научился пользоваться метапрограммированием эффективно. Там, где надо — пользоваться. Где не надо — не пользоваться. И вот я прихожу в С++, и вижу там очень много мест, где метапрограммирование можно эффективно применить. Там есть свои инструменты, которые не во все задачи хорошо вписываются. А некоторых привычных инструментов (макросы, например) нет вообще. Нет инструментов — нет метапрограммирования. Да, именно так. И еще местные, которые уверены, что оно совсем тут не надо, так как всегда обходились без него.

Вот так это примерно выглядит с моей колокольни.

//Психиатр

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

Что помешало выбрать для реализации браузера такой замечательный язык, как CommonLisp?

Цена на качественные компиляторы и недальновидность манагеров — вендоров этих компиляторов.

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

Потом попробуйте это байду заджитить.

Именно эта байда будет джититься очень хорошо. Но вот более тяжелый шаблонный код — уже не так хорошо, всё верно. Особенно, если используется LLVM. Чтобы делать «динамический С++», нужно порождать AST и его интерпретировать, а пока интерпретируется, то в фоне JIT-ить. Но системы на основе LLVM так, в основном, не умеют. Они сразу порождают биткод, который потом комилируется в машинный. В случае С++, да и любого боле-менее высокоуровневого языка это (порождение биткода) может быть слишком долго.

Вот есть язык Julia, который пророчат на замену Python, jit-компилируемый в LLVM. Так там иногда нужно долго ждать, когда он свою библиотеку отджитит. Совсем не то, если ты хочешь просто скрипт запустить. С данимическим С++ всё гораздо хуже, если решь идет о шаблонном коде.

//Психиатр

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

Кстати, BigMoney и Лисп :-)

Зато не сидят на месте и развивают свою платформу под конъюнктуру рынка ;) Давно бы обанкротились если бы не делали бигманей.

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

Цена на качественные компиляторы

Visual C++ в 1993-м стоил 500$. AllegroCL под Win - 595$. Практически одинаково. Так что это отмазки для бедных.

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

http://franz.com

Знаю их. Если убрать весь маркетинговый апломб, то в итоге мало что останется такого, чего нет у других. Но таки да. Лисп под капотом и во все поля.

//Психиатр

anonymous
()

Но зачем нужен Lisp в 2016 году, когда есть полноценные языки на основе переписывания термов (Pure, например), а завтипы завозят даже в хаскель?

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

AllegroCL под Win - 595$.

Не очень давно делали запрос в Franz :-) ACL 9 x86_64 стоил 8 тыс. у.е. одной копии компилятора, который сможет генерировать программы на ACL для распространения :-) (Т.к. любая программа на CL включает в себя и компилятор, то распространение программ должна позволять лицензия.) :-)

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

Нет инструментов — нет метапрограммирования. Да, именно так. И еще местные, которые уверены, что оно совсем тут не надо, так как всегда обходились без него.

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

Ну и кстати говоря. Многие C++ за старую систему #include-ов ругают. Тогда как при пре-компайл-тайм кодогенерации это очень удобно. Можно было не целые классы генерировать, а их фрагменты, которые затем в нужных местах инклюдились. В Java такого не было, там рулили трюки с рефлекшеном.

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

Не очень давно делали запрос в Franz :-) ACL 9 x86_64 стоил 8 тыс. у.е. одной копии компилятора

Все верно, лохов-фанатиков надо стричь, в то время как всякие Apple и MS дают бесплатные инструменты.

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

Ну вот, о чём я и говорил - лицензия на распространение программ, включающих компилятор/рантайм ACL 3 в 90-хх «A Professional version with royalty free runtime distribution and source code is available for $2495.» :-)

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

Тот Лисп, который мы тут обсуждаем, он декларирует бесшовную совместимость с С++. И только поэтому мы его обсуждаем.

//Психиатр

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

Это не то, а:

«A Professional version with royalty free runtime distribution and source code is available for $2495.»

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

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

Ну вот, о чём я и говорил - лицензия на распространение программ, включающих компилятор/рантайм ACL 3 в 90-хх «A Professional version with royalty free runtime distribution and source code is available for $2495.» :-)

Ну так ее одну надо было всего - для сборки релизной версии. А все разработчики могли пользоваться версией за $449. В итоге разница не такая большая.

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

Цена на качественные компиляторы и недальновидность манагеров — вендоров этих компиляторов.

Цена на инструмент напрямую связана с востребованностью инструмента. Чем выше объемы продаж, тем ниже цена и наоборот. Так что даже про недальновидность манагеров вы правы (что вряд ли), то проблема скорее в том, что на компиляторы лиспа цена была слишком высока по причине слишком низкого спроса. Т.е. CL мало кому был нужен.

Собственно, не только он. Такая же история была и у коммерческих SmallTalk-ов. И у нынешнего Eiffel-я.

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

Ну так ее одну надо было всего - для сборки релизной версии. А все разработчики могли пользоваться версией за $449. В итоге разница не такая большая.

История не знает сослагательного наклонения :-) И вопрос «почему Netscape не стал писать браузер на Common Lisp» так же глуп как «почему Линус Торвальдс не стал писать Git на C++» :-)

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

как всякие Apple и MS дают бесплатные инструменты.

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

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

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

Уже ответил выше. А вообще, ну очевидно же почему CL не мог даже рассматриваться, - он слишком жирный и тормозной. Браузер на CL, запущенный на PC с 4-8Мб ОЗУ, ушел бы сразу навечно в своп.

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

Все верно, лохов-фанатиков надо стричь, в то время как всякие Apple и MS дают бесплатные инструменты.

Бугага :-) Так лохи как раз холопы, кто не видят альтернатив говну, которое они вынуждены жрать, будучи плебеями :-)

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

Ага, сначала купи либо мак, либо винду.

Ты их в любом случае купишь, если будешь под них писать. Даже если это будет не C#, Swift, C++ etc., а CL.

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

И вопрос «почему Netscape не стал писать браузер на Common Lisp» так же глуп как «почему Линус Торвальдс не стал писать Git на C++»

На самом деле вопрос про Git на C++ отнюдь не праздный. Но в контексте разговоров о неоспоримом преимуществе Lisp-ов над всем остальным миром гораздо интереснее, почему Линус не стал писать Git на Lisp-е.

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

На самом деле вопрос про Git на C++ отнюдь не праздный. Но в контексте разговоров о неоспоримом преимуществе Lisp-ов над всем остальным миром гораздо интереснее, почему Линус не стал писать Git на Lisp-е.

Ответ очевиден - Линус мастер по C :-) Не нужны ему ни цепепи, ни лиспы :-)

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

Бугага :-) Так лохи как раз холопы, кто не видят альтернатив говну, которое они вынуждены жрать, будучи плебеями :-)

Ну покритикуй F#, например.

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

C тоже на месте не стоит

Действительно, туда наконец добавили const и void. Ах да, это было в 89-м...

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

Браузер на CL, запущенный на PC с 4-8Мб ОЗУ, ушел бы сразу навечно в своп.

не факт

Хотя сейчас это делать проще и даже намного легче, чем JVM.

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

почему Линус не стал писать Git на Lisp-е.

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

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

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

Это был бы не Линус :-) Ибо как мог бы сишник до мозга костей создать лиспось, чтоб потом писать Git на Лиспе, если он сишник? :-)

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

Действительно, туда наконец добавили const и void. Ах да, это было в 89-м...

Ты потерялся во времени :-) Уже 5 лет как есть C11 :-)

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

По факту мы живем в реальном мире, в котором о преимуществах Lisp-а догадываются отдельные адепты, об адекватности которых можно судить просто по факту их участия в спорах о Rust и C++. А если еще и учесть, что они при этом говорят...

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

Указывать на формальные преимущества Lisp-ов по отношению к этим инструментам адептам, наверняка, приятно. Но пользы от этого ни для кого нет.

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

нет, только над цепепе в данном треде.

Где эти преимущества? Что такое есть в вашем CL, что позволило кому-то где-то создать конкурента Chrome, Firefox, Photoshop, MySQL, MSSQL, Oracle и т.д. И этом речь только про C++. Можно глянуть в сторону Java. Не говоря уже в сторону совсем древнего и убогого C. Вот придурочный смайлик все время PostgreSQL в пример приводит. Где что-то калибра PostgreSQL на CL?

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

Кстати да :-) Почему до сих пор нет браузера на F#? :-)

Заговор корпораций, слишком дорогая цена бесплатной Visual Studio, язык не для быдла, нет F#-машин, т.к. у них нет шансов перед попсовым железом и т.д. Очевидно же.

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

Но пользы от этого ни для кого нет.

Ну уж прям никакой пользы нет: кто-то узнает о альтернативах не уступающих (и даже лучших чем) C++.

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

Где что-то калибра PostgreSQL на CL?

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

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