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

ты усвоил хоть, что «string»[1] = 0 делать нельзя в цепепе, или нет?

Вы мне так и не ответили, понимаете ли вы разницу между константным указателем на данные и указателем на константные данные. Судя по вашему высказыванию, вы до сих пор не знаете, как это относится к конструкции «string»[1] = 0.

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

JIT-компиляция
Где это может пригодиться? Ну, например, если мы делаем новый язык поверх С++, с развитым метапрограммированием уровня системы типов.

Typed Racket тебе в помощь :-)

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

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

Я разве где-то утверждал обратное? Или пытался доказать, что как язык программирования C++ мощнее/лучше/безопаснее, чем какой-нибудь из Lisp-ов?

Мне не понятно, какое отношение возможности лиспов имеют к разговору о C++ и перспективах Rust-а.

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

понимаете ли вы разницу между константным указателем на данные и указателем на константные данные.

Бугага :-) Ты не делай «string»[1] = 0, а то словишь SIGSEGV :-)

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

Я смотрю на вещи, связанные с метапрограммированием, немного более приземленно.

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

//Психиатр

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

Это проблема только для тех, кто в IDE не может custom build step настроить.

Настройка IDE по причине невозможности выразить что-либо на языке программирования - это проблема тех, кто пишет на недоязыках :-)

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

Ты начал с декларативного программирования, теперь ты в уши льёшь про «кодирование данных»

Я понимаю, что ты со мною разговариваешь смеха ради.

Зачем мне эти примитивные примеры как в книжках про цепепе различных облысевших теоретиков? :-)

Без работы этих облысевших теоретиков ты бы сейчас не за компом сидел в теплом офисе, а на руднике бы корячился. Это если би маленьким не сдох. Так что прояви уважение.

//Психиатр

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

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

А C++ в таком количестве разных предметных областей используется и настолько по-разному, что то, что нормально в одной нише, будет абсолютным оверкиллом в другой.

В этом, кстати, еще одна сложность развития C++. Которой пока нет у Rust-а.

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

тот же Boost.Hana уже выглядит отвратительно

Вот можешь же адекватно мыслить, когда хочешь :-) Молодец! :-)

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

C и Java - самые адекватные языки программирования для решения практических задач *командами* - простые и эффективные

Джава «понемногу» наращивает количество фич и увеличивает сложность. Это к тому, что такие вполне мейнстримовые и «командные» языки как джава и С# не такие уж простые и процесс идёт дальше, как и с любым живым языком. C тоже на месте не стоит.

Конечно, между С и С++ всегда будет разрыв по «сложности», а вот насчёт джавы не уверен. Пусть это и будут «разные сложности».

От того все эти «стандарты», нормативы, паттерны, совещания, конференции, семинары, вебинары - это всё приёмы организации

Как будто этого всего нет для «простой джавы».

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

Ты не делай «string»[1] = 0, а то словишь SIGSEGV

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

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

C++ AST вполне себе IL

Я даже не понимаю, причем здесь AST, не говоря о том, как использовать его в роли IL (если ты не автор компилятора Си++).

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

Без работы этих облысевших теоретиков ты бы сейчас не за компом сидел в теплом офисе, а на руднике бы корячился. Это если би маленьким не сдох. Так что прояви уважение.

Подстрой свой парсер и внутренний компилятор, потом ещё раз прочитай :-) Где было заявлено о неуважении к лысым теоретикам? :-)

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

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

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

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

бывают ещё проблемы создания компиляторов

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

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

Typed Racket тебе в помощь

Спасибо, но у меня, и не только у меня, большая кодовая база на С++, и я хочу её продолжать использовать целиком и полностью, а не «биндинги к С». Или такая возможность имеетя?

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

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

Ты внимательно хоть за логической цепочкой своей же следить можешь? :-)

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

Или такая возможность имеетя?

