LINUX.ORG.RU

Rust 0.7

 ,


1

5

3 июля было объявлено о выходе очередной версии Rust — языка программирования, разрабатываемого Mozilla. Новая версия включает в себя около 2000 изменений и исправлений ошибок.

Основные изменения:

  • Изменения в языке:
    • квалификатор видимости больше неприменим к 'impl', только к методам;
    • переписан borrow checker, исправлено множество ошибок;
    • параметр 'self' больше не равен неявно `&'self self` и для него может быть явно определено время жизни;
    • перегружаемые составные операторы ('+=' и пр.) были временно удалены из-за ошибок;
    • циклы 'for' теперь требуют 'for'-итераторов, чтобы вернуть 'bool';
    • 'Durable' trait был заменен `'static`;
    • структуры с атрибутом '#[packed]' выравниваются по байтовой границе;
    • параметры типов, привязываемые посредством 'Copy', должны быть явно скопированы с ключевым словом 'copy';
    • 'Option<~T>' сейчас представляется как nullable-указатель;
    • '@mut' делает динамические borrow checks корректно;
    • функция main теперь ищется только на верхнем уровне. Атрибут '#[main]' валиден в любом месте;
    • поля структур больше не могут быть мутабельными, вместо этого используется унаследованная мутабельность;
    • удалены атрибуты '#[no_send]', '#[no_freeze]';
    • неограниченная рекурсия прерывается при достижении лимита, определенного переменной окружения 'RUST_MAX_STACK' (1gb по умолчанию);
    • удален режим 'vecs_implicitly_copyable', векторы никогда не копируются неявно;
    • атрибут '#[static_assert]' выдает assert'ы о статических булевых переменных во время компиляции;
    • 'argument modes' больше не существует;
    • редко используемая инструкция `use mod` удалена.
  • Расширения синтаксиса:
    • 'fail!' и 'assert!' принимают списки аргументов '~str', '&'static str' или 'fmt!';
    • `Encodable`, `Decodable`, `Ord`, `TotalOrd`, `TotalEq`, `DeepClone`, `Rand`, `Zero` и `ToStr` могут быть автоматически выведены посредством директивы `#[deriving(...)]`;
    • макрос `bytes!` возвращает вектор байтов для string, u8, char и численных литералов.
  • Библиотеки:
    • `core` crate был переименован в `std`;
    • `std` crate был переименован в `extra`;
    • расширена и улучшена документация;
    • добавлен модуль std: `iterator` для внешних итераторов (external iterator objects);
    • std: многие итераторы, написанные в старом стиле, были заменены на реализацию 'Iterator';
    • std: многие внутренние векторы и строковые итераторы (включая 'any', 'all и пр.) удалены;
    • std: prelude теперь не реэкспортирует любые модули, только типы и трейты;
    • std: дополнения в Prelude: `print`, `println`, `FromStr`, `ApproxEq`, `Equiv`, `Iterator`, `IteratorUtil`.

>>> Подробности

Equiv

Весь язык как Доздра Пер Ма ...

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

Вот google сделал GO, а generics и исключений в нем нет.

Генериков там ПОКА нет. Эта вещь, которую все хотят, и которую рано или поздно запилят.

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

Я уже давал эту ссылку, и дам ее еще раз: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-th... - прочитай, оно того стоит.

Решение интересное. Но попробуй предложи писать на Rust разработчиков PostgreSQL, BerkeleyDB, ядер OS, драйверов. Я думаю тебя пошлют куда подальше и будут правы. Им необходимо и достаточно C. И они не испытывают таких неудобств как ты. IMHO в перспективе Rust ждет таже участь, что BitC.

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

Согласен только наполовину. У Go больше шансов выжить, и он не большее говно чем Rust.

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

попробуй предложи писать на Rust разработчиков PostgreSQL, BerkeleyDB, ядер OS, драйверов.

Я пишу драйверы и с радостью бы писал их на Rust. И я не один такой, судя по rust-dev@

Им необходимо и достаточно C

А раньше им было необходимо и достаточно Ассемблера.

IMHO в перспективе Rust ждет таже участь, что BitC.

Он уже избежал судьбы BitC.

У Go больше шансов выжить,

Может быть.

и он не большее говно чем Rust.

Неотключаемый GC, нет дженериков, AДТ, pattern matching, unsafe. Если для тебя это «не большее говно», то... как говорится, you are entitled to your wrong opinion.

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

Тогда пишите свою систему, все более менее распространенные это POSIX а POSIX это C.

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

Я пишу драйверы и с радостью бы писал их на Rust. И я не один такой, судя по rust-dev@

Да, но ИМХО у подавляющего большинства сишников другие подходы к программированию.

А раньше им было необходимо и достаточно Ассемблера.

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

Неотключаемый GC, нет дженериков, AДТ, pattern matching, unsafe. Если для тебя это «не большее говно», то... как говорится, you are entitled to your wrong opinion.

Если ты судишь о ЯП по количеству фич, то да Rust - лидер.

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

Я пишу драйверы и с радостью бы писал их на Rust.

Мне интересно, как ты думаешь сочетать высокоуровневые возможности с низкоуровневыми. Как в C++?

AДТ, pattern matching

Месье поклонник хачкеля?

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

Неотключаемый GC, нет дженериков, AДТ, pattern matching, unsafe. Если для тебя это «не большее говно», то... как говорится, you are entitled to your wrong opinion.

Unsafe есть, дженерики рано или поздно сделают.

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

Мне интересно, как ты думаешь сочетать высокоуровневые возможности с низкоуровневыми.

Пример приведи.

Месье поклонник хачкеля?

Никогда не слышал о таком языке.

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

Тогда пишите свою систему

«Не говорите, что мне делать, и я не скажу вам, куда идти» (ц)

POSIX это C.

Олдовые UNIX-гуру в треде, все в машину.

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

Неотключаемый GC, нет дженериков, AДТ, pattern matching, unsafe. Если для тебя это «не большее говно», то... как говорится, you are entitled to your wrong opinion.

Unsafe есть

Ок. Но всего остального нет? Если да, то я остаюсь при своем мнении.

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

ИМХО у подавляющего большинства сишников другие подходы к программированию.

Конечно, есть любители от души помесить память. Но тот же PostrgeSQL изначально был написан на Lisp, так что...

раньше им было необходимо и достаточно Ассемблера.

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

Никто и не планирует совсем похоронить Си. Задача-максимум - свести его роль к роли, в которой сейчас ассемблер.

Если ты судишь о ЯП по количеству фич, то да Rust - лидер.

Я не сужу по количеству фич. И, даже если бы судил, Rust был бы в лучшем случае середнячком.

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

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

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

Суть вопроса состоит в том, что пока в продакшене POSIX никто от C не откажется. Каким бы он ни был.

Что значит «отказываться от Си»? Просто для протокола: никто не предлагает переписывать всё на Rust; более того, даже если Rust взлетит, он очень долго будет сосуществовать с Си/Си++.

А Капитан спешит напомнить, что на POSIX в продакшене давно пускают кучу языков - от Си++ до Ruby.

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

А Капитан спешит напомнить, что на C++ можно драйвера писать, если уж C так не нравится.

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

А Капитан спешит напомнить, что на C++ можно драйвера писать

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

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

В реальности выбора нет, между Си и доведенным до ума Rust я бы выбрал Rust. Между Си++ и Rust - не знаю; Rust как язык гораздо симпатичнее, но стыковка с Си++-библиотеками у него будет никакая.

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

ООП слишком тяжеловесен для системного программирования, как вы сами писали. Нужно нечто сильно проще но не проще, перефразируя слова товарища Эйнштейна. C реализует минималистичный процедурный подход, возможно даже слишком минималистичный но это упрощает восприятие кода. Если системы начнут писать на C++ их API начнет напоминать boost, оно вам надо?

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

ООП слишком тяжеловесен для системного программирования, как вы сами писали

Я не писал такого. Си++ _как язык_ слишком тяжеловесен, да, но и он пригоден для системного программирования (то, что на нем сейчас не напишешь драйвер для Linux - это другой вопрос; десяток лет назад был успешный проект по использованию Си++ в ядре). ООП вполне годится для системного программирования (собственно, в Linux ООП лепят на основе Си).

Кроме того, современный взгляд на ООП отличается от того, который был в силе во время проектирования Си++: https://lwn.net/Articles/548560/

C реализует минималистичный процедурный подход

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

Если системы начнут писать на C++ их API начнет напоминать boost, оно вам надо?

Во-первых, меня не сильно пугает Boost (к тому же любой действующий ядерный программист видел в ядре вещи немногим лучше Boost); во-вторых, Rust гораздо проще Си++.

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

Если системы начнут писать на C++ их API начнет напоминать boost, оно вам надо?

Капитан утверждает, что плюсовое API совсем необязательно превращать в шаблонное месиво а-ля STL или Boost, ограничившись режимом «C с классами» и используя лишь сравнительно безвредные с точки зрения читабельности кода и [практически] не дающие оверхеда с точки зрения производительности возможности типа неймспейсов, public/protected/private и т.п..

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

ООП != С++. И вообще, если уж ООП нужно в проекте, то можно отказаться от него только в узких местах (если пара дополнительных разыменовываний указателей в vft ужасно бъет по производительности).

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

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

Си был примитивен даже для своего времени, а по сегодняшним меркам он просто убог

Пока будут такие вещи как Arduino или GPU (а они будут всегда) С ни куда не денется. А всяких рустов там ни когда не было и скорее всего не будет

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

Пока будут такие вещи как Arduino или GPU (а они будут всегда) С ни куда не денется

AFAIK, для Ардуино можно писать на Си++, а для CUDA есть шаблоны.

А всяких рустов там ни когда не было

Правда штоле? O_O

и скорее всего не будет

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

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

Правда штоле? O_O

Ну хз может и есть, но видимо на глаза старается не попадаться

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

Проблемы начинаются сразу же, как только приходится работать с чужим кодом. Чем дальше написанное от «твоих 20%», тем сложнее его понимать.

вот это более точная формулировка проблемы

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

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

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

Это как сказать, что ассемблер убог :) просто язык низкого уровня. И зато простой же очень.

