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

Парадигма уже сильно другая.

Стоп :-) Какая именно, ведь цепепе же мульти-парадигменный язык программирования :-)

А С++17 будет вообще няшечкой.

А стандарт уже будет 1300 + 500 = 1800 страниц? :-)

Ниша С++ — это хранение и тяжеловесная обработка больших массивов данных. Коих будет становиться всё больше и больше, и обработка всё сложнее и сложнее. И библиотеки такие есть в разработке.

Ого! :-) Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++ :-)

Вот есть такой язык R, который внезапно из никому не известного инструмента штатного статистика стал основным инстументом в data science.

В R нет маразматической системы типов, которая выкручивает руки :-) (Цепепешники любят термит «компилятор бьёт по рукам» и думают, что это круто.) :-) Поэтому он и пользуется популярностью как простой и полезный инструмент, который помогает делать что-то полезное, а не строчить концепты с шаблонами, с трэйтсами и перегрузками операторов >> << :-)

Язык ужасный, но за него очень хорошо платят. А потому его учат.

Печально, что приходится учить ужасные языки ради бабла :-)

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

Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++

Они в курсе, и сами про это периодически пишут. А большинство СУБДшников вовсе не связывается ни со скобками 60-х, ни с недоассемблерами 70-х.

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

Стоп :-) Какая именно, ведь цепепе же мульти-парадигменный язык программирования :-)

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

А стандарт уже будет 1300 + 500 = 1800 страниц? :-)

Может и больше даже. И что? Прикладным программистам он весь — не нужен. Он весь нужен только разработчикам компиляторов.

Ого! :-) Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++ :-)

А ты внутренности PostgreSQL видел? Знаешь, какие там внутренние структуры данных? Там метапрограммирование бы очень сильно всё упростило. А обобщение структур данных позволило бы расширять систему гораздо меньшими усилиями. Но никто ничего переписывать не будет, проще написать новый Посгрес. И они пишутся. Тяжелая Big Data переезжает на С++. А та, что остается в Java, бежит из heap в offheap.

Печально, что приходится учить ужасные языки ради бабла :-)

Такая суровая жизнь, я тебя понимаю)

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

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

Т.е. метапрограммировать в цепепе-14 можно чаще, но учить для этого «упростившееся метапрограммирование» по стандарту не нужно :-) Гг :-)

Тяжелая Big Data переезжает на С++.

Покажи хоть одну СУБД на C++, которая хоть как-нибудь себя хорошо зарекомендовала среди просто люда? :-) Ну есть, например, SciDb. Но кто её использует? :-)

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

https://www.rethinkdb.com/

Это новинка :-) Где данные об использовании по ней? :-) Кстати, если кто не знал, вот что однажды сказал её со-основатель: «We don't use Lisp, but much of our software is built on ideas borrowed from Lisp. We don't use it because we needed low level control — most of the code is written in C++, even with some bits of assembly. But we've borrowed an enormous number of ideas from Lisp. In fact, if we weren't Lispers, we would have built a very different (and I think significantly more inferior) product.» отсюда

https://www.mongodb.org

Ок :-) Но в PostgreSQL есть jsonb :-)

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

We don't use it because we needed low level control

Нормальное решение для осей с сишным интерфейсом и рантаймом. Если бы была лиспоось, писали бы на лиспе для «we needed low level control».

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

Нормальное решение для осей с сишным интерфейсом и рантаймом. Если бы была лиспоось, писали бы на лиспе для «we needed low level control».

Но суть то «But we've borrowed an enormous number of ideas from Lisp. In fact, if we weren't Lispers, we would have built a very different (and I think significantly more inferior) product.» :-)

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

большинство СУБДшников вовсе не связывается ни со скобками 60-х, ни с недоассемблерами 70-х

А какая разница на чем реализована СУБД? Аналитику ты пишешь всяко на SQL+расширения. Дергать запросы и хранимки можно хоть из перла. Вообще не вижу каким боком тут C++. Или суровый программист сначала реализует свою СУБД, и без этого бигдата не считается?

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