2015 год был значительным годом для Rust: мы выпустили версию 1.0, стабилизировали большинство элементов языка и кучу библиотек, значительно выросли как сообщество, а также реорганизовали управление проектом. Может показаться что 2016 год не будет таким же интересным (будет трудно превзойти выпуск 1.0), но это будет супер-важный год для Rust, в котором произойдет много захватывающих вещей. В этой статье я расскажу о том, что, как я думаю, должно произойти. Это не официальная позиция и не обещание разработчиков Rust.2015
Прежде чем мы поговорим о будущем, вот несколько цифр за прошлый год:
В 2015 году силами сообщества Rust:
- Создано 331 предложение по улучшению языка (RFC)
- из которых 161 было принято и влито в основной репозиторий
- всего 120 человек подало RFC, из них 6 человек создало 10 и более, Alex Crichton создал 23 RFC
- Создано 559 задач по улучшению RFC
- Прислано и влито в репозиторий Rust 4630 Pull-запросов
- авторами которых является 831 человек, из них 91 создали больше 10 запросов, 446 человек создали только один, а Steve Klabnik был автором 551 pull-запроса
- Создано 4710 задач
- из которых 1611 еще открыты
- авторами которых является 1319 человек, из которых 79 создали больше 10, а Alex Crichton открыл всего 159 задач
- Выпущено шесть стабильных релизов Rust (1.0 – 1.5)
- Поддерживается стабильность Rust – 96% пакетов, которые компилировались на 1.0, по прежнему компилируются с использованием версии 1.5
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 год будет прекрасным годом для всего сообщества. С новым годом!
Комментарии (59)
VioletGiraffe
10.01.2016 15:54+1Недавно была хорошая статья о том, для кого и зачем сделан язык Go. ИМХО не помешала бы такая же о Rust.
VioletGiraffe
11.01.2016 10:06+6За что минусы-то, да ещё и в карму?.. Я ж ничего обидного про Rust не сказал!
kstep
11.01.2016 12:31+3Я бы плюсанул в карму, но плюсовать можно только тех, у которых есть публикации. В итоге только минусовать можно, а те, кто хочет поставить плюс, тупо не могут это сделать. Напиши какую-нибудь статью, будет проще плюсы получать =)
VioletGiraffe
11.01.2016 12:45+1Знаю, что плюсовать не могут, но минусовать-то зачем? Хоть бы объясняли, за что!
Написать что-нибудь хочу с тех пор, как зарегистрировался года 2 назад, но не о чем мне писать — ничего такого уникального не делал, о чём бы уже не было написано :(
nwalker
11.01.2016 23:23Раст сделан для тех, кто пишет на С и С++ и хочет делать это лучше ценой дополнительной нагрузки на программиста.
В принципе, все.
billyevans
10.01.2016 16:01Я так понимаю уже будет ломающая некоторые пакеты 1.7 версия users.rust-lang.org/t/upcoming-breakage-starting-in-rust-1-7-from-rfcs-1214-and-136/4207
kstep
10.01.2016 16:20Ну ломает она очень небольшое количество пакетов, в 99% случаев никто это не почувствует.
Да и изменения там в принципе только исправляют некорректное поведение языка: раст позволял делать вещи, которые не должен был позволять делать в принципе.
defuz
10.01.2016 21:35+7Выпускать новые на 100% обратно совместимые версии языка практически невозможно. Например, простое добавление одного нового метода в стандартной библиотеке может в очень редких случаях сломать кому-то код – если он до этого объявил свой типаж с таким же методом и реализовал его для этого типа. А добавление нового приватного поля может повлиять на ABI-совместимость.
Разработка Rust мне нравиться тем, что во-первых они постулируют принципы, по которым можно определить, какие изменения приемлемы для минорного релиза, а какие нет. Во-вторых, в случае с минорными обратно-несовместимыми изменениями компилятор за 2 релиза начинает выдавать предупреждение для кода, который сможет сломаться в будущем, с объяснением проблемы и рекомендацией, как ее можно избежать.
Ну и в третьих, разработчики Rust тестируют как добавление обратно несовместимого изменения отразиться на всей экосистеме, буквально компилируя все публичные пакеты новой версией языка и прогоняя для них тесты. Насколько я знаю, это беспренцендентное решение. Иногда бывало такое, что Steve Klabnic (один из core разработчиков Rust) сам заранее рассылал PR тем проектам, у которых может сломаться код в следующих версиях Rust.stepik777
10.01.2016 21:41А добавление нового приватного поля может повлиять на ABI-совместимость.
ABI совместимости сейчас вроде вообще никакой нет.
billyevans
10.01.2016 22:13Конечно, я этим согласен. Я это указал, не чтоб как то поругать раст, а для общей информации, там довольно детальное изложение с формулами есть, возможно кому-то интересно будет почитать.
defuz
10.01.2016 22:20Без проблем, просто из вашего комментария можно сделать вывод, что у Rust серьезные проблемы с обратной совместимостью, хотя на самом деле это не так. Мало кто так сильно заботиться об обратной совместимости, как это делает сегодня команда Rust. Именно по-этому любая мелкая обратная несовместимость явно декларируется и обсуждается.
ababo
10.01.2016 16:47+7Ну зачем Rust такая гадость, как исключения? Требую их исключить!
kstep
10.01.2016 16:49+3Формально это не исключения, а просто дополнительный сахар для паттерн матчинга на Result с ранним возвратом. Дальнейшее развитие макроса try! по сути. Хотя лучше бы они, ИМХО, работали над HKT и монадическими комбинаторами.
ababo
10.01.2016 16:53+3Нужда в сборке мусора мне тоже непонятна. Зачем заслонять киллер-фичу borrow-checker'а попсовым GC? Ну не конкурировать Rust'у с Go/Java/C#/Python, зачем лезть не в свою нишу?
stepik777
10.01.2016 16:57+1Это нужно для взаимодействия с языками, у которых есть GC. Например для Servo, для взаимодействия с JS движком.
kstep
10.01.2016 17:00+4Опять же не путайте GC как неотъемлемую часть рантайма языка, и как опциональную библиотеку. Никто в сам раст GC впиливать не собирается. Будет отдельная либа для сборки мусора, как в Си++. Сейчас проблема в том, что нет красивого стабильного синтаксиса указать, какой конкретно аллокатор использовать при размещении данных в куче, есть по факту только Box, который всегда юзает дефолтный аллокатор (jemalloc). В язык просто добавят синтаксис, позволяющий размещать переменные не только напрямую через malloc на куче, но и под контролем GC, который можно выбрать любой, не выбирать вообще, или выбрать несколько разных и использовать вместе по потребностям.
stepik777
10.01.2016 17:07+2Это вы про разные аллокаторы говорите, а с GC отдельная тема и там всё довольно сложно (1, 2). Хотят сделать довольно тесную интеграцию Раста с GC.
kstep
10.01.2016 17:15+2Всё равно не вижу большой проблемы. Ну появится тип Gc<T>, наравне с Rc<T>, Arc<T> и Box<T>, ну и что? Семантика работы с ним будет аналогичная, использование — только явное, то есть не будет так, что ты делаешь
let x = 123;и оно внезапно подхватывается актичным сборщиком мусора, который будет следить за x.stepik777
10.01.2016 17:18+1Так я тоже не вижу большой проблемы, я просто к тому, что это не «просто добавят синтаксис», а довольно хитроумная штука, которую ещё непонятно как сделать.
kstep
10.01.2016 17:34+2Понятно, что внутре будет не просто одна только неонка, а сложная алгоритмически-ёмкая реализация, но для пользователя языка это просто новый синтаксис.
Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
ababo
10.01.2016 17:07+2Мне, просто, кажется, что GC — это фундаментальная вещь, влияющая на стиль кодирования. Если такая библиотека взлетит, то это деформирует семантику языка (я не про его ядро, а про способ мышления им), изменит направленность community, а также отвратит низкоуровневых разработчиков (поскольку будет написана туча GC-based кода, который и станет стандартом de-facto). Впрочем, я могу ошибаться, поглядим, что из этого получится.
defuz
10.01.2016 21:42+1Во-первых, для С тоже есть кучу библиотек, реализующих GC, и ничего, вроде бы никто еще не забыл, что на C можно писать без сборщика мусора.
Во-вторых, если кому-то хочеться писать свои проекты с использованием GC, но при этом пользоваться теми приемущиствами, которые дают библиотеки Rust, то почему бы и нет? Главное, чтобы такое нововведение не помешало системному программированию, но я не думаю, что с этим будут хоть какие-то проблемы.
Особенность Rust в данном случае в том, что для него создать полноценный и опциональный GC гораздо сложнее, ведь Rust дает гораздо больше гарантий, чем C, а это значит, что компилятор и GC должны каким-то образом договариваться и проверять, что эти гарантии выполняются. Сложности начинаются там, где соприкасается код с GC и код, который управляеться borrow cheker'ом.
potan
12.01.2016 16:22Если стандартная библиотека и заметное количество сторонних библиотек не будут использовать сборку мусора, то ни кого дополнительная возможность не отпугнет. Но может привлечь большое количество программистов, которым жесткие гарантии (по времени и памяти) требуются редко, а производительность и, особенно, надежность важны.
potan
12.01.2016 16:16Для нормального (не консервативного) Gc от компилятора нужна метаинформация о типах — что бы знать, где указатели на управляемые Gc объекты, а где данные и прочие указатели. Иначе сборка мусора будет тормозить и может не все собрать.
potan
12.01.2016 16:12+2Что бы проще было писать интерпретаторы языков с Gc.
Кроме того Gc во многих важных случаях эффективнее Rc. Если пытаться все сводить к borrow-checker, то Rc тоже надо бы выкинуть.
Monnoroch
10.01.2016 17:49+1github.com/glaebhoerl/rfcs/blob/trait-based-exception-handling/active/0000-trait-based-exception-handling.md — отстой!
Нужна do-нотация просто и монады.kstep
10.01.2016 17:53+2Самое смешное, что как раз do-нотация есть в виде макроса. Проблема в том, что она недостаточно общая, нельзя её написать для всех монад сразу без HKT, нужно реализовать отдельно для каждого монадического типа. А HKT вводить не торопятся.
На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.Monnoroch
10.01.2016 17:59-1Это полный отстой: сейчас зафиксируют стремный синтаксис, а потом назад фиг вернешься: совместимость же. По мне так к черту, я не парюсь по поводу написания пары лишних строк для обработки ошибок: после Go вообще эта проблема не напрягает, а вот увидеть нормальный фикс в удаленном будущем без уродского C#-синтаксиса, который, конечно же, придется поддерживать, я хочу.
kstep
11.01.2016 12:33Мне вот подумалось, что из
tryвполне может вырасти do-нотация, как в скале случилось сfor.
defuz
10.01.2016 22:00+1Я рекомендую перечитать обсуждение этого RFC, там все это горячо и глубоко обсуждается со всех возможных ракурсов. Меня тоже по-началу коробило от такого решения, но сейчас есть ощущение, что все-таки это наилучший вариант, хоть он и ломает немного систему координат тем, кто достаточно долго пишет на Rust.
greabock
10.01.2016 21:18+3использование Cargo для сборки rustc?
try!(использованиеCargoДляСборкиRustc())
ozkriff
11.01.2016 12:44Надеюсь, хоть IndexAssign (https://github.com/rust-lang/rust/pull/25628) скоро одобрят, а то с хештаблицами сейчас работать не слишком удобно.
kstep
11.01.2016 12:55+1Ну судя по тому, что в доках стабильного раста появились всякие AddAssign, оно уже там, дело за малым. Думаю, скоро стабилизируют.
ozkriff
11.01.2016 13:09Это не для индексов же. Я хочу возможность нормально писать `&mut map[key]` (по аналогии со сто лет как работающим `&map[key]`), а не `map.get_mut(key).expect(«TODO: добавить обработку ошибок по вкусу»)`. :(
kstep
11.01.2016 15:55Для этого ведь достаточно реализации IndexMut. Для меня загадка, почему он не реализован для мапов.
ozkriff
11.01.2016 16:00+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.
defuz
11.01.2016 13:07Вроде бы этот RFC недавно был на стадии final comment period, так что наверняка добавят, не думаю что там что-то сложное.
leventov
12.01.2016 11:02-2Меньше чем за год «стабильности» они сломали 4% пакетов? Отличная стабильность, что тут скажешь
defuz
12.01.2016 13:43+1Речь идет о работоспособности кода, написанного конкретно под Rust 1.0, но скпомпилированного с помощью Rust 1.5, а не о поломке пакетов. Конечно, абсолютное большинство из этих 4% пакетов были обновлены и исправлены для работоспособности на старших версиях. И да, это отличный результат.
leventov
12.01.2016 13:46-3Отличный результат, говорите? 100% кода, написанного под Java 1.0 в 1996 году, компилируется с помощью Java 8.
defuz
12.01.2016 13:55+3Вы чушь говорите. Что, с 1996 года в java не зарезирвировали ни одного нового ключевого слова, которое в старых библиотеках могло использоваться как имя переменной? Или ни в один класс из стандартной библиотеки не добавили ни одного нового метода, которой мог быть объявлен в старых библиотеках в наследуемом классе без override? Или не добавили ни одного нового класа, который конфликтовал бы по имени с пользовательским класом при wild card import?
grossws
12.01.2016 14:04+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).leventov
12.01.2016 14:15Мы говорим про совместимость компиляции, а не рантайма.
grossws
12.01.2016 14:39Тогда ок, я-то предполагал, что под работоспособностью выше имелась ввиду работоспособность полученного после компиляции, а не возможность просто скомпилировать.
Тогда в качестве примера скорее подойдёт scala, где использование новых нестабильных фич языка или хитрых приёмов с типами приводит к невозможности сборки новой версией компилятора.
Поглядев на libstd я отметил, что там пока ещё довольно много кода, отмеченного, как нестабильный, не говоря уже про libcore (который интересен в embedded). И те библиотеки, которые зависят от него вполне могут страдать. Язык-то активно развивается. С виду даже быстрее, чем скала между 2.9 и 2.10.
leventov
12.01.2016 14:14Ок, формально не 100% совместимость…
С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.
Добавление метода без@Override(который сам по себе был добавлен в Java 6) разрешено (это только предупреждение, а не ошибка компиляции, опять же, до Java 6 даже предупреждения не было).
Добавление методов таки может сломать совместимость, если появляется неоднозначность, например, был метод foo(Interface1), добавлен foo(Interface2), а где-то в коде вызывается foo(obj), где obj наследует и Interface1, и Interface2.
Но вероятности этого опять же очень-очень малы. Всяко меньше 4% пакетов за годdefuz
12.01.2016 14:40+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.
defuz
12.01.2016 14:49+2В конце концов, можете просто пролистать вот этот список.
Я не думаю, что разработчики только одной Java-библиотеки из 20 сделали хотя бы одно изменение только для того, что бы библиотека начала работать в новой версии Java.
potan
13.01.2016 19:45+1Попадался унаследованный код под java 1.5, который не собирался под 1.6 и 1.7 из-за пропвыших пакетов из sun.*.
SerCe
Как одно из событий 2015, можно также упомянуть активное развитие крутейшей IDE для rust.