«Clasp is a new Common Lisp implementation that seamlessly interoperates with C++ libraries and programs using LLVM for compilation to native code. This allows Clasp to take advantage of a vast array of preexisting libraries and programs, such as out of the scientific computing ecosystem. Embedding them in a Common Lisp environment allows you to make use of rapid prototyping, incremental development, and other capabilities that make it a powerful language.»

https://github.com/drmeister/clasp

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

Спасибо, но у меня, и не только у меня, большая кодовая база на С++

На здоровье :-) Посмотри clasp тогда - Common Lisp на базе LLVM :-) Дядька специально делает его для тех задач, о которых ты говоришь :-)

Или такая возможность имеетя?

В Racket имеется возможность любому метапрограммисту реализовать себя :-) Там очень продвинутый FFI к C, но не к цепепе (спасибо name mangling) :-)

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

Где было заявлено о неуважении к лысым теоретикам? :-)

Если ты искренне не понимаешь эмоциональной окрашенности фразы:

Зачем мне эти примитивные примеры как в книжках про цепепе различных облысевших теоретиков? :-)

то ты — аутист. Впрочем, мне уже сообщили, что у тебя тут длинная история «чудачеств». Тебе среди людей трудно.

С уважением, //Психиатр

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

На здоровье :-) Посмотри clasp тогда - Common Lisp на базе LLVM :-) Дядька специально делает его для тех задач, о которых ты говоришь :-)

Спасибо за наводку. Обязательно посмотрю.

//Психиатр

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

Если ты искренне не понимаешь эмоциональной окрашенности фразы:

Там только факты без всякой эмоциональной окраски :-)

то ты — аутист. Впрочем, мне уже сообщили, что у тебя тут длинная история «чудачеств». Тебе среди людей трудно.

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

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

Зацени :-)

Ну идея вроде с ходу понятная: DSL. В данном случае для (био-)химии. Я к таким вещам отношусь если не с восторгом, то с уважением. Применительно к данной дискуссии Lisp может и не подойти. По крайней мере в том ключе, в котором мы обсуждаем Rust, С++ и D. Все три этих языка — ресурсно ориентированные. Т.е. там есть средства уровня языка для управления ресурсами. В С++ и D — это деструкторы. А в Rust — афинные типы. Очень важные характеристики в области, о которой я задесь говорю — большие данные. Средства же метапрограммирования в них довольно примитивные относительно специализированных языков. Зато в этих языках нет ресурсной ориентированности. Хотя... много чего на свете есть.

//Психиатр

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

Да уж, выдающееся творение. https://drmeister.wordpress.com/2015/07/30/timing-data-comparing-cclasp-to-c-...

I’m calculating the 78th Fibonacci number 10,000,000 times in each case. For these integer arithmetic heavy functions, CClasp performs pretty well (~4x slower than C++).

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

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

Я даже не понимаю, причем здесь AST, не говоря о том, как использовать его в роли IL

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

//Психиатр

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

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

Не совсем. Заявленная бесшовная интеграция с С++ позволяет вынести весь тяжеловесный код в С++, оставив в Lisp только высокоуровневую компоненту (и REPL). Вполне себе стандартный подход. Python именно так и живет, и здравствует. Julia идет ему на смену. Довольно много областей, где нужен эффективный REPL. А в Big Data это вообще must have.

//Психиатр

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

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

Как не красиво выдирать фразу из контекста :-) Смысл сей статьи в другой фразе, которую ты оставил за кадром:

my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

Не подскажешь, сколько человеко-лет потребовалось, чтобы появился GCC 5? :-)

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

Clasp

Да, спасибо. Я сейчас подробнее посмотрю, что он может в плане интеграции с С++.

//Психиатр

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

my point is that CClasp has come a long way from being hundreds of times slower than C++ to within a factor of 4.

Это не CClasp прошел путь, это мужик научился пользоваться LLVM

Не подскажешь, сколько человеко-лет потребовалось, чтобы появился GCC 5? :-)

Тот же вопрос про LLVM.

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

Смысл сей статьи в другой фразе

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

Тогда как за это время на обычном C++ можно было решать прикладные проблемы не имея тормозов со скоростью выполнения.