высокоуровневый ассемблер безусловно нужнен

но я не согласен с тем. что си — простой, или си — это высокоуровневый ассемблер

вот пример:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

int main(int argc, char** argv)
{
  assert(argc==2);
  unsigned char a = (char) atoi(argv[1]);
  unsigned char b = a*3;
  unsigned char c = (   b  +1 ) / 2;
  unsigned char d = ( (a*3)+1 ) / 2;
  printf( "%d %d\n", (int)c, (int)d );
  return 0;
}

что напечатает программа, скажем, если ее запустить как "./a.out 128"?

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

В смысле ты о том, что c!=d? Ну, приводит оно их к int'у, а чо делать-то ещё? Работа с числами разного размера хоть какие-то вопросы всегда вызывает, очевидно.

Или там ещё какие-то нюансы в разных компиляторах?

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

Ну, приводит оно их к int'у, а чо делать-то ещё?

как «чо делать»?!

когда речь об высокоуровневом ассемблере, он *должен* вычислять в рамках именно char, а еще лучше — в рамках int8_t, а не приводить к *хрен знает* какому инту

если у меня умножение было бы не на 3, а на больше, то там уже на разных машинах (с разным размером инта) результат был бы вообще разный

даже само то, что int8_t появился относительно недавно, говорит о том, что си — это не высокоуровневый ассемблер

даже если в архитектуре нет вычислений *именно* с int8_t, то все равно их можно и нужно программно эмулировать

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

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

Общего для всех понятия красоты нет ни в C++, ни в C, ни в Java, ни в любом другом ЯП. Такая вот пичалька.

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

кстати, к моему примеру можно придраться, сказав, что литералы «1», «2», «3» имеют тип инт, и поэтому логично продвинуть тип до инта, дабы (попытаться) сохранить точность

поэтому правильный пример должен быть таким:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

int main(int argc, char** argv)
{
  assert(argc==2);
  unsigned char one   = 1;
  unsigned char two   = 2;
  unsigned char three = 3;
 
  unsigned char a = (char) atoi(argv[1]);
  unsigned char b = a*three;
  unsigned char c = (      b   +one ) / two;
  unsigned char d = ( (a*three)+one ) / two;
  printf( "%d %d\n", (int)c, (int)d );
  return 0;
}
www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

Общего для всех понятия красоты нет ни в C++, ни в C, ни в Java, ни в любом другом ЯП. Такая вот пичалька.

знаешь известный рассказик (м.б. стишок маршака) про мальчика, дедушку, и осла? как они не садились друг на друга, все выглядело по-идиотски

так вот дизайнеры языков решили, что одного осла хватит на всех, и в результате «общего для всех понятия красоты нет», гы-гы

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

