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)

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

psql изначально был написан на нем.

И это же можно назвать эпитафией ему. Печать наискось - не годится для серьезной СУБД.

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

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

psql изначально был написан на нем.

На Лиспе была написана экспериментальная СУБД Postgres, которая потом стала POSTGRES95, а потом - PostrgeSQL. Так что никогда не было PostgreSQL на CL.

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

> Так что никогда не было PostgreSQL на CL.

На Лиспе была написана экспериментальная СУБД Postgres

А без нее не было бы PostgreSQL.

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

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

Блин, человеческой тупости не перестаешь удивляться. C++ играет на поле языков без GC. Без GC. Соответственно, более лучшие альтернативы нужно показывать на этом поле. И где они, кроме обсуждавшегося здесь изначально Rust-а?

А в полку языков с GC есть много достойных языков, которым CL в силу своей маргинальности, сольет по полной программе.

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

Ну так на CL написали прототип, потом на Си - реальную систему. Всё правильно.

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

Не SQL но AllegroGraph.

Да уж, примеров хоть завались. Выше уже приводилось достаточное количество СУБД разных типов на C++.

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

А без нее не было бы PostgreSQL.

LOL, авторы выбирали из:

C C++ MODULA 2+ LISP ADA SMALLTALK

Причем С++ не был выбран только из-за того, что в 1985 не было достаточно стабильного компилятора. В итоге начали писать на связке С и лисп. Но после признали, что «the use of LISP has been a terrible mistake», по тем причинам, что он тормозной, жирный, GC только мешал, а связка С/Lisp была крайне неудобной. Если бы С++ тогда уже вылез из пеленок, то и PostgreSQL вполне вероятно был бы на нем.

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

Причем здесь GC? Это детали реализации.

«Any response time sensitive program must therefore allocate and deallocate space manually» (c) авторы POSTGRES, отказавшиеся от лиспа.

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

Причем здесь GC? Это детали реализации.

Звиздец, занавес.

Простите мне мой французский, но нет смысла продолжать разговор.

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

«Any response time sensitive program must therefore allocate and deallocate space manually» (c) авторы POSTGRES, отказавшиеся от лиспа.

Они не осилили писать не лиспе без консинга? А как же ынтырпрайз на Жабе?

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

ну и к слову - осилили, но при этом сделали логичный вывод - а нахрена им тогда лисп, если его и так немного, а писать на нем приходится с ограничениями.

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

Не о том вопрос.

Отсутствие GC в C++ делает C++ тем языком, которым он является. Со всеми его проблемными местами. Включая сложность разработки и сегфолты.

Судить о языках, не понимая таких элементарных вещей, это мощно.

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

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

может быть занимательно: Rust vs. C++: Fine-grained Performance

Да, интересно. Правда мне показалось, что некоторые штуки, на отсутствие которых автор жалуется, в языке присутствуют. Например, then_some (в виде and_then).

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

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

В каких-таких точках? И что в это время будут делать ждущие клиенты?

// captcha: boontu

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

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

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

//Психиатр

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

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

Но разве, если иметь необходимые возможности, этот самый генератор парсеров не может быть доступен в виде («мета»)библиотеки для языка? Авторы который, точно так же, могут «разобраться больше», чем среднестатистический пользователь?

Внешние инструменты, как правило, предлагают какие-то готовые средства для отладки и/или трассировки происходящего во время парсинга. Что значительно облегчает создание собственного парсера.

Опять же, разве отлаживать будет не наоборот проще, если это будет делаться в рамках одного языка?

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

Почему?

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

Отсутствие GC в C++ делает C++ тем языком, которым он является

Строго говоря, отсутствие GC и присутствие деструкторов, чувствительных к границам видимости объектов.

А ручное управление памятью и в С есть.

//Психиатр

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

Блин, человеческой тупости не перестаешь удивляться.

Это точно :-)

А в полку языков с GC есть много достойных языков, которым CL в силу своей маргинальности, сольет по полной программе.

Какому именно достойному языку с GC сольёт CL? :-) И в чём сольёт конкретно? :-)

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

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

В том смысле, что ниш(и) толком нет (ещё)?

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

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

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

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

Могу.

А ты озвучить конкретны претензии?

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

Но разве, если иметь необходимые возможности, этот самый генератор парсеров не может быть доступен в виде («мета»)библиотеки для языка? Авторы который, точно так же, могут «разобраться больше», чем среднестатистический пользователь?

Боюсь, мы сейчас начинаем уходить в какие-то дебри фантазии.

Если говорить про то, что есть. А есть, если не брать в расчет Lisp-ы, динамика, вроде Python/Ruby, в которой нет такого понятия, как компиляция. Там даже описание класса — это лишь последовательно исполняемая последовательность команд, в которую можно вставить свою последовательность инструкций и это приведет к модификации того самого класса, который в данный момент декларируется. На этом построена вся Ruby-овая магия по «метапрограммированию».

