Comments 42
Чего, на ваш взгляд, больше всего не хватает в Rust?
HKT, специализация, impl trait.
Нет, это т.н. "конструкторы типов". Грубый аналог из С++
template<template<class> HKT>Один из примеров использования — те самые монады. Есть более конкретные примеры, но сходу не вспомню.
Хороший, на мой взгляд, пример потенциального использования типов высшего порядка можно показать на таком примере:
trait Container<T> {
// some methods
}
fn map<T, C: Container<T>>(c: C<T>) -> C<T> {
// some code
}Мы хотим на уровне сигнатуры функции выразить то, что функция map не только возвращает контейнер элементов того же типа, что аргумент, но и конкретная реализация контейнера у аргумента и возвращаемого значения тоже совпадает.
В 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++»
использование GCC в качестве backend'а
Вот серьозно, зачем это нужно если есть LLVM.
поддержка асинхронного программирования (async/await)
Как по мне в rust лучше предоставить семейство типов для работы с асинхронностью. async/await лучше оставить более высокоуровневым языкам. Например в с# это модель очень удобна, но достигается путем нескольких абстракции.
Вот серьозно, зачем это нужно если есть LLVM.
LLVM поддерживает намного меньше целевых платформ, разве нет?
Те же, кто входит в индустрию, как правило, тратят время на изучение матчасти, т. к. для НРС гораздо важнее знать алгоритмы, структуры данных и архитектуру целевых платформ, поскольку прослойка между ПО и железом тонкая. Нет какой-то большой разницы, откуда дёргать НРС либы — из С или Rust.
P. S.
Лично я к Rust отношусь хорошо.
В Google товарищи, которые занимались coreboot, решили написать свою собственную реализацию фазы DXE (проект u-root) на Go, и у них оно может выстрелить, т.к. ресурсов достаточно, но пока индустрия вся это не поддержит — ничего не изменится, и пока даже намеков нет на какой-то прогресс в этой области.
Понятно, что любой путь начинается с первого шага, но пока даже на этот шаг (в случае с Rust таким шагом будет добавление драйверов на нем в сборочную систему EDK2, чтобы можно было начать их собирать там же, где собирается все остальное) времени ни у кого нет.
Вот сколько раз не смотрел в сторону Rust — не хватает в нем одной немаловажной фичи — взаимодействие с существующими библиотеками на С++ (в силу множества причин)
Я так понимаю что план состоит в создании внешних генераторов, которые, насколько это возможно с учетом различных подходов языков к куче всего, будут сами делать привязки. До какой-то, пока не очень большой, степени сишный rust-lang-nursery/rust-bindgen уже умеет работать с C++, но еще есть довольно перспективный rust-qt/cpp_to_rust.
Еще есть мой проект https://github.com/Dushistov/rust_swig для генерации c++ обертки для rust кода. Он как бы в обратную сторону от bindgen, для вызова rust кода из c/c++,
а не для вызова c/c++ из rust что сделано в bindgen. Права в отличии от jni/java backend, c++ backend только в начале развития.
Он одинаково хорошо взаимодействует как с Rust, так и с С++.
Вообще довольно странно выглядит требование работать с библиотеками на C++, учитывая то, что никто не может работать с библиотеками на C++ (даже C++):
- В стандарте так и не зафиксировано, как должны выглядеть символы для классов, методов, инстанцированных шаблонов, мэнглинг может различаться в зависимости от компилятора, языка, архитектуры, чего угодно. В windows нельзя из собранного студией кода использовать dll, собранный mingw, и наоборот. Как этим должен пользоваться внешний инструмент?
- Шаблоны в С++, которые хочет автор, существуют только в заголовочных файлах. Долгая затея с экспортируемыми шаблонами, введённая в 98-м стандарте, провалилась, поддержать их за десять лет смог ровно один компилятор Comeau, и в C++11 их из стандарта выкинули. Сейчас затею пытаются повторить с модулями, но чем это всё кончится, пока непонятно. Поэтому единственный способ их поддержать — самому стать компилятором C++-кода, чтобы обрабатывать заголовочные файлы с шаблонами. Затея, изначально обречённая на провал.
Таким способом невозможно использовать шаблоны, кроме явно инстанцированных (ещё вероятно можно вручную попросить инстанцировать нужные специализации, но в описании я ничего такого не нашёл).
А ещё это будет очень весело работать с обёрнутым #ifdef-ами кодом: чтобы правильно сгенерировать обёртку к библиотеке, надо (как-то) выставить все те же дефайны, с которыми она собиралась, т.е. любую библиотеку из системного репозитория придётся фактически пересобирать, т.е. мы всё-таки начинаем кроме раста и обёртки компилировать ещё и плюсовый код. И если у нас есть библиотека, обмазанная autotools, то потребуется: autotools для библиотеки, cmake для cpp_to_rust, и cargo для сборки всего воедино — три билд-системы.
Для серьезного промышленного программирования мало кто захочет возиться с биндингами к C-библиотеке.
Еще есть ведро библиотек на остове нативных гуёв (для Windows/Cocoa), ну и всякие чисто растовые Conrod, Limn.
Платформы:
поддержка компиляции в С код
использование GCC в качестве backend'а
Противоречиво выглядит,
во-первых почему два пункта, если мы умеем rust->C, значит финальный
бинарник можно и с помощью gcc сгенерировать, в чем может быть проблема?
во-вторых есть https://github.com/JuliaComputing/llvm-cbe llvm C backend,
если в нем что-то не работает то не проще ли его доработать, чем городить
велосипед для генерации rust->C?
В оригинале было "или".
Сишный бэкенд LLVM, насколько я знаю, заброшен очень давно уже. Возможно, его и можно починить-допилить, но подозреваю что это совсем не просто — иначе зачем бы его забрасывали?
но подозреваю что это совсем не просто — иначе зачем бы его забрасывали?
Наверное потому что на самом деле он мало кому нужен,
ведь все основные платформы поддерживаются, а все остальное нужно очень мало числу людей.
Сишный бэкенд LLVM, насколько я знаю, заброшен очень давно уже
https://github.com/JuliaComputing/llvm-cbe это отдельный от llvm проект.
И куда там развиваться? LLVM IR вроде бы стабильный, если проект обрабатывает
достаточно большое подмножество и делает это правильно, то развиваться дальше практически некуда.
Вторая проблема — нет качественной родной среды. Настройка pycharm под раст заняла у меня чересчур уж много времени. Претендовать на массовость можно если сделать установщик среды с компилятором, дебаггером и всем что положено, и разумеется — в один клик, как vs.
А сам язык вроде уже норм, и я бы сказал что нужно не поддержку библиотек сделать, а скорее вообще ввести этот стиль как опциональную возможность, когда не всё вшивается в экзе, а модульно составляется — для написания ОС было бы полезно всё таки.
Вторая проблема — нет качественной родной среды. Настройка pycharm под раст заняла у меня чересчур уж много времени. Претендовать на массовость можно если сделать установщик среды с компилятором, дебаггером и всем что положено, и разумеется — в один клик, как vs.
Самый дружелюбный IDE опыт на данный момент — https://intellij-rust.github.io — в целом все из коробки работает. Еще есть официальный https://github.com/rust-lang-nursery/rls-vscode, но RLS в ночниках иногда может фигово работать — надо уметь сказать rustup'у откатиться на прошлый ночник.
Настройка pycharm под раст заняла у меня чересчур уж много времени.
С использованием вот этого плагина, так? Какие сложности возникли? А то я использую IntelliJ Rust с CLion и вполне доволен.
А в чем собственно была проблема? и как давно это было?
Не в создании нового проекта случайно?
Вторая проблема — нет качественной родной среды.
По щелчку пальцев ставится и настраивается Eclipse c RustDT, но у нее два относительно серьёзных минуса:
- IDE толстая, просит Java для работы, и потому не для слабых машин
- Поддержка RustDT остановлена год назад. Но пока в языке не вкрутили чего-то, ломающего старые юзкейсы, это не страшно.
Rust: «Назад к корням»