Новости Rust #2 (октябрь 2018)

    КДПВ с тыквой, потому что хэллоуин


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


    В этой подборке: Rust 1.30, Rust 2018, конференция RustRush, Amethyst 0.9, сквотинг crates.io, сборщик мусора, споры про 2D графику, Non-lexical lifetimes, функциональный GUI.


    Rust 1.30 и тестирование Rust2018


    Вышел Rust 1.30 (обсуждение). Основные нововведения — частичная стабилизация процедурных макросов, импорт макросов через обычный use, улучшение системы модулей, "сырые" идентификаторы и поддержка no_std приложений (подробнее в хабропереводе).


    Rust 1.31 будет первым выпуском редакции (edition) "Rust2018" (что за "редакции"?), в связи с чем всех желающих приглашают подключаться к тестированию бета версии 1.31 и cargo fix.


    RustRush 2018: конференция 15-16 декабря в Москве


    RustRush 2018 — конференция для разработчиков на Rust, посвящённая вебу, блокчейну, высокой производительности и системному программированию.


    Обновился сайт (rustrush.ru) — опубликован почти полный список докладчиков и программа, начата продажа основной партии билетов.


    Будут четыре участника проекта Rust Language: Стив Клабник, Эшли Уильямс, Паскаль Хертлиф, Катарина Фей. Из других звёзд локальных и не очень — Максим Лапшин с прошивкой IP-камеры, Костя Степанов и Пьер Кригер aka tomaka. Программа.


    Если кто-то хочет подать доклад, до 19 ноября открыт Call for Papers.


    лого rustrush


    WebAssembly



    Embedded


    • rust-industrial-io — используя libiio, предоставляет доступ к промышленным сенсорам и приводам;


    • Начата разработка cortex-r-rt — рантайм пакета для Cortex-R процессоров;


    • keypad — драйвер для клавиатурных матричных схем;


      схема


    • Bluetooth Low Energy with Rust (обсуждение);


    • Со стабилизацией #[panic_handler] в 1.30, стала возможна разработка Cortex-M приложений, работающих без ОС, с использованием стабильного компилятора.


    • shared-bus (код) — позволяет безопасно делить периферию между устройствами при помощи мьютексов;


    • Embedded WG (рабочая группа) растет: уже 27 разработчиков в 11 командах;



    Ржавый игрострой



    Сквотинг на crates.io


    Споры о том, должен ли crates.io начать поддерживать пространства имен/организации, почти не прекращаясь идут с самого появления cargo. Просто кину тут список из нескольких за последние годы:



    Вопрос сложный, конца срачу не видно. Кто-то пару недель назад психанул и решил то ли заддосить, то ли заспамить репозиторий:



    Несколько часов пользователи сервиса испытывали проблемы с доступом. По итогам сильно ничего не изменилось: ввели несколько дополнительных правил против откровенного спама, дискуссии возобновились с удвоенной силой, создав в процессе еще несколько Pre-RFC. Посмотрим, куда оно все в итоге придет.


    Shifgrethor GC


    withoutboats, в процессе исследования на что способно новое, еще не стабилизированное Pin API, написал экспериментальную библиотеку для сборки мусора — Shifgrethor — и опубликовал серию статей о том как и почему она устроена:



    Это не первая попытка реализовать ржавую GC библиотеку (когда-то в языке вообще были @-указатели для этой цели), но от прошлых попыток эта отличается использованием нового механизма Pin'ов.


    Поскольку библиотека зависит от Pin API, она пока не может работать на стабильной Ржавчине. Лодочник несколько раз повторяет, что проект пока что чисто исследовательский и он даже не уверен где именно будет иметь смысл применять эту библиотеку — скорее всего для интеграции с GC других языков или реализации сложных структур данных.


    Обсуждение Shifgrethor на IRLO.


    Серия заметок о 2D графике



    Почему взять и создать универсальную библиотеку для 2D графики на все случаи жизни не получится? Очень занимательно, рекомендую полистать сами статьи и комментарии к ним.



    Заметки про Non-lexical lifetimes (NLL)


    Нико опубликовал несколько заметок о том как NLL (что это такое?) будет сразу встроен в следующую редакцию Rust'а (пока что его надо явно включать через feature(nll)), о его реализации и проблемах, которые предстоит решить в будущих итерациях анализатора заимствований (borrowck):



    Для желающих закопаться немного глубже есть еще URLO тема.



    Azul


    Даже по комментариям к прошлому ежемесячнику видно что GUI — больное место Ржавчины. Очередная попытка заткнуть эту дыру в экосистеме: Azul — функциональная IMGUI библиотека с кешированием состояния, использующая WebRender для отрисовки (обсуждение).


    Подробности смотрите на сайте проекта: azul.rs.



    Одной строкой



    Новые и обновленные пакеты



    Новые RFC


    По RFC довольно удобно наблюдать, в какую сторону движется язык, так что вот несколько интересных. В заголовке PRов есть ссылка "Rendered", по которой RFC доступен в удобочитаемой форме.


    • RFC 2436 Formatting guidelines — очередной шаг к установлению диктатуры Единого Официального Стиля Оформления Rust Кода;
    • RFC 2476 Clippy 1.0 — устаканили какой функционал clippy должен быть стабилизирован;
    • RFC 2457 Allow non-ASCII identifiers — многострадальный и срачегонный RFC, прошедший уже далеко не одну итерацию;
    • RFC 2451 Re-Rebalancing Coherence — позволит реализовать impl<T> ForeignTrait<LocalType> for ForeignType<T>;
    • RFC 2581 Generic integers — предлагает добавить uint<N> и int<N> целые типы;

    И вот еще несколько Pre-RFC обсуждений:





    Это все, спасибо за внимание!


    Если я не добавил какую-то важную ссылку или событие, смело закидывайте в комментарии. :)


    КДПВ взята отсюда, остальные картинки из сайтов соответствующих проектов.

    • +43
    • 3,9k
    • 9
    Поделиться публикацией

    Похожие публикации

    Комментарии 9
      +2
      *взглянул на тыкву на КДПВ* АААААААААА!
        +1

        Вот мне интересно, как внутри раста различают RFC которые IETF и свои?

          +1

          В идеале, никак не должны отличаться. По крайней мере процедуру одинаковую проходят.

            0

            Я скорее про ссылки в коде и документации. Ссылаются ли в коде на RFC из Rust'a?
            Допустим, когда я вижу что-то типа RFC 5389 Section 15.2, я понимаю, что это ссылка на описание STUN, аттрибут XOR-MAPPED-ADDRESS.

              +2

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


              Допустим, когда я вижу что-то типа RFC 5389 Section 15.2, я понимаю, что это ссылка на описание STUN, аттрибут XOR-MAPPED-ADDRESS.

              По умолчанию "RFC" значит именно ржавые, а для IETF, IAB, ISOC или еще каких явно указывается префикс организации:


              As stated in the User Datagram Protocol's specification in [IETF RFC 768], UDP is an unordered, unreliable protocol;
                0

                О, спасибо! С таким форматом документации проблем не должно быть, удобно.

                  0

                  Я сейчас посмотрел, и мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру (до тех пор, пока не появились ржавые RFC, которые уже пересекаются).


                  Может я чего-то не понимаю?

                    +3
                    мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру

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


                    до тех пор, пока не появились ржавые RFC, которые уже пересекаются

                    Я не уверен что Rust это первый проект, который стал свои формализованные предложения обзывать "RFC": быстрый гуглеж показывается как формальные "MS RFC" еще аж в 2006ом году, так и просто неформальное использование аббревиатуры, например, на форумах D в 2011ом. А за последние годы так вообще распространенной практикой стало (хотя это уже, возможно, под влиянием ржавчины): emberjs/rfcs, yarnpkg/rfcs и еще десятки.


                    В общем, видимо, если контекст неоднозначен и есть шанс запутаться, то лучше сразу писать "<ИмяПректа> RFC <номер>".

            +1
            Шикарный пост, спасибо

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

            Самое читаемое