| layout | categories | title | author | original | translator |
|---|---|---|---|---|---|
post |
размышления |
Назад к корням |
666 |
bmusin |
Мне приходит в голову множество разных целей для Rust в текущем 2018 году, к слову, 2017 год прошел для меня очень быстро, так что я задался следующим вопрсом: Если бы я мог выбрать одну-единственную цель для Rust в 2018 году, то что бы я выбрал?
Я буду пристрастен, вот мое мнение:
В 2018 году никто не должен начинать писать новый проект на C или C++.
Я системный программист([HPC][hpc]) и сейчас, если мне придется выбрать для работы язык программирования, то я буду выбирать лишь между C и C++. Rust не является для меня достаточно хорошим вариантом, несмотря на то, что я использую данный язык для своих небольших проектов и для быстрого прототипирования.
Почему именно эта цель, а не какая-либо другая? Действительно, Rust хорошо подходит для многих задач, которые лежат вне плоскости системного программирования. Однако это очень широкое поле, где уже и так имеется довольно большое количество других ЯП, и так как они заточены под разные задачи - некоторые, например, используют GC(garbage collector) - то для некоторых специфических задач они будут подходить лучше, чем Rust.
С другой стороны, область ЯП системного програмирования достаточно узка, где имеются только два достойных рассмотрения, похожих друг на друга языка: C и C++. Сообщества, которые они образуют огромны (миллионы разработчиков), и эти программисты хотят, чтобы на Rust'е можно было успешно решать те же задачи, которые они решают, используя два вышеупомянутых ЯП.
Безопасная работа с память без использования сборщика мусора имела успех,
но для C и C++ разработчиков использование Rust до сих вынуждает идти на некоторые
компромисы. Так что 2018 год должны быть годом безопасной работы с памятью без
компромисов: чтобы в 2019 году никто из тех, кто профессионально занимается написанием
unsafe кода не мог утверждать: "Я не могу использовать Rust из-за X" и в то
же время быть правым. У нас уже имеется "безопасный" язык, в этом году мы
должен провести такую работу, чтобы те, кому нужна такая "безопасность", не имели
оправдания не использовать Rust. Начинание написания нового низкоуровневого проекта в 2019
году на С или C++ должно заставлять людей удивленно поднимать брови и никак иначе.
Для того чтобы достичь этой цели, мы должны выяснить какие области системного программирования (обработка финансовых транзакций, вычисления на суперкомпьютерах, написание драйверов устройств, программирование ядер ОС, программирование для встраиваемых систем, разработка игр, системы автоматизированного проектирования (CAD), браузеры, компиляторы...) имеют препятствия, оценить их и устранить, чтобы сделать Rust наиболее подходящим языком для этих областей.
Мы определенно должны параллельно улучшать Rust для использования в WASM, написания скриптов, веб-разработки и других областей. Но если бы мне пришлось выбрать одну главную цель для развития в этом году, то я бы выбрать область системного программирования.
P.S: Я не хочу делать главным фокусом этой заметки какие-либо определенные возможности языка. Имеются много возможностей языка, работа над которыми уже идет, но которые до сих пор находятся в незавершенном состоянии или нестабильны.
Относящиеся к языку: модель-памяти (C/C++), использование ассемблерных вставок в коде, константные generic'и, макросы 2.0, поддержка асинхронного программирования(async/await), alloca(С), массивы с размером задаваемым во время выполнения (VLA)(С)
Относящиеся к библиотекам: потоковые итераторы (С++), использование SIMD инструкций (С/C++), встроенные функции компилятора (intrinsics), аллокаторы памяти(C++), обработка положений нехватки памяти(OOM) (С++)
Инструментарий: выявление неопределенного поведения(UB): 100% выявление UB во время выполнения, определение покрытия кода тестами в cargo. IDE (C/C++): автодополнение, переход к определению, переименовывание, рефакторинг, форматирование кода Сargo: использование сквозь ssh-каналы, внутренние зеркала, объединение xargo/cargo в единый cargo Платформы: поддержка компиляции в С код, использование GCC в качестве backend, поддержка CUDA. взаимное использование Rust и C++ кода, в частности шаблонов, "концептов", модулей.
Замечу, что каждой их этих проблем было уделено много часов работы в Rust-сообществе. Я не упомянул ABI-совместимость, ибо этому было уделено сравнительно мало внимания.
В частности, работа над моделью памяти и неопределенным поведением - это то, что может выгодно отличить Rust от C и C++, которые также имеют свои модели памяти, но не имеют способа выявлять неопределенное поведение (UB). Можно даже сказать, что отсутствие модели памяти делает язык гораздо хуже, чем C и C++ на мой взгляд.
hpc "High-performance computing"