А если нужен клей, который бы позволял дергать что-то, написанное на C++, то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

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

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

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

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

то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

Можно было бы. Но человек взял Лисп. Это значит, что он из академической среды. Простим ему это.

Clasp exposes the Clang AST library and the Clang ASTMatcher library. This allows programmers to write tools in Common Lisp that automatically analyze and refactor C++ programs. Clasp can be used to automatically clean-up and refactor large C++ codebases!

Может оказаться очень полезной вещью даже для тех, кто шаблоны не пишет))

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

Это не CClasp прошел путь, это мужик научился пользоваться LLVM

Это проблема восприятия :-) Мужик написал, что «CClasp прошёл путь» :-) tailgunner прочитал это как «научился пользоваться LLVM» :-)

Тот же вопрос про LLVM.

Ну да :-) И тот же вопрос про SBCL, который вообще со времён CMUCL :-) Мой поинт в том, что мужик фактически в одиночку проделал за относительно короткий срок работу, продемонстрировав отличный результат :-)

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

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

...и эта работа заключалась в использовании LLVM, чтобы получить результат в 4 раза хуже, чем дает... LLVM же!

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

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

Думаю, что там дергаются методы, который LLVM выставляет наружу. И которые используются штатными инструментами из LLVM, вроде clang analyzer и clang-tidy.

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

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

А несравненная сложность разработки? А сегфолты? А тормоза на действительно больших приложениях?

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

...и эта работа заключалась в использовании LLVM, чтобы получить результат в 4 раза хуже, чем дает... LLVM же!

Оттуда же:

Our goal is to make Clasp the fastest and most capable dynamic scripting language for C++ libraries.

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

А несравненная сложность разработки?

Несравненная с чем - с божественным Лиспом? Ну тут-то вообще все сливают, это да.

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

Этому тезису столько же лет, сколько и Lisp-у. Странно, что в него еще верят.

Я всё-таки уверен, что рано или поздно («более нормальное») метапрограммирование доберётся до мейнстрима. Подвижки есть и в «маргинальных» языках: в D кое-что, относительно С++, добавилось, в расте есть гигиенические макросы, в скале есть макросы. В «мейнстриме» тоже: roslyn/compiler as service для С#, насчёт джавы хз, но в джава-мире ситуация несколько проще - кому надо, тот может взять ту же скалу или кложуру.

Разумеется, это не значит, что все программы станут из него состоять.

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

А я говорю о результатах.

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

Разница в 4 раза — это уже очень хорошо.

//Психиатр.

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

А несравненная сложность разработки?

Почему вы думаете, что в C++ сложность разработки обязательно гораздо выше?

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

А сегфолты?

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

А тормоза на действительно больших приложениях?

А уж какие тормоза случаются в больших приложениях на JVM...

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

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

дергать что-то, написанное на C++, то можно было не делать новый Lisp, а взять Lua, Python, Ruby или еще что-нибудь в таком роде.

Правило Гринспуна же.

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

Нехорошо коверкать цитаты. А насчет божественного Лиспа - за счет того, что никто не пишет на Лиспе (ну, кроме немногих, хм, увлеченных людей), нет никаких объективных сравнений скорости разработки на Си++ и Лиспе. А сравнивая скорость раработки на попсовом Python, я не вижу никаких чудес - всё так, как должно быть.

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

Разница в 4 раза — это уже очень хорошо.

Хорошо для чего? Если для клея, то пофиг; если для основного рабочего языка - ну, nice try, да.

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

Нехорошо коверкать цитаты.

это не я, это спеллчекер, который думяет, что умнее меня.

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

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

Почему не стоит? :-) В Common Lisp есть декларации типов, декларации оптимизации, декларации проверок времени выполнения, применяя которые можно ожидать ровно того, на что способен компилятор Лиспа в машинный код :-) На практике, скорость очень близка к C, а иногда даже превосходит C - простой пример - парсер заголовков/multipart HTTP :-)

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

In this benchmark, fast-http is 1.25 times faster than http-parser, a C equivalent.

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