15.01.2018 03:41
bmusin 42 8200 Источник

Мне приходит в голову множество разных целей для 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++, на мой взгляд.

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


  1. DarkEld3r
    15.01.2018 10:34
    #10616356
    +2

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

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


    1. danslapman
      15.01.2018 10:56
      #10616396

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


      1. ozkriff
        15.01.2018 10:58
        #10616402

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


    1. bmusin Автор
      15.01.2018 11:23
      #10616448

      DarkEld3r, а что значит НКТ? Спасибо.


      1. danslapman
        15.01.2018 11:31
        #10616472
        +1

        Higher Kinded Types — типы высших порядков


      1. snuk182
        15.01.2018 11:32
        #10616478
        +2

        Higher-kinded types


    1. DaylightIsBurning
      15.01.2018 12:59
      #10616696

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


      1. TargetSan
        15.01.2018 21:38
        #10617664

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


        template<template<class> HKT>

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


        1. SilentRider
          16.01.2018 08:25
          #10618050
          +1

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


          trait Container<T> { 
    // some methods
}

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

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


  1. DVL333
    15.01.2018 11:19
    #10616442

    Ошибки перевода:

    В 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++»


    1. Revertis
      15.01.2018 13:29
      #10616764

      Да весь перевод просто ужасен. Всякие «мы должен провести» и «мы должен выяснить»…


  1. bmusin Автор
    15.01.2018 11:26
    #10616454

    Поправил, спасибо.


  1. unsafePtr
    15.01.2018 11:28
    #10616456

    использование GCC в качестве backend'а

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

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


    1. ozkriff
      15.01.2018 11:29
      #10616466

      Вот серьозно, зачем это нужно если есть LLVM.

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


      1. unsafePtr
        15.01.2018 12:11
        #10616598
        +1

        Да, так оно. А разве некоторые платформы не устарели? По моему поддержка GCC не настолько важна на данный момент. Лучше направить сил на что нибудь другое.


    1. mayorovp
      15.01.2018 15:01
      #10617006

      С другой стороны, именно в таких языках как C++ или Rust сопрограммы могут быть реализованы наиболее красивым образом: без всяких конечных автоматов, с сохранением во внутреннем состоянии задачи непосредственно регистра IP…


  1. RomanArzumanyan
    15.01.2018 11:38
    #10616504

    Увы, но между первыми реальными успехами языка и замещением С/С++ пройдут годы. В НРС инфляция знаний очень низкая, текущие спецы со знанием С/С++ в массе нескоро перейдут на другие языки — хотя бы потому, что потратили много времени на приобретение нынешнего уровня знаний.

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

    P. S.
    Лично я к Rust отношусь хорошо.


  1. CodeRush
    15.01.2018 13:37
    #10616780
    +1

    Добавлю из своего прошивочного погреба: для проталкивания Rust в эту нишу нужно очень сильное давление со стороны производителей CPU, потому что именно они пишут львиную долю кода прошивок и пока они не захотят сменить C на более безопасный язык — ничего с места не сдвинется.
    В Google товарищи, которые занимались coreboot, решили написать свою собственную реализацию фазы DXE (проект u-root) на Go, и у них оно может выстрелить, т.к. ресурсов достаточно, но пока индустрия вся это не поддержит — ничего не изменится, и пока даже намеков нет на какой-то прогресс в этой области.
    Понятно, что любой путь начинается с первого шага, но пока даже на этот шаг (в случае с Rust таким шагом будет добавление драйверов на нем в сборочную систему EDK2, чтобы можно было начать их собирать там же, где собирается все остальное) времени ни у кого нет.


    1. bearded_guy
      15.01.2018 14:57
      #10616998

      Большой +1. Если пользуешься процами фирмы X, то компиляторы, библиотеки и брендированный эклипс тоже от фирмы Х. Обычно даже с оффициальными тулами полно проблем, не говоря уже про сторонние.


  1. shybovycha
    15.01.2018 14:22
    #10616906

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


    1. ozkriff
      15.01.2018 14:28
      #10616922

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


      1. apro
        15.01.2018 16:37
        #10617254
        +1

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


    1. bmusin Автор
      15.01.2018 14:57
      #10616992

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


    1. torkve
      15.01.2018 15:06
      #10617022
      +3

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


      1. В стандарте так и не зафиксировано, как должны выглядеть символы для классов, методов, инстанцированных шаблонов, мэнглинг может различаться в зависимости от компилятора, языка, архитектуры, чего угодно. В windows нельзя из собранного студией кода использовать dll, собранный mingw, и наоборот. Как этим должен пользоваться внешний инструмент?
      2. Шаблоны в С++, которые хочет автор, существуют только в заголовочных файлах. Долгая затея с экспортируемыми шаблонами, введённая в 98-м стандарте, провалилась, поддержать их за десять лет смог ровно один компилятор Comeau, и в C++11 их из стандарта выкинули. Сейчас затею пытаются повторить с модулями, но чем это всё кончится, пока непонятно. Поэтому единственный способ их поддержать — самому стать компилятором C++-кода, чтобы обрабатывать заголовочные файлы с шаблонами. Затея, изначально обречённая на провал.


      1. snuk182
        15.01.2018 16:33
        #10617232
        +1

        На фоне этого всего работой github.com/rust-qt/cpp_to_rust я несказанно доволен. Да, наследования нету и не будет, скорее всего, но пока без него удается жить.


        1. torkve
          15.01.2018 17:30
          #10617342

          Да, и он работает так же, как работают абсолютно все: генерируем си-враппер, подключаем его через FFI.
          Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
          А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.


          1. snuk182
            15.01.2018 18:34
            #10617464

            И все же лучше, чем писать все с полного нуля?


            1. torkve
              15.01.2018 19:01
              #10617516

              Местами лучше, да, с этим я и не спорю :)


  1. Jenyay
    15.01.2018 14:30
    #10616924
    +1

    Для Rust не хватает стабильно обновляющихся кроссплатформенных библиотек для построения GUI, например, на основе wxWidgets / Qt.


    1. paceholder
      15.01.2018 14:36
      #10616942

      И не только GUI. Например для того же HPC большая часть написана или на C или на C++.
      Для серьезного промышленного программирования мало кто захочет возиться с биндингами к C-библиотеке.


    1. snuk182
      15.01.2018 16:31
      #10617224
      +1

      Rust QT юзабелен, с некоторыми поправками. GTK обновляется стабильно.
      Еще есть ведро библиотек на остове нативных гуёв (для Windows/Cocoa), ну и всякие чисто растовые Conrod, Limn.


      1. Jenyay
        15.01.2018 16:57
        #10617282

        Rust Qt надо попробовать. GTK не люблю из-за того, что под Виндой интерфейс выглядит чужеродно. По той же причине не люблю растровые GUI (они выглядят чужеродно везде).


  1. apro
    15.01.2018 16:34
    #10617242

    Платформы:
    поддержка компиляции в С код
    использование GCC в качестве backend'а

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


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


    1. ozkriff
      15.01.2018 16:40
      #10617262

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


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


      1. apro
        15.01.2018 18:06
        #10617414

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

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


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

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


  1. Foror
    15.01.2018 18:27
    #10617456
    +1

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


  1. Nick_mentat
    16.01.2018 12:31
    #10618480

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


    1. ozkriff
      16.01.2018 12:39
      #10618500
      +1

      Вторая проблема — нет качественной родной среды. Настройка pycharm под раст заняла у меня чересчур уж много времени. Претендовать на массовость можно если сделать установщик среды с компилятором, дебаггером и всем что положено, и разумеется — в один клик, как vs.

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


      1. Nick_mentat
        17.01.2018 12:14
        #10620598

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


    1. DarkEld3r
      16.01.2018 12:41
      #10618506

      Настройка pycharm под раст заняла у меня чересчур уж много времени.

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


    1. SilentRider
      16.01.2018 16:00
      #10619086

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


    1. snuk182
      16.01.2018 18:12
      #10619390

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

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