Месье поклонник хачкеля?

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

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

Представления Гвидо о красоте кода не являются общими для всех, тем более что даже в стандартной библиотеке полного единства оформления кода не наблюдается.

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

Это не плохая попытка. И есть куда ткнуть людей. Другое дело в c-подобных языках где такого стандарта даже близко не наблюдается.

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

Это не плохая попытка. И есть куда ткнуть людей.

Именно что попытка. И ткнуть можно, но не стоит удивляться, если после такого тычка тебя пошлют куда-нибудь. А всё потому, что понятие красоты (хоть кода, хоть чего) субъективно и общим для всех можно считать разве что некое компромиссное решение, к которому постепенно пришло сообщество разработчиков, но никак не инструкции от одного-двух человек, написанные в соответствии с их мнением о красоте кода. Впрочем, справедливости ради отмечу, что PEP 8 никому не навязывается и в нём недвусмысленно написано, что следование этому PEP-у хорошо, но ещё важнее просто сам факт использования в проекте единого стиля оформления кода.

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

Вы можете написать конкретно, по пунктам, почему вы не можете писать драйвер под линукс на C++?

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

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

Zen of Python написан не Россумом, а питон-хакером. Так что это не «представление Гвидо о красоте».

Virtuos86 ★★★★★ ()
Ответ на: комментарий от A-234

Драйверы на Си++ просто не поддержваются. Невозможно задать правило сборки, в сырцах используются идентификаторы вроде class, generic структуры дьанных всё равно сделаны в виде макросов - это только то, что сразу приходит в голову. Написать дра йвер, наверное,.можно, но усилия на это съедят весь профит

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

Мне интересно, почему вы считаете что с Rust таких проблем не будет?

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

Вначале, они, конечно, будут. Но 1) Си++ уже официально отвергнут как язык для написания кода ядра 2) Rust еще может собрать вокруг себя достаточно квалифицированное и активное сообщесвтво, чтобы пролезть в ядро

И, конечно, 3) не ядром единым.

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

Ты так говоришь, что я захотел потыкать этот раст. Пусть меня скастуют в новость о выходе стабильной версии. Да-да, я про ту, в которой не будет перегружаемые составные операторы ('+=' и пр.) были временно удалены из-за ошибок;

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

Пусть меня скастуют в новость о выходе стабильной версии. Да-да, я про ту, в которой

Если тебе в самом деле интересно, просто следи за новостями. Сам.

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

Мечты, мечты, а в реальности хотите иметь ООП для дров - пилите свое ядро, ЧТД. По своему опыту драйверописания сужу, небольшому конечно, только Linux и Solaris. Можно накропать библиотеку типа MFC для ООП драйверов но ее создание и поддержание представляется мне кошмаром. Даже для солярки, про линукс и подумать страшно.

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

Мечты, мечты

Надежды.

в реальности хотите иметь ООП для дров - пилите свое ядро

В реальности тебе нужно пешее эротическое путешествие.

Можно накропать библиотеку типа MFC для ООП драйверов

Долгое путешествие.

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

Да, отсутствие логики в рассуждениях это самый неопровергаемый аргумент. Все вроде сам уже написал, и С++ нам злобный Торвальдс в ядре использовать не дает, и Rust манит потому что его нету но есть желание чтобы был, и мифический профит от шаблонов пока мерещится но уже вот вот. Казалось бы, очевидно что нынешние ядра не подходят, но стоит об этом заговорить как начинается истерика.

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