Rust: «Назад к корням»

https://www.reddit.com/r/rust/comments/7p6n90/rust2018_back_to_the_roots/
  • Перевод

Мне приходит в голову множество разных целей для Rust в текущем 2018 году, к слову, 2017 год прошел для меня очень быстро, так что я задался следующим вопросом: если бы я мог выбрать одну-единственную цель для Rust в 2018 году, то что бы я выбрал?


Я буду пристрастен, и вот мое мнение:


2018 должен стать последним годом, когда приходится начинать писать новый проект на C или C++


Я системный программист (HPC) и сейчас, если мне придется выбрать для работы язык программирования, то я могу выбирать лишь между C и C++. Rust недостаточно хорош для меня, пусть я и использую его каждый день для всех мелких проектов и прототипов.


Почему именно эта цель, а не какая-либо другая? Действительно, Rust хорошо подходит для многих задач, которые лежат вне плоскости системного программирования. Однако это очень широкая область, где уже и так имеется довольно большое количество других ЯП, и так как
они заточены под разные задачи — некоторые, например, используют GC — то для некоторых специфических задач они будут подходить лучше чем Rust.


С другой стороны, область системных ЯП достаточно узка и в ней имеются только два закрепившихся родственных языка: C и C++. Сообщества, которые они образуют, огромны (миллионы разработчиков), и эти программисты хотят, чтобы на Rust'е можно было
успешно решать те же задачи, которые они решают, используя два вышеупомянутых ЯП.


Это здорово, что язык позволяет безопасно работать с памятью без GC, но для C и C++ разработчиков использование Rust до сих вынуждает идти на некоторые компромиссы. Так что 2018 год должен быть годом безопасной работы с памятью без компромиссов: чтобы в 2019 году никто из тех, кто профессионально занимается написанием unsafe кода не мог утверждать: "Я не могу использовать Rust из-за X" и в то же время быть правым. У нас уже имеется безопасный язык, в этом году мы должны провести такую работу, чтобы те, кому нужна такая безопасность, не имели оправдания не использовать Rust. Написание нового низкоуровневого проекта в 2019 году на С или C++ должно заставлять людей удивленно поднимать брови и никак иначе.


Для того чтобы достичь этой цели, мы должны выяснить какие области системного программирования (обработка финансовых транзакций, вычисления на суперкомпьютерах, написание драйверов устройств, программирование ядер ОС, программирование для встраиваемых систем, разработка игр, системы автоматизированного проектирования (CAD),
браузеры, компиляторы, и т. д.) имеют проблемы, оценить их и устранить, чтобы сделать Rust
наиболее подходящим языком для этих областей.


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


P.S: Я не хочу делать главным фокусом этой заметки какие-либо определенные возможности
языка. Есть много возможностей языка, работа над которыми уже идет, но которые до сих пор находятся в незавершенном состоянии или нестабильны.


Относящиеся к языку:


  • модель памяти (C/C++)
  • использование ассемблерных вставок в коде
  • константные generic'и
  • макросы 2.0
  • поддержка асинхронного программирования (async/await)
  • alloca (С)
  • массивы с размером задаваемым во время выполнения (VLA)(С)

Относящиеся к библиотекам:


  • потоковые итераторы (С++)
  • использование SIMD инструкций (С/C++)
  • встроенные функции компилятора (intrinsics)
  • аллокаторы памяти (C++)
  • обработка положений нехватки памяти (OOM) (С++)

Инструментарий:


  • выявление неопределенного поведения (UB): 100% выявление UB во время выполнения
  • определение покрытия кода тестами в cargo

IDE (C/C++):


  • интеграция с Cargo
  • автодополнение
  • переход к определению
  • переименовывание
  • рефакторинг
  • форматирование кода — все это должно просто работать.

Сargo:


  • использование сквозь ssh-туннели
  • внутренние зеркала
  • объединение xargo/cross в единый cargo

Платформы:


  • поддержка компиляции в С код
  • использование GCC в качестве backend'а
  • поддержка CUDA
  • улучшение совместимости Rust с C++ кодом: шаблоны, концепты и модули

Замечу, что каждой их этих проблем было уделено много часов работы в Rust-сообществе.
Я не упомянул ABI-совместимость, так как этому было уделено сравнительно мало внимания.