Так что в динамике с таким подходом нет никаких проблем.

А вот если взять статику, то ситуация несколько сложнее. Не спец в таких делах, но некоторое время назад всплывала тема т.н. stagging-а. Насколько помню, речь там шла о том, что трансляция программы выполнялась в несколько этапов: сначала транслировался какой-то модуль, который затем подгружался в состав компилятора и предоставлял компилятору свою функциональность, затем компилировался следующий модуль, который так же подгружался в состав компилятора и т.д. Соответственно, при компиляции i+1 модуля этому модулю были доступны конструкции, которые стали частью компилятора после трансляции модулей 1,2,...,i.

В этом плане какой-нибудь генератор парсеров вполне может стать неким модулем (i-N), который войдет в состав компилятора и будет доступен при компиляции модуля (i+1).

Но, насколько я помню, все это было красиво для управляемых сред (вроде JVM или .NETа). А вот как реализовать stagging для нативных языков вроде C++... Понятия не имею.

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

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

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

Почти неотличимо от C89 (и малоотличимо от K&R).

Да, семантически и синтаксически ничего не поменялось почти :-) И это свидетельствует о его правильном дизайне, о его нишиевости :-) В стандарт C11 добавили потоки, главным образом :-)

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

Строго говоря, отсутствие GC и присутствие деструкторов, чувствительных к границам видимости объектов.

Плюс совместимость с языком C и завязанность на стандартную библиотеку языка C.

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

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

Какому именно достойному языку с GC сольёт CL? :-)

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

И в чём сольёт конкретно? :-)

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

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

Или язык тоже обрастёт своими костылями

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

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

Так что ждем Rust2, в котором, как в D2, учтут ошибки Rust :)

//Психиатр

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

В том смысле, что ниш(и) толком нет (ещё)?

То, что ниши пока нет — это просто текущая ситуация, отправная точка, так сказать. Если Rust стрельнет, то может быть и у него сложится так, что суровые embedded-щики будут писать на одном подмножестве Rust-а со своим набором библиотек... А ученые, статистики и финансисы, занимающиеся machine learning и big data — на совсем другом подмножестве Rust-а совсем с другими библиотеками.

А ведь в C++ сейчас именно так.

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

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

Для этого как раз и имеет смысл запускать сборщик мусора вручную - чтобы сделать поведение более предсказуемым, систему более стабильным :-) Для этого в Лиспах и есть возможность дёргать GC, скажем, каждые t секунд :-)

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

В расте, по сути, такие же деструкторы.

Совершенно верно. В дополнение к афинным типам.

//Психиатр

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

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

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

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

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

где бенчмарки?

Haskell

В количестве готовых и качественных инструментов

сомневаюсь

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

Scala, C#, Haskell. Да имя им легион. Даже Java 8.

И чем же эти языки лучше Common Lisp? :-)

В количестве готовых и качественных инструментов

Так в количестве и в качестве :-) У нас вот есть SLIME - качественный инструмент :-)

, в развитости инфраструктуры

Что под этим понимать? :-) Тонны говённых библиотек? :-)

, в размерах коммьюнити.

Тут CL сольёт любому языку :-) Ты прав, Женя :-)

Даже в стоимости средств разработки.

SLIME бесплатен :-) Макросы бесплатны :-) Любой язык тут сольёт CL :-)

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

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

А потом через 25 лет он, наконец, осмелился и сделал auto :-) И рукоплескали адепты дедушке, и были радостны и благодарны! :-) Бугага :-)

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

Или ты про кастомные аллокаторы, которые их не дергают?

В основном, про них. Писать на С++ и не писать/не использовать готовый кастомный аллокатор — а зачем тогда писать на С++?

//Психиатр

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

И чем же эти языки лучше Common Lisp?

Достаточно уже того, что это не Lisp-ы. Но вы не поймете.

Тонны говённых библиотек?

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

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

Достаточно уже того, что это не Lisp-ы. Но вы не поймете.

А, понятно :-) Аргументов нет в силу не знания ни одного из тех самых языков :-) Слив засчитан :-)

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

Я делаю софт не для того, чтобы им или мной восхищались :-)

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

Писать на С++ и не писать/не использовать готовый кастомный аллокатор — а зачем тогда писать на С++?

Понт защитан %)

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

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

Возможно. С другой стороны - если инструмент не доступен, то заменители становятся привычными и становятся нормой. Точно так же, хватало противников, скажем, лямбд в плюсах - мнол жили и без них неплохо.

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

Кстати, рефлексия (этапа компиляции) в С++ тоже была бы полезна...

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

В интернетах, вестимо.

То есть, не пруфа. Ок.

Да кто ж вам запретит.

Написал ли ты большое приложение на Haskell используя эти прелестные инструменты опять же на Haskell, чтобы мнение не было голословным?

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