The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск языка программирования Rust 0.12, развиваемого проектом Mozilla

10.10.2014 10:27

В преддверии начала подготовки стабильного выпуска языка программирования Rust 1.0, переход к бета-тестированию которого ожидается в конце года, представлен очередной экспериментальный выпуск Rust 0.12.0, продолжающий развитие функциональности и оттачивание языковых конструкций.

Язык Rust развивается проектом Mozilla и сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов). Исходные тексты проекта распространяются под лицензией MIT. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo, написанный на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model).

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

С момента прошлого выпуска внесено около 1900 изменений, среди которых:

  • Большое внимание уделено подготовке документации. Полностью переписано руководство разработчика (The Rust Guide);
  • Продолжено развитие пакетного менеджера Cargo, который в некоторых ситуациях уже вполне доведён до готовности;
  • Переписаны и приведены в соответствие к требованиям по написанию кода реализации многих API в области std;
  • Вторичные библиотеки вынесены из основного дерева исходных текстов и теперь должны быть установлены через пакетный менеджер Cargo. Среди таких библиотек: uuid, semver, glob, num, hexfloat, fourcc;
  • Возможность определения lifetime-аннотаций в определении функции;
  • Поддержка работы в 64-разрядных версиях Windows;
  • В компиляторе rustc реализована эксперментальная поддержка распараллеливания при указания опции "-C codegen-units";
  • Практически доведена до готовности реализация типов с динамически изменяемым размером (Dynamically-sized), для управления данными типами представлено новое свойство "Sized";
  • Свойство "Share" переименовано в "Sync" для избежания ассоциаций с типом "shared reference";
  • Добавлено новое ключевое слово "move" для индикации замыканий, захватывающих значения;
  • Добавлено новый более эффективный тип замыканий - "unboxed closures";
  • Для переименования выражений теперь следует использовать "use foo as bar" вместо "use bar = foo", а также "extern crate foo as bar" вместо "extern crate bar = foo";
  • Изменён синтаксис (например, "[0..4]", "[a, b, c..]") определения блоков в "Slice" и "SliceMut". Для определения входящих диапазонов теперь следует использовать три точки вместо двух, т.е. "0...4" вместо "0..4";
  • Расширены возможности стандартной библиотеки. Переработаны библиотеки Bit-vectors, collections::bitv и collections::btree. Проведена оптимизация в работе компонентов, связанных с вводом/выводом.