В частности, работа над моделью памяти и неопределенным поведением — это то, что может выгодно отличить Rust от C и C++, которые также имеют свои модели памяти, но не имеют способа выявлять неопределенное поведение (UB). Можно даже сказать, что отсутствие модели памяти делает язык гораздо менее безопасным и предсказуемым чем C и C++, на мой взгляд.


Большое спасибо всем из сообщества Rustycrate, кто участвовал в переводе, вычитке и редактировании данной статьи. А именно: mkpankov, ozkriff, Revertron.

Чего, на ваш взгляд, больше всего не хватает в Rust?

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

Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 42
  • +10
    Чего, на ваш взгляд, больше всего не хватает в Rust?

    HKT, специализация, impl trait.

    • +2
      И хорошо-бы встроенный do notation
      • 0

        После стабилизации оператора ? это уже можно не ждать, кмк.

      • 0
        DarkEld3r, а что значит НКТ? Спасибо.
      • 0
        Я правильно понимаю, что HKT polymorphism — это то же самое, что multimethods в C++? Почему что в C++ что в Rust их до сих пор не реализовали? Высокая сложность реализации или никому не нужно? Мне кажется, что польза от этого была бы громадная — не нужно будет этих костылей в виде visitor pattern.
        • +2

          Нет, это т.н. "конструкторы типов". Грубый аналог из С++


          template<template<class> HKT>

          Один из примеров использования — те самые монады. Есть более конкретные примеры, но сходу не вспомню.

          • +2

            Хороший, на мой взгляд, пример потенциального использования типов высшего порядка можно показать на таком примере:


            trait Container<T> { 
                // some methods
            }
            
            fn map<T, C: Container<T>>(c: C<T>) -> C<T> {
                // some code
            }

            Мы хотим на уровне сигнатуры функции выразить то, что функция map не только возвращает контейнер элементов того же типа, что аргумент, но и конкретная реализация контейнера у аргумента и возвращаемого значения тоже совпадает.

      • 0
        Ошибки перевода:
        В 2018 году никто не должен начинать писать новый проект на C или C++.

        что противоречит дальнейшей фразе:
        Rust недостаточно хорош для меня...


        В оригинале:
        2018 should be the last year somebody should ever need to start a new project in C or C++.

        Я бы перевел скорее как:
        «2018 должен стать последним годом, когда приходится начинать писать новый проект на C или C++»
        • 0
          Да весь перевод просто ужасен. Всякие «мы должен провести» и «мы должен выяснить»…
        • 0
          Поправил, спасибо.
          • +3
            использование GCC в качестве backend'а

            Вот серьозно, зачем это нужно если есть LLVM.
            поддержка асинхронного программирования (async/await)

            Как по мне в rust лучше предоставить семейство типов для работы с асинхронностью. async/await лучше оставить более высокоуровневым языкам. Например в с# это модель очень удобна, но достигается путем нескольких абстракции.
            • 0
              Вот серьозно, зачем это нужно если есть LLVM.

              LLVM поддерживает намного меньше целевых платформ, разве нет?

              • +5
                Да, так оно. А разве некоторые платформы не устарели? По моему поддержка GCC не настолько важна на данный момент. Лучше направить сил на что нибудь другое.
              • +1
                С другой стороны, именно в таких языках как C++ или Rust сопрограммы могут быть реализованы наиболее красивым образом: без всяких конечных автоматов, с сохранением во внутреннем состоянии задачи непосредственно регистра IP…
              • +3
                Увы, но между первыми реальными успехами языка и замещением С/С++ пройдут годы. В НРС инфляция знаний очень низкая, текущие спецы со знанием С/С++ в массе нескоро перейдут на другие языки — хотя бы потому, что потратили много времени на приобретение нынешнего уровня знаний.

                Те же, кто входит в индустрию, как правило, тратят время на изучение матчасти, т. к. для НРС гораздо важнее знать алгоритмы, структуры данных и архитектуру целевых платформ, поскольку прослойка между ПО и железом тонкая. Нет какой-то большой разницы, откуда дёргать НРС либы — из С или Rust.

                P. S.
                Лично я к Rust отношусь хорошо.
                • +2
                  Добавлю из своего прошивочного погреба: для проталкивания Rust в эту нишу нужно очень сильное давление со стороны производителей CPU, потому что именно они пишут львиную долю кода прошивок и пока они не захотят сменить C на более безопасный язык — ничего с места не сдвинется.
                  В Google товарищи, которые занимались coreboot, решили написать свою собственную реализацию фазы DXE (проект u-root) на Go, и у них оно может выстрелить, т.к. ресурсов достаточно, но пока индустрия вся это не поддержит — ничего не изменится, и пока даже намеков нет на какой-то прогресс в этой области.
                  Понятно, что любой путь начинается с первого шага, но пока даже на этот шаг (в случае с Rust таким шагом будет добавление драйверов на нем в сборочную систему EDK2, чтобы можно было начать их собирать там же, где собирается все остальное) времени ни у кого нет.
                  • +1
                    Большой +1. Если пользуешься процами фирмы X, то компиляторы, библиотеки и брендированный эклипс тоже от фирмы Х. Обычно даже с оффициальными тулами полно проблем, не говоря уже про сторонние.
                  • 0

                    Вот сколько раз не смотрел в сторону Rust — не хватает в нем одной немаловажной фичи — взаимодействие с существующими библиотеками на С++ (в силу множества причин)

                    • +2

                      Я так понимаю что план состоит в создании внешних генераторов, которые, насколько это возможно с учетом различных подходов языков к куче всего, будут сами делать привязки. До какой-то, пока не очень большой, степени сишный rust-lang-nursery/rust-bindgen уже умеет работать с C++, но еще есть довольно перспективный rust-qt/cpp_to_rust.

                      • +2

                        Еще есть мой проект https://github.com/Dushistov/rust_swig для генерации c++ обертки для rust кода. Он как бы в обратную сторону от bindgen, для вызова rust кода из c/c++,
                        а не для вызова c/c++ из rust что сделано в bindgen. Права в отличии от jni/java backend, c++ backend только в начале развития.

                      • 0
                        shybovycha, я где-то читал, что можно можно использовать С код как прослойку.
                        Он одинаково хорошо взаимодействует как с Rust, так и с С++.
                        • +11

                          Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):


                          1. В стандарте так и не зафиксировано, как должны выглядеть символы для классов, методов, инстанцированных шаблонов, мэнглинг может различаться в зависимости от компилятора, языка, архитектуры, чего угодно. В windows нельзя из собранного студией кода использовать dll, собранный mingw, и наоборот. Как этим должен пользоваться внешний инструмент?
                          2. Шаблоны в С++, которые хочет автор, существуют только в заголовочных файлах. Долгая затея с экспортируемыми шаблонами, введённая в 98-м стандарте, провалилась, поддержать их за десять лет смог ровно один компилятор Comeau, и в C++11 их из стандарта выкинули. Сейчас затею пытаются повторить с модулями, но чем это всё кончится, пока непонятно. Поэтому единственный способ их поддержать — самому стать компилятором C++-кода, чтобы обрабатывать заголовочные файлы с шаблонами. Затея, изначально обречённая на провал.
                          • +2
                            На фоне этого всего работой github.com/rust-qt/cpp_to_rust я несказанно доволен. Да, наследования нету и не будет, скорее всего, но пока без него удается жить.
                            • 0
                              Да, и он работает так же, как работают абсолютно все: генерируем си-враппер, подключаем его через FFI.
                              Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
                              А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
                              • 0
                                И все же лучше, чем писать все с полного нуля?
                                • 0
                                  Местами лучше, да, с этим я и не спорю :)
                        • +2
                          Для Rust не хватает стабильно обновляющихся кроссплатформенных библиотек для построения GUI, например, на основе wxWidgets / Qt.
                          • 0
                            И не только GUI. Например для того же HPC большая часть написана или на C или на C++.
                            Для серьезного промышленного программирования мало кто захочет возиться с биндингами к C-библиотеке.
                            • +2
                              Rust QT юзабелен, с некоторыми поправками. GTK обновляется стабильно.
                              Еще есть ведро библиотек на остове нативных гуёв (для Windows/Cocoa), ну и всякие чисто растовые Conrod, Limn.
                              • 0
                                Rust Qt надо попробовать. GTK не люблю из-за того, что под Виндой интерфейс выглядит чужеродно. По той же причине не люблю растровые GUI (они выглядят чужеродно везде).
                            • 0
                              Платформы:
                              поддержка компиляции в С код
                              использование GCC в качестве backend'а

                              Противоречиво выглядит,
                              во-первых почему два пункта, если мы умеем rust->C, значит финальный
                              бинарник можно и с помощью gcc сгенерировать, в чем может быть проблема?


                              во-вторых есть https://github.com/JuliaComputing/llvm-cbe llvm C backend,
                              если в нем что-то не работает то не проще ли его доработать, чем городить
                              велосипед для генерации rust->C?

                              • +1

                                В оригинале было "или".


                                Сишный бэкенд LLVM, насколько я знаю, заброшен очень давно уже. Возможно, его и можно починить-допилить, но подозреваю что это совсем не просто — иначе зачем бы его забрасывали?

                                • 0
                                  но подозреваю что это совсем не просто — иначе зачем бы его забрасывали?

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


                                  Сишный бэкенд LLVM, насколько я знаю, заброшен очень давно уже

                                  https://github.com/JuliaComputing/llvm-cbe это отдельный от llvm проект.
                                  И куда там развиваться? LLVM IR вроде бы стабильный, если проект обрабатывает
                                  достаточно большое подмножество и делает это правильно, то развиваться дальше практически некуда.

                              • +4
                                Нужен хотя бы синтаксический сахар для композиций, если ООП не хотят впилить.
                                • +1
                                  Основные проблемы с Растом, которые, как мне кажется, не позволят так быстро ввести его в массовое использование: очень мало, и очень трудно найти обучающие материалы для тех кто начинает программировать. с/с++ можно изучать как первый язык, и в некоторых школах так и делают — с 9 класса. Есть много учебников и для взрослых «чайников», и курсов для тех кто хочет сменить профессию с не-программистской. Тогда как всё что я видел по Расту ориентировано на как минимум знакомых с программированием людей (больше половины учебников вообще сразу бросают в человека многопоточностью, тогда как многие программисты вообще работают не зная что это).
                                  Вторая проблема — нет качественной родной среды. Настройка pycharm под раст заняла у меня чересчур уж много времени. Претендовать на массовость можно если сделать установщик среды с компилятором, дебаггером и всем что положено, и разумеется — в один клик, как vs.
                                  А сам язык вроде уже норм, и я бы сказал что нужно не поддержку библиотек сделать, а скорее вообще ввести этот стиль как опциональную возможность, когда не всё вшивается в экзе, а модульно составляется — для написания ОС было бы полезно всё таки.
                                  • +3
                                    Вторая проблема — нет качественной родной среды. Настройка pycharm под раст заняла у меня чересчур уж много времени. Претендовать на массовость можно если сделать установщик среды с компилятором, дебаггером и всем что положено, и разумеется — в один клик, как vs.

                                    Самый дружелюбный IDE опыт на данный момент — https://intellij-rust.github.io — в целом все из коробки работает. Еще есть официальный https://github.com/rust-lang-nursery/rls-vscode, но RLS в ночниках иногда может фигово работать — надо уметь сказать rustup'у откатиться на прошлый ночник.

                                    • 0
                                      Я тогда устанавливал плагин сразу из шарма, там нашёлся какой-то раст. А потом компилятор не хотел подключаться. Среда его видит, проект на языке создаётся, а вместо компилятора указан интерпретатор пайтона, и потом заменять его надо с бубном. Как-то так было, насколько я помню. Сейчас, возможно, плагины допилили чуть-чуть.
                                    • +1
                                      Настройка pycharm под раст заняла у меня чересчур уж много времени.

                                      С использованием вот этого плагина, так? Какие сложности возникли? А то я использую IntelliJ Rust с CLion и вполне доволен.

                                      • 0

                                        А в чем собственно была проблема? и как давно это было?
                                        Не в создании нового проекта случайно?

                                        • 0
                                          Вторая проблема — нет качественной родной среды.

                                          По щелчку пальцев ставится и настраивается Eclipse c RustDT, но у нее два относительно серьёзных минуса:
                                          • IDE толстая, просит Java для работы, и потому не для слабых машин
                                          • Поддержка RustDT остановлена год назад. Но пока в языке не вкрутили чего-то, ломающего старые юзкейсы, это не страшно.

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