Разработчик
0,0
рейтинг
10 января в 14:53

Разработка → Rust в 2016 году перевод

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

2015


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

В 2015 году силами сообщества Rust:


2016


Как и во второй половине 2015 года, я ожидаю увидеть много постепенных усовершенствований в 2016 году: полировку библиотек, исправление ошибок компилятора, улучшение инструментов и увеличение количества счастливых пользователей. Также на горизонте есть довольно много крупных изменений – последние месяцы мы провели много времени занимаясь планированием, рефакторингом и консолидацией проекта, и я ожидаю что это принесет свои плоды.

Язык


Cпециализация реализаций (impl specialization) – это возможность иметь несколько реализаций типажа для одного типа, когда существует возможность определить наиболее частную из них. Это открывает возможности для оптимизации и решает некоторые раздражающие вопросы. Существующий RFC почти принят и работа идет полным ходом. Хороший выбор для начала 2016 года.

Последнее время мы также обсуждаем эфективную реализацию наследования (а-ля виртуальные структуры). Существует некая красивая взаимосвязь между специализацией и наследованием, так что большая часть плана уже составлена. Пока все еще остаются кое-какие важные пробелы, но я надеюсь, что они будут заполнены.

Еще одна новая возможность системы типов, обсуждаемая последнее время, – это абстрактные типы возврата (abstract return types, иногда также называемые «impl trait»). Она позволяет использовать типаж (вместо типа) в качестве возвращаемого значения функции. Идея проста, но есть несколько больных вопросов, которые нужно будет решить. Но поскольку у сообщества существует потребность в этой возможности, я думаю, что она будет реализована в 2016 году.

Новая система выделения памяти и синтаксис размещения (placement box syntax) позволит Rust удовлетворить кучу потребностей системного програмирования (например, позволив выбрать аллокатор для некоторой коллекции). Также это дверь к возвращению сборки мусора в Rust. Felix Klock упорно трудится над дизайном и реализацией, чтобы эти возможности появились в этом году.

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

Одной из не самых сильных сторон Rust является обработка ошибок. Мы обсуждали различные варианты сделать ее более удобной, и похоже что в скором времени любимый вариант будет принят в качестве RFC. Это предложение добавляет оператор ?, который работает аналогично макросу try! (например, можно будет писать foo()? там, где сегодня вы пишете try!(foo())), а также вводит новое выражение try ... catch, которое позволяет перехватывать и обрабатывать исключения. Я ожидаю, что это предложение (или во всяком случае очень похожее) будет принято и реализовано очень скоро.

Мы могли бы, наконец, сказать до свидания drop-флагам. Так или иначе, мы мечтаем об этом.

Библиотеки


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

Библиотека libc в значительной степени устаканена, так что я думаю что в этом году она будет полироваться и двигаться в направлении стабилизации.

rand – еще один крейт из инкубатора, на стабизацию которого можно расчитывать, и я не думаю что будут происходить какие-либо крупные изменения API в будущем.

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

Также есть несколько действительно интересных пакетов связанных с параллелизмом: crossbeam, rayon, simple_parallel, и другие. Я понятия не имею к чему в конечном итоге мы прийдем в этой области, и мне очень интересно будет это увидеть.

Инструменты


Я думаю, что 2016 год будет захватывающим с точки зрения инструментов разработки для Rust. Для нас это направление имеет высокий приоритет, и мне хотелось бы подчеркнуть некоторые вещи, над которыми мы сейчас работаем:

  • инкрементальная компиляция
  • среды разработки (IDE)
  • переписывание и объединение инструментов multirust и rustup
  • улучшение поддержки кросскомпиляции
  • улучшение поддержки Windows
  • пакеты для дистрибутивов Linux
  • инструменты для рефакторинга
  • улучшение работы rustfmt
  • использование Cargo для сборки rustc?

Сообщество


Было здорово наблюдать как растет сообщество в 2015 году, и я надеюсь, что оно вырастет еще больше в 2016. Я с нетерпением ожидаю знакомства с новыми потрясающими людьми и новыми интересными проектами, ожидаю увидеть новые статьи и новые взгляды на язык с точки зрения людей с различным предыдущим опытом, ожидаю больше встреч и больше всего!

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

Я не знаю об официальных планах, но я надеюсь и ожидаю проведения очередного Rust Camp в этом году. На прошлогоднем мероприятии было весело, и я уверен что было бы здорово увидеть продолжение.

Я также ожидаю увидеть как Rust становится все более «серьезным» – его использование в продакшене и важных проектах с открытым исходным кодом. Ожидаю увидеть как существующие проекты на Rust становятся более значимыми сами по себе, а не только как «проекты использующие Rust».

Некоторые вещи, которые, я думаю, не произойдут


Типы высшего порядка – я думаю, все мы хотим их в той или иной форме, но это огромный вызов с точки зрения архитектуры и большое количество вопросов, над которыми нужно будет поработать. Я буду очень удивлен, увидев основательный RFC по внедрению типов высшего порядка в этом году, не говоря уже о реализации.

Обратная несовместимость – после 1.0 мы были довольно хороши в сохранении стабильности и не ломали уже работающие вещи, и я уверен, что мы сможем продолжить эту тенденцию.

2.0 – есть дискуссия по поводу выпуска обратно несовместимой версии Rust, но это выглядит все менее реалистичным для 2016 года. Пока нам удается двигаться в рамках обратно совместимых релизов достаточно хорошо, и нет ничего такого, что потребовало бы от нас выпуска обратно несовместимой версии. Я не думаю, что нам удастся всегда обходиться без выпуска 2.0, но я думаю что это произойдет точно не в 2016 году.

В независимости от того, что именно случится, я верю что 2016 год будет прекрасным годом для всего сообщества. С новым годом!
Перевод: Nick Cameron
Иващенко Иван @defuz
карма
93,2
рейтинг 0,0
Разработчик
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (59)

  • +6
    Как одно из событий 2015, можно также упомянуть активное развитие крутейшей IDE для rust.
  • +1
    Недавно была хорошая статья о том, для кого и зачем сделан язык Go. ИМХО не помешала бы такая же о Rust.
    • +6
      За что минусы-то, да ещё и в карму?.. Я ж ничего обидного про Rust не сказал!
      • +3
        Я бы плюсанул в карму, но плюсовать можно только тех, у которых есть публикации. В итоге только минусовать можно, а те, кто хочет поставить плюс, тупо не могут это сделать. Напиши какую-нибудь статью, будет проще плюсы получать =)
        • +1
          Знаю, что плюсовать не могут, но минусовать-то зачем? Хоть бы объясняли, за что!
          Написать что-нибудь хочу с тех пор, как зарегистрировался года 2 назад, но не о чем мне писать — ничего такого уникального не делал, о чём бы уже не было написано :(
    • 0
      Раст сделан для тех, кто пишет на С и С++ и хочет делать это лучше ценой дополнительной нагрузки на программиста.
      В принципе, все.
      • +5
        «ценой дополнительной нагрузки на программиста» — очень спорная формулировка :). Я бы скорее говорил в направлении перенеса какой-то части нагрузки на программиста со стадии отладки на стадию написания кода.
        • 0
          Да, пожалуй, формулировка не очень.
  • 0
    Я так понимаю уже будет ломающая некоторые пакеты 1.7 версия users.rust-lang.org/t/upcoming-breakage-starting-in-rust-1-7-from-rfcs-1214-and-136/4207
    • 0
      Ну ломает она очень небольшое количество пакетов, в 99% случаев никто это не почувствует.
      Да и изменения там в принципе только исправляют некорректное поведение языка: раст позволял делать вещи, которые не должен был позволять делать в принципе.
    • +7
      Выпускать новые на 100% обратно совместимые версии языка практически невозможно. Например, простое добавление одного нового метода в стандартной библиотеке может в очень редких случаях сломать кому-то код – если он до этого объявил свой типаж с таким же методом и реализовал его для этого типа. А добавление нового приватного поля может повлиять на ABI-совместимость.

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

      Ну и в третьих, разработчики Rust тестируют как добавление обратно несовместимого изменения отразиться на всей экосистеме, буквально компилируя все публичные пакеты новой версией языка и прогоняя для них тесты. Насколько я знаю, это беспренцендентное решение. Иногда бывало такое, что Steve Klabnic (один из core разработчиков Rust) сам заранее рассылал PR тем проектам, у которых может сломаться код в следующих версиях Rust.
      • 0
        А добавление нового приватного поля может повлиять на ABI-совместимость.
        ABI совместимости сейчас вроде вообще никакой нет.
      • 0
        Конечно, я этим согласен. Я это указал, не чтоб как то поругать раст, а для общей информации, там довольно детальное изложение с формулами есть, возможно кому-то интересно будет почитать.
        • 0
          Без проблем, просто из вашего комментария можно сделать вывод, что у Rust серьезные проблемы с обратной совместимостью, хотя на самом деле это не так. Мало кто так сильно заботиться об обратной совместимости, как это делает сегодня команда Rust. Именно по-этому любая мелкая обратная несовместимость явно декларируется и обсуждается.
  • +7
    Ну зачем Rust такая гадость, как исключения? Требую их исключить!
    • +3
      Формально это не исключения, а просто дополнительный сахар для паттерн матчинга на Result с ранним возвратом. Дальнейшее развитие макроса try! по сути. Хотя лучше бы они, ИМХО, работали над HKT и монадическими комбинаторами.
      • +3
        Нужда в сборке мусора мне тоже непонятна. Зачем заслонять киллер-фичу borrow-checker'а попсовым GC? Ну не конкурировать Rust'у с Go/Java/C#/Python, зачем лезть не в свою нишу?
        • +1
          Это нужно для взаимодействия с языками, у которых есть GC. Например для Servo, для взаимодействия с JS движком.
        • +4
          Опять же не путайте GC как неотъемлемую часть рантайма языка, и как опциональную библиотеку. Никто в сам раст GC впиливать не собирается. Будет отдельная либа для сборки мусора, как в Си++. Сейчас проблема в том, что нет красивого стабильного синтаксиса указать, какой конкретно аллокатор использовать при размещении данных в куче, есть по факту только Box, который всегда юзает дефолтный аллокатор (jemalloc). В язык просто добавят синтаксис, позволяющий размещать переменные не только напрямую через malloc на куче, но и под контролем GC, который можно выбрать любой, не выбирать вообще, или выбрать несколько разных и использовать вместе по потребностям.
          • +2
            Это вы про разные аллокаторы говорите, а с GC отдельная тема и там всё довольно сложно (1, 2). Хотят сделать довольно тесную интеграцию Раста с GC.
            • +2
              Всё равно не вижу большой проблемы. Ну появится тип Gc<T>, наравне с Rc<T>, Arc<T> и Box<T>, ну и что? Семантика работы с ним будет аналогичная, использование — только явное, то есть не будет так, что ты делаешь let x = 123; и оно внезапно подхватывается актичным сборщиком мусора, который будет следить за x.
              • +1
                Так я тоже не вижу большой проблемы, я просто к тому, что это не «просто добавят синтаксис», а довольно хитроумная штука, которую ещё непонятно как сделать.
                • +2
                  Понятно, что внутре будет не просто одна только неонка, а сложная алгоритмически-ёмкая реализация, но для пользователя языка это просто новый синтаксис.

                  Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
          • +2
            Мне, просто, кажется, что GC — это фундаментальная вещь, влияющая на стиль кодирования. Если такая библиотека взлетит, то это деформирует семантику языка (я не про его ядро, а про способ мышления им), изменит направленность community, а также отвратит низкоуровневых разработчиков (поскольку будет написана туча GC-based кода, который и станет стандартом de-facto). Впрочем, я могу ошибаться, поглядим, что из этого получится.
            • +1
              Во-первых, для С тоже есть кучу библиотек, реализующих GC, и ничего, вроде бы никто еще не забыл, что на C можно писать без сборщика мусора.

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

              Особенность Rust в данном случае в том, что для него создать полноценный и опциональный GC гораздо сложнее, ведь Rust дает гораздо больше гарантий, чем C, а это значит, что компилятор и GC должны каким-то образом договариваться и проверять, что эти гарантии выполняются. Сложности начинаются там, где соприкасается код с GC и код, который управляеться borrow cheker'ом.
            • 0
              Если стандартная библиотека и заметное количество сторонних библиотек не будут использовать сборку мусора, то ни кого дополнительная возможность не отпугнет. Но может привлечь большое количество программистов, которым жесткие гарантии (по времени и памяти) требуются редко, а производительность и, особенно, надежность важны.
          • 0
            А в C++ есть сборка мусора? О_о
            • +2
              • 0
                А неконсервативные сборщики среди них есть? Я не встречал.
                • 0
                  Нет, точных не видел.
          • 0
            Для нормального (не консервативного) Gc от компилятора нужна метаинформация о типах — что бы знать, где указатели на управляемые Gc объекты, а где данные и прочие указатели. Иначе сборка мусора будет тормозить и может не все собрать.
        • +2
          Что бы проще было писать интерпретаторы языков с Gc.
          Кроме того Gc во многих важных случаях эффективнее Rc. Если пытаться все сводить к borrow-checker, то Rc тоже надо бы выкинуть.
  • +1
    github.com/glaebhoerl/rfcs/blob/trait-based-exception-handling/active/0000-trait-based-exception-handling.md — отстой!
    Нужна do-нотация просто и монады.
    • +2
      Самое смешное, что как раз do-нотация есть в виде макроса. Проблема в том, что она недостаточно общая, нельзя её написать для всех монад сразу без HKT, нужно реализовать отдельно для каждого монадического типа. А HKT вводить не торопятся.

      На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.
      • –1
        Это полный отстой: сейчас зафиксируют стремный синтаксис, а потом назад фиг вернешься: совместимость же. По мне так к черту, я не парюсь по поводу написания пары лишних строк для обработки ошибок: после Go вообще эта проблема не напрягает, а вот увидеть нормальный фикс в удаленном будущем без уродского C#-синтаксиса, который, конечно же, придется поддерживать, я хочу.
        • +2
          Ну так этот RFC ещё и не приняли. Всё может поменяться. Я на это надеюсь.
        • 0
          Мне вот подумалось, что из try вполне может вырасти do-нотация, как в скале случилось с for.
      • +1
        Я рекомендую перечитать обсуждение этого RFC, там все это горячо и глубоко обсуждается со всех возможных ракурсов. Меня тоже по-началу коробило от такого решения, но сейчас есть ощущение, что все-таки это наилучший вариант, хоть он и ломает немного систему координат тем, кто достаточно долго пишет на Rust.
  • +3
    использование Cargo для сборки rustc?

    try!(использованиеCargoДляСборкиRustc())
  • +8
    Бессовестный самопиар: я опубликовал на Udemy курс по Rust.
  • 0
    Надеюсь, хоть IndexAssign (https://github.com/rust-lang/rust/pull/25628) скоро одобрят, а то с хештаблицами сейчас работать не слишком удобно.
    • +1
      Ну судя по тому, что в доках стабильного раста появились всякие AddAssign, оно уже там, дело за малым. Думаю, скоро стабилизируют.
      • 0
        Это не для индексов же. Я хочу возможность нормально писать `&mut map[key]` (по аналогии со сто лет как работающим `&map[key]`), а не `map.get_mut(key).expect(«TODO: добавить обработку ошибок по вкусу»)`. :(
        • 0
          Для этого ведь достаточно реализации IndexMut. Для меня загадка, почему он не реализован для мапов.
          • +1
            Реализацию IndexMut специально убрали когда-то, как раз в ожидании IndexAssign:

            https://github.com/rust-lang/rust/pull/23559

            This commit removes the IndexMut impls on HashMap and BTreeMap, in order to future-proof the API against the eventual inclusion of an IndexSet trait.

            Ideally, we would eventually be able to support:

            map[owned_key] = val;
            map[borrowed_key].mutating_method(arguments);
            &mut map[borrowed_key];
            


            but to keep the design space as unconstrained as possible, we do not currently want to support IndexMut, in case some other strategy will eventually be needed.

            Code currently using mutating index notation can use get_mut instead.
    • 0
      Вроде бы этот RFC недавно был на стадии final comment period, так что наверняка добавят, не думаю что там что-то сложное.
    • 0
      Нихрена себе! Так какой-то Lua получается. Непривычно для меня, но выглядит классно!
      • 0
        Не, ну до метатаблиц тут очень далеко. Просто щепотка удобства.
  • –2
    Меньше чем за год «стабильности» они сломали 4% пакетов? Отличная стабильность, что тут скажешь
    • +1
      Речь идет о работоспособности кода, написанного конкретно под Rust 1.0, но скпомпилированного с помощью Rust 1.5, а не о поломке пакетов. Конечно, абсолютное большинство из этих 4% пакетов были обновлены и исправлены для работоспособности на старших версиях. И да, это отличный результат.
      • –3
        Отличный результат, говорите? 100% кода, написанного под Java 1.0 в 1996 году, компилируется с помощью Java 8.
        • +3
          Вы чушь говорите. Что, с 1996 года в java не зарезирвировали ни одного нового ключевого слова, которое в старых библиотеках могло использоваться как имя переменной? Или ни в один класс из стандартной библиотеки не добавили ни одного нового метода, которой мог быть объявлен в старых библиотеках в наследуемом классе без override? Или не добавили ни одного нового класа, который конфликтовал бы по имени с пользовательским класом при wild card import?
          • +2
            У меня вылезали проблемы совместимости oracle jdk7 vs oracle jdk8, чё уж там.

            Простой пример — jboss as 7 не запускался на jdk8, но запускался на jdk7.

            Другой пример — sbt, ant и maven (при использовании определенных плагинов) могут вести себя по разному на разных версиях jdk. Например, sbt 0.11 (если правильно помню) не работал при запуске на 8 jre. Плагины под ant и maven, использовавшие rhino в качестве ScriptingEngine падали под 8, т. к. у nashorn другая api (со стороны js).
            • 0
              Мы говорим про совместимость компиляции, а не рантайма.
              • 0
                Тогда ок, я-то предполагал, что под работоспособностью выше имелась ввиду работоспособность полученного после компиляции, а не возможность просто скомпилировать.

                Тогда в качестве примера скорее подойдёт scala, где использование новых нестабильных фич языка или хитрых приёмов с типами приводит к невозможности сборки новой версией компилятора.

                Поглядев на libstd я отметил, что там пока ещё довольно много кода, отмеченного, как нестабильный, не говоря уже про libcore (который интересен в embedded). И те библиотеки, которые зависят от него вполне могут страдать. Язык-то активно развивается. С виду даже быстрее, чем скала между 2.9 и 2.10.
          • 0
            Ок, формально не 100% совместимость…

            С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.

            Добавление метода без @Override (который сам по себе был добавлен в Java 6) разрешено (это только предупреждение, а не ошибка компиляции, опять же, до Java 6 даже предупреждения не было).

            Добавление методов таки может сломать совместимость, если появляется неоднозначность, например, был метод foo(Interface1), добавлен foo(Interface2), а где-то в коде вызывается foo(obj), где obj наследует и Interface1, и Interface2.

            Но вероятности этого опять же очень-очень малы. Всяко меньше 4% пакетов за год
            • +4
              Может вы и говорите о совместимости компиляции, но Brian Anderson в своем посте говорил о совместимости всей инфраструктуры, включая компилятор, менеджер пакетов, стандартную библиотеку, и компилируемость всех зависимостей тестируемой библиотеки.

              С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.
              Но достаточная причина для того, чтобы сломать компиляцию, встретившись хотя бы один раз в исходном коде библиотеки или любой ее зависимости.

              Добавление метода без Override (который сам по себе был добавлен в Java 6) разрешено (это только предупреждение, а не ошибка компиляции, опять же, до Java 6 даже предупреждения не было).
              Ок, я забыл что override в Java это не ключевое слово. Тем не менее, просто подумайте, как переопределение метода «в слепую» может повлиять на работу кода, который использует этот метод, в том числе на код из стандартной библиотеки.

              Всех этих причин достаточно, чтобы ломать совместимость серьезных библиотек. Я буду очень удивлен, если хотя бы половина полноценных библиотек, а не программ на 100 строк, неизменявшихся с Java 1.0 будет успешно скомпилирована и корректно работать в инфраструктуре Java 8. Я не удивлюсь, если тест провалят 90% библиотек.

              Может быть 4% меньше чем за год – это действительно много, учитывая, скажем так, размеренность жизни в мире Java. Я рекумендую вам измерять такие вещи не временными промежутками, а количеством изменений, произошедших за это время. А то может получиться, что самым стабильным языком у нас будет COBOL.
            • +2
              В конце концов, можете просто пролистать вот этот список.

              Я не думаю, что разработчики только одной Java-библиотеки из 20 сделали хотя бы одно изменение только для того, что бы библиотека начала работать в новой версии Java.
        • +1
          Попадался унаследованный код под java 1.5, который не собирался под 1.6 и 1.7 из-за пропвыших пакетов из sun.*.

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