Базовые возможности языка:

  • Ориентация на безопасность:
    • Аккуратная работа с памятью - никаких нулевых и потерянных указателей. Автоматическое управление памятью;
    • Контроль изменчивости. Объекты неизменяемы (Immutable) по умолчанию;
    • Безопасность динамического выполнения: обработка сбоев, исключения, ведение лога, RAII / dtors;
    • Typestate: возможность определения сложных инвариантов, контролирующих структуры данных.
  • Ориентация на параллельность и эффективность кода:
    • Явный контроль памяти, контролирование схемы распределения памяти;
    • Крайне лёгкие задачи, формируемые в виде сопрограмм. Лёгкость в порождении тысяч и миллионов подпроцессов;
    • Итераторы в стэке (фактически лямбда-блоки без распределения кучи);
    • Статическая, нативная компиляция с созданием исполняемых файлов ELF, PE, Mach-o;
    • Прямой и простой интерфейс для кода на языке Си;
  • Ориентация на практическое применение:
    • Мультипарадигмальный, функциональный, императивно-процедурный, объектно-ориентированный, поддерживающий параллельную actor-модель;
    • Функции высшего порядка с биндингами;
    • Нет номинальных типов или иерархии типов;
    • Мультиплатформенный, поддерживается Windows, Linux, Mac OS X, *BSD;
    • Хранение строк в UTF-8, разнообразие низкоуровневых типов;
    • Работает с существующими нативными наборами инструментов: GDB, Valgrind, Shark и т.д.;
    • Практическая возможность нарушения правил: возможность игнорирования правил безопасности, если чётко указано, когда и как их нарушать.


  1. Главная ссылка к новости (https://mail.mozilla.org/piper...)
  2. OpenNews: Выпуск языка программирования Rust 0.11, развиваемого проектом Mozilla
  3. OpenNews: Подготовлен вариант GNU Coreutils, переписанный на языке Rust
  4. OpenNews: Выпуск языка программирования Rust 0.10, развиваемого проектом Mozilla
  5. OpenNews: Для GCC подготовлен фронтэнд с поддержкой языка Rust, развиваемого проектом Mozilla
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40791-rust
Ключевые слова: rust
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (68) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:45, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    systemd уже переписали на rust?
     
     
  • 2.2, qqqq (ok), 10:49, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    не, пока тлько core utils - https://github.com/uutils/coreutils
     
     
  • 3.17, Аноним (-), 14:36, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    куда катится этот мир
     
     
  • 4.19, Аноним (-), 15:59, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы против безопасности в утилитах, которые установлены повсеместно?
     
     
  • 5.25, Мяут (ok), 18:02, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уязвимости обычно возникают, там где вносится много новой функциональности: Shellshock из-за специфичной возможности bash (функции в переменных окружения) и реализации heartbeat в OpenSSL, приведшей к Heartbleed-уязвимости.

    И если Rust - это и есть та самая новая функциональность, то cat'у у которого из изменений за последние пару лет - стиль я верю больше:
    http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/cat.c;h=c

     
     
  • 6.27, Аноним (-), 18:30, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Помимо перечисленного, есть специфичные для языков уязвимости. Выход за пределы массива, разыменование нулевого указателя.
     
     
  • 7.55, Мяут (ok), 18:56, 13/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Конечно, они есть. Но в случае с вылизанными coreutils - ИМХО они маловероятны.
     
  • 5.32, Аноним (-), 21:18, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы против безопасности в утилитах, которые установлены повсеместно?

    Теперь давай сюда grep -ri "unsafe" по дереву исходников. Результат скормить wc -l.

     
     
  • 6.35, Аноним (-), 23:13, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты давай-ка посмотри какого размера блоки unsafe. Большинство однострочные, очень просто контролировать. Весь код на C/C++ в Rust считается unsafe. Всё ещё будем считать C++ безопасным?
    Никто не гарантирует полной непробиваемости. Всегда найдётся тупица, который всё поломает. Но по умолчанию в Rust это сделать сложнее.
     
  • 3.18, Аноним (-), 14:38, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    coreutils под лицензией mit? вот извращенцы
     
     
  • 4.23, Аноним (-), 16:51, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чем это хуже coreutils под лицензией BSD?
     
  • 3.60, nich (ok), 03:13, 15/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то мне кажется, что это какая-то несерьёзная реализация coreutils.
     

  • 1.3, yantux (??), 10:55, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –17 +/
    Если речь идёт об управлении памятью, то чем это лучше java?

    Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?

     
     
  • 2.5, Аноним (-), 11:22, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Оно более менее нормально компилируется в native приложение и не тянет за собой JRE. И оно более функционально даже чем Java 8. Хотя слово лучше/хуже это всегда холивар :)
     
  • 2.8, cbs (?), 11:41, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Если речь идёт об управлении памятью, то чем это лучше java?

    Дык ведь... что значит: "лучше"?
    Насколько понимаю, задачи у этих языков слишком разные, чтобы ставить вопрос так.

     
  • 2.9, beam (??), 11:57, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Результат, касательно управления памятью, думаю, один и тот же, а вот цена за него отличается.
    В этой статье есть графики производительности GC в java. http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

    Вы можете легко оценить затраты на безопасное обращение с памятью в rust по сравнению с java разделив значения в графиках на 0.

     
     
  • 3.16, Аноним (-), 14:08, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > оценить затраты на безопасное обращение с памятью в rust по сравнению с java разделив значения в графиках на 0

    Хочешь сказать, что в Rust эти затраты стремятся к бесконечности?

     
  • 2.10, anonymus (?), 11:57, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Что такое сопрограмма? Раньше такого термина не было.

    Ну зачем же так открыто признаваться в своём невежестве. Почитайте Кнута, что ли.

     
     
  • 3.40, Минона (?), 08:36, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Причем тут невежество?
    Это системная проблема современного образования.
     
     
  • 4.49, Crazy Alex (ok), 17:46, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это системная проблема современной нехватки IT-специалистов и локальная проблема конкретного идиота. Благо, для самообразования  в IT есть абсолютно все условия - от горы пособий и онлайн курсов до отсутствия нужды в каком-либо специальном оборудовании чтобы всему научиться на практике.
     
  • 2.12, Аноним (-), 12:01, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот дурачок. Сборщику мусора java до модели памяти Rust как до луны пешком.
     
     
  • 3.15, Led (ok), 13:28, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот дурачок.

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

     
     
  • 4.20, Аноним (-), 16:00, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати да, ни разу не видел вот этого здесь.
     
  • 2.33, Ordu (ok), 22:54, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если речь идёт об управлении памятью, то чем это лучше java?

    Вы ждёте что вам здесь лекцию о Rust прочитают? Сходите лучше на сайт Rust и посмотрите сами, чего они там напилили, чтобы обойтись без вызовов free, запусков GC и без счётчиков ссылок.

    > Что такое сопрограмма? Раньше такого термина не было. Я так понимаю, этот же термин есть в D. Зачем это придумано?

    А это чтобы вы спросили.

     
     
  • 3.61, nich (ok), 03:46, 15/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > посмотрите сами, чего они там напилили, чтобы обойтись
    > без вызовов free, запусков GC и без счётчиков ссылок.

    В rust-е есть и Rc<T> и Gc<T>.

     
  • 2.62, arisu (ok), 03:49, 15/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Что такое сопрограмма? Раньше такого термина не было.

    а-а-а! как же я не заметил это чудо?!

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

     
  • 2.64, rewlad (?), 12:48, 15/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если речь идёт об управлении памятью,
    то это лучше чем в java тем, что не нужен сборщик мусора и расходы на него.
    И это лучше чем в С тем, что не поработаешь случайно с освобожденной памятью,
    и это проверяется во время компиляции.

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

    sync_a();
    return sync_c(sync_b());
    /**[VS]**/
    async_a(function(err){
        async_b(function(v){
            async_c(v,function(w){
                result_handler(w)
            },error_handler)
        },error_handler)
    },error_handler)

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


     

  • 1.4, beerseller (ok), 10:57, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А поддержка динамически подключаемых библиотек там намечается?
     
     
  • 2.6, Аноним (-), 11:33, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хотеть криптолибы на Rust.
     
  • 2.7, Аноним (-), 11:38, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Зачем нам безопасность, нам надо чтобы все само подгружалось!
     
     
  • 3.14, beerseller (ok), 12:35, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Почему само? Я имею ввиду, чтобы можно было выносить разные возможности в отдельные модули (типа backend). И затем при загрузке подгружать нужную библитеку реализации.

    Как пример: разные варианты работы с дисплеем: Модуль для работы с X, wayland, mir, directfb....
    Что-то типа такого. Ну и понятно, что при загрузке таких модулей должно проверяться ABI

     
     
  • 4.21, Аноним (-), 16:00, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и понятно, что при загрузке таких модулей должно проверяться ABI

    Ого. Может быть, и "задачу останова" вы уже решили?

    Или вы имеете в виду версию ABI? Но тогда ваша хотелка реализуется не на уровне языка исходных текстов, а на уровне имён файлов собранной библиотеки, реализуется динамическим загрузчиком ОС, и уже триста лет как.

     

  • 1.11, Аноним (-), 11:57, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Практически доведена до готовности реализация типов с динамически изменяемым размером (Dynamically-sized)"

    а раньше динамические массивы не поддерживались??

     
     
  • 2.13, Аноним (-), 12:11, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Поддерживались.
     

  • 1.22, Аноним (-), 16:22, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >> возможность порождать тысячи и даже миллионы подпроцессов

    Да ну и что, даже аппаратная реализация многопоточности тут не нужна ?

     
     
  • 2.26, Аноним Аналитег (?), 18:10, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> аппаратная реализация многопоточности

    а что это такое?

     
     
  • 3.29, Аноним (-), 20:45, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это то, благодаря чему реализован механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другой, сохраняя значения каждого регистра предыдущего.
     
     
  • 4.30, Аноним (-), 20:47, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    процессами*
     
  • 4.31, Аноним (-), 21:17, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Речь не о процессах и даже не о нитях, это реализовано целиком в пространстве пользователя.
     
     
  • 5.34, Аноним (-), 22:55, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Я это знаю, но тут утверждается, что всё это целиком и полностью реализовано в Ruste'е, особенно "обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов)". Что собственно и озадачило меня :)
     
     
  • 6.41, Бывший школьник (?), 10:19, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Green threads же
     
  • 5.36, Аноним (-), 23:30, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    то есть один процесс-нить сможет изменить глобальную переменную, в другой процессе-ните уже взять её измененной?
     
  • 4.37, Аноним Аналитег (?), 00:51, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> механизм переключения между процессора путем интервального пика таймера, после которого один процесс меняет другой

    т.е. прерывания вы называете аппаратной реализацией многопоточности?

     
     
  • 5.43, Аноним (-), 15:37, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы хотите предложить какую-либо альтернативную реализацию многопоточности, которая бы обходилась без прерываний ?
     
     
  • 6.44, ffirefox (?), 17:36, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так уже давно предлагали. В виндах 3.x это был основной метод организации многозадачности.
     
     
  • 7.45, Аноним (-), 18:37, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Чягоо ?
     
     
  • 8.46, Аноним Аналитег (?), 22:20, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    хе-хе имеется ввиду кооперативная многозадачность, в терминологии ветки обсужд... текст свёрнут, показать
     

  • 1.24, sorrymak (ok), 17:32, 10/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что с GCCRS (Rust для GCC)? Готово для использования?
     
     
  • 2.28, Аноним (-), 18:32, 10/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Едва ли. Впервые о нём слышу, хотя языком интересуюсь.
    После 1.0 можно будет говорить, что что-то готово для использования.
     

  • 1.38, Kodir (ok), 01:33, 11/10/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался гораздо быстрее.
     
     
  • 2.39, inferrna (ok), 07:12, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Им захотелось немного хаскелльщины, а ди, это скорее питонщина.
     
     
  • 3.42, Аноним (-), 14:28, 11/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ты коммиты смотрел у Руста? там Рубистов и ЯваСкриптоПисателей гора.
     
     
  • 4.47, Kodir (ok), 04:12, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это-то и пугает! :)
    У статического языка должны быть статические же реализаторы.
     
  • 3.50, Crazy Alex (ok), 17:57, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ди это что угодно, но не питонщина. По многим причинам, начиная прежде всего с любви к TIMTOWDI. Там у них в рассылке много лет сидит ярый питонист и очень хорошо заметно, как дишные концепции ему всё время не по нраву - то хочет беззнаковые целые убрать, то bounds checks обязательные, то ещё что...

    Собственно, ближе всего к правде то, что и написано на сайте - D is a C++ done right. С хорошим метапрограммированием (которого в Rust вообще нет) и кучей удобств для программиста.

     
     
  • 4.57, kuku (?), 00:20, 14/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    http://doc.rust-lang.org/0.12.0/guide-macros.html

     
     
  • 5.63, nich (ok), 07:53, 15/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > http://doc.rust-lang.org/0.12.0/guide-macros.html

    А можно на макрах исключения забацать?

     
  • 2.48, й (?), 16:24, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > уже несколько лет существовал Ди?
    > ...
    > они бы помогли Ди с библиотеками

    покажите мне green threads в этом переусложнённом монстре.

     
     
  • 3.51, Crazy Alex (ok), 18:14, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем они там? Есть Fibers, есть Tasks, есть libasync. А делать свой менеджер потоков в языке - это ни разу не в стиле D. Вот это как раз было бы переусложнением.
     
     
  • 4.53, й (?), 19:49, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это всё и в Ruby есть. Green threads таки круче.

    Речь не о "менеджере потоков", речь о том, что параллельный софт удобнее разрабатывать на ерланговских green threads, чем на всех этих велосипедах из твоего сообщения. Разработчики Rust это поняли, D -- нет, об чём и речь.

     
  • 4.54, й (?), 19:55, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О. Ещё бонусный вопрос, раз уж вы отрицаете переусложнённость D. Цель: написать UTF-8 в консоль (мы же в 21 веке знаем и про локали, и про юникод, и про винду). В Go это просто как 'Println("что надо"). Приведите не более сложный код на D, если он и правда не переусложнён.
     
  • 2.52, Crazy Alex (ok), 18:14, 12/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем надо было пилить Ржавого, когда до этого уже несколько лет существовал
    > Ди? Если бы у мозилофилов было чуть меньше амбиций и чуть
    > больше мозгов, они бы помогли Ди с библиотеками и язык популяризовался
    > гораздо быстрее.

    У мозилловцев NIH рекордных размеров. От pdf.js до Daala.

     
     
  • 3.56, arisu (ok), 21:24, 13/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    э… а ничего, что Daala — это рыбка?
     
  • 2.58, Artemciy (?), 02:18, 14/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность. К тому же стандартные библиотеки D больше заточены под сборку мусора и нет разграничения памяти между задачами.
     
     
  • 3.59, arisu (ok), 02:42, 14/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > В D нету borrow checker-а, обеспечивающего Rust дополнительную безопасность.

    об этом думают, есть даже DIP.

    > К тому же стандартные библиотеки D больше заточены под сборку мусора

    об этом тоже очень сильно думают, в git-е достаточно много подвижек в сторону @nogc-кода. также Александреску выкатил предварительный вариант refcounted строк, и идут обсуждения про то, как и рыбку, и ёлку: и mark/sweep GC иметь, и при необходимости rc GC. пока что ругаются.

    > и нет разграничения памяти между задачами.

    э? если ты про фиберы (то бишь, сопрограммы) — то да, нет. это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values такое разграничение получится само собой.

    пока что с escape analysis всё не очень весело, потому так.

     
     
  • 4.65, Artemciy (?), 22:42, 17/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > > и нет разграничения памяти между задачами.
    > э? если ты про фиберы (то бишь, сопрограммы) — то да, нет.
    > это, в общем-то, by design, а не flaw. хотя возможно, что из DIP про scoped values
    > такое разграничение получится само собой.
    > пока что с escape analysis всё не очень весело, потому так.

    В Rust это называется task (задача), и она даже не фиберная а обычный поток пока что. Но зато сборщик мусора, когда он появится, будет собирать мусор отдельно в каждой задаче, а не во всем процессе. По моему опыту это охуенно важно.

    Речь не о том, flaw это или не flaw, а о том что дизайн языков довольно разный, поэтому мем о том что Мозилле надо было использовать D, вместо выдумывания нового языка Rust - не совсем верный.

     
     
  • 5.66, arisu (ok), 23:30, 17/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Речь не о том, flaw это или не flaw, а о том
    > что дизайн языков довольно разный, поэтому мем о том что Мозилле
    > надо было использовать D, вместо выдумывания нового языка Rust - не
    > совсем верный.

    а, в этом смысле. тут не спорю. впрочем, я до сих пор не уверен, что сами авторы rust в курсе, что хотят получить на выходе и как это должно выглядеть. но не уверен, что это такой уж огромный недостаток: общая идея у них есть, а что они по дороге насочиняют… может, оно и лучше получится, чем если бы изначально план на скрижалях имелся.

     
  • 5.67, arisu (ok), 23:37, 17/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая на смену владельца, или надеяться, что компилятор сможет сам это разрулить (тоже не лучший вариант, на самом деле), или жёстко message passing (это, собственно, подвид первого варианта). то есть, создать экземпляр какой-то фигни и расшарить её с другим потоком будет уже не просто присваиванием.

    поэтому, например, в D и не внедряют task-local heaps: не очень ясно, как это разруливать так, чтобы и безопасно было, и не надо было ручной код делать, и при этом не потерялась возможность «низкоуровневости».

     
     
  • 6.68, Artemciy (?), 23:25, 18/10/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > p.s. с другой стороны, обмениваться данными между задачами придётся или явно указывая
    > на смену владельца

    В Rust "=" - это move, кстати.
    Для копирования надо явно указывать clone.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру