Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
<мечты>Была бы ещё для Rust удобная среда разработки</мечты>
Еще релиза не было, а Вы про среду)
Будет развитие языка — будет и среда
Будет развитие языка — будет и среда
Как по мне Rust уже развит настолько, насколько можно желать для комфортного решения задач. Субьективно оценивая, больше половины использующих Rust не будут использовать (а возможно даже знать) все возможности, предоставляемые нам компилятором этого замечательного языка. Так почему же нельзя обратить внимание в сторону того, чтобы на язык было проще переключиться с другого (C++ или новомодного и любимого мной Go к примеру)?
У раста, при всей моей симпатии к нему как к языку и целям разработчиков, пока есть некоторые существенные проблемы, которые несколько ограничивают его широкое использование на данный момент: далеко не всегда оптимальный генерируемый код по сравнению с другими языками (по скорости), великоватые бинарники (собранный версией 0.11.0 «hello world» для x64 занимает что-то типа 1.7M unstripped супротив ~150K у окамла например) и отсутствие компилятора (как и эмит-бэкенда) для не-интел платформ, а это важно для языка, который по идее должен заменить си/плюсы в том числе в ембеддеде.
В то же время, раст выглядит очень привлекательным именно за счет того, за что его ругают функциональщики — если на первых порах он был скорее больше похож на «ML с плюсами», то сейчас все чаще говорят о «C++ done the right way». Спорить с этом тяжело, ибо история показывает, что императивно-ориентированный синтаксис — очень сильный буст к популярности. (Тут уместно вспомнить ремарки о чутье Гвидо по поводу того, как должен выглядеть питон.)
В то же время, раст выглядит очень привлекательным именно за счет того, за что его ругают функциональщики — если на первых порах он был скорее больше похож на «ML с плюсами», то сейчас все чаще говорят о «C++ done the right way». Спорить с этом тяжело, ибо история показывает, что императивно-ориентированный синтаксис — очень сильный буст к популярности. (Тут уместно вспомнить ремарки о чутье Гвидо по поводу того, как должен выглядеть питон.)
Немного занудства :)
Справедливо для всех языков, в принципе. С -O2 Rust очень близок к C и регулярно переплёвывает разрекламированный Go.
Есть такое — из-за того, что в бинарник статически линкуется рантайм. Отключите рантайм и получите размер чуть больше, чем соответствующая программа на C. В целом, это не видится разработчикам языка (да и не только им) такой уж большой проблемой, с учётом того, сколько сейчас стоит дисковая память.
Странное утверждение. Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка. А ещё см. здесь.
далеко не всегда оптимальный генерируемый код по сравнению с другими языками (по скорости)
Справедливо для всех языков, в принципе. С -O2 Rust очень близок к C и регулярно переплёвывает разрекламированный Go.
великоватые бинарники
Есть такое — из-за того, что в бинарник статически линкуется рантайм. Отключите рантайм и получите размер чуть больше, чем соответствующая программа на C. В целом, это не видится разработчикам языка (да и не только им) такой уж большой проблемой, с учётом того, сколько сейчас стоит дисковая память.
отсутствие компилятора (как и эмит-бэкенда) для не-интел платформ
Странное утверждение. Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка. А ещё см. здесь.
В целом, мне кажется, с современными объёмами дискового пространства, статически скомпилированные бинарники очень удобны, потому что их просто переносить и разворачивать. Так что я бы вообще не относил это к минусам.
Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка.Да, это все хорошо. Но я немного о другом: пока что для раста очень мало готовых бутстрап-компиляторов под разные платформы и операционные системы. То есть я могу, конечно, сказать
./configure --target=arm-unknown-linux-gnueabi, но мне в любом случае понадобится нативный rustc. Еще пример: lang/rust есть в портах FreeBSD, но он amd64-only и более того:.if ${OPSYS} == FreeBSD && ${OSVERSION} < 1000000Можно, конечно, попробовать собрать rustс+LLVM самостоятельно, но это не самый тривиальный процесс, и я совсем не уверен, что мне удастся получить работающий компилятор, скажем, для powerpc или спарка. А у того же окамла такой проблемы нет.
BROKEN= Only compiles on FreeBSD 10 and 11
.endif
Да, всё так как вы говорите. Но вы сравните время, сколько существует OCaml и сколько существует Rust, который даже до стабильной версии ещё не добрался. Задатки есть, поэтому добавить поддержку дополнительных платформ будет, по крайней мере, не невозможно. Кроме того, процесс разработки языка очень открытый, поэтому если кому-то это действительно надо и есть желание поучаствовать в развитии языка, всегда можно присылать патчи и RFC.
Может будет кому интересно. Ведётся разработка плагина для VisualStudio.
Проект открытый, код доступен на GitHub: PistonDevelopers/VisualRust. Плагин, также, представлен в галерее VisualStudio, т.е. его можно установить через менеджер дополнений.
Проект открытый, код доступен на GitHub: PistonDevelopers/VisualRust. Плагин, также, представлен в галерее VisualStudio, т.е. его можно установить через менеджер дополнений.
Плагин под IDEA уже начали писать, лексер есть, грамматики для парсера в разработке. Думаю к релизу минимальный функционал разработчики допилят (go-to-symbol, минимальное авто-дополнение)
Плагин для IDEA смотрел примерно месяц назад. Осталось впечатление, что кроме подсветки ключевых слов там больше и нету ничего. Но радует, что хотя бы начало положено, будем надеятся, что получится что-то хотя бы уровня плагина для Go в той же IDEA.
Есть повод поконтрибьютить. Жаль только что лишь на JVM языках плагины к IDEA пишутся.
Автор об этом и так честно сообщает. Но там уже есть некоторые грамматики, поэтому я делаю вывод, что он не остановится на лексере (подсветке)
Получается и подстветка не полноценная, лексера ведь не достаточно, чтобы определить семантику символа.
что вы подразумеваете под семантикой символа?
можно конкретные слова (ключевые) подсвечивать, можно по регуряркам искать (комментарии, док-блоки).
Грамматика никак не влияет на подсветку, она дает возможность анализировать код для более умных фич.
В контексте раста одним только лексером вполне можно искать unsafe блоки и подсвечивать их красным, на пример.
можно конкретные слова (ключевые) подсвечивать, можно по регуряркам искать (комментарии, док-блоки).
Грамматика никак не влияет на подсветку, она дает возможность анализировать код для более умных фич.
В контексте раста одним только лексером вполне можно искать unsafe блоки и подсвечивать их красным, на пример.
Я не говорил явно про грамматику, а про семантику. Значение некоторых символов (возможно, не в Rust) и грамматикой вывести нельзя.
Простой пример:
PairМожет ли лексер в одиночку решить, имя типа ли это или же выражение, в котором Pair сравнивается на «меньше» с char, результат которых сравнивается с чем-то, что еще не было прочитано? Не может.
На мой взгляд подсветка в случае имени типа и в случае выражения должна быть разной. Возможно с этим можно поспорить.
Простой пример:
PairМожет ли лексер в одиночку решить, имя типа ли это или же выражение, в котором Pair сравнивается на «меньше» с char, результат которых сравнивается с чем-то, что еще не было прочитано? Не может.
На мой взгляд подсветка в случае имени типа и в случае выражения должна быть разной. Возможно с этим можно поспорить.
Из всего что я перепробовал, на данный момент есть одно работоспобное и не требующее самостоятельной сборки решение для винды — на основе среды разработки geany.
1. Скачиваем mingw, gtk2, geany, исходники geany c github.com/geany/geany; устанавливаем все это, а также сам rust.
2. В PATH прописываем пути к mingw/bin, gtk/bin и rust/bin
3. Из исходников geany берем папку data и целиком копируем ее с заменой той папки data которая была при установке geany. Там множество настроек для различных языков, включая rust
4. Создаем проект, в нем создаем файл с расширением .rs, пишем код!
Работает подсветка синтаксиса, компиляция и запуск прямо из среды, дерево символов, вывод сообщений компилятора в специальное окно среды, по щелчку на сообщении открывается соответствующая строка в коде. То есть стандартный набор возможностей, для начала более чем достаточно.
1. Скачиваем mingw, gtk2, geany, исходники geany c github.com/geany/geany; устанавливаем все это, а также сам rust.
2. В PATH прописываем пути к mingw/bin, gtk/bin и rust/bin
3. Из исходников geany берем папку data и целиком копируем ее с заменой той папки data которая была при установке geany. Там множество настроек для различных языков, включая rust
4. Создаем проект, в нем создаем файл с расширением .rs, пишем код!
Работает подсветка синтаксиса, компиляция и запуск прямо из среды, дерево символов, вывод сообщений компилятора в специальное окно среды, по щелчку на сообщении открывается соответствующая строка в коде. То есть стандартный набор возможностей, для начала более чем достаточно.
В комплекте с Rust идет плагин для Vim
Я сейчас перевожу пост, опубликованный разработчиками, в течении нескольких дней будет готово — выложу на Хабр. Вслед за ним авторы языка планируют написать ещё несколько статей, посвящённых основным фичам языка и экосистемы. Rust наконец-то выходит в большой мир :)
Как и обещал, вот перевод: habrahabr.ru/post/237199/
Кажется я понял суть Rust, разница между Go и Rust примерно как между мечом и магией.
Их не надо сранивать.
А какая разница между мечем и магией? Не уловил аллегорию. Кроме типа урона ничего на ум не приходит.
Комментарии про Go в постах про Rust традиционно минусуются.
Меня не столько волнуют минусы комментария, сколько комментаторы, не понимающие фундаментальную разницу между мечом и магией. >_<
Меч — реальность, магия фантастика? Но Кольт-Ассемблер, АК-Си и Малыш-Python все равно рулят.
Фундаментальная разница в том, что меч это практически обычная палка, которой надо много и усердно бить. Магия состоит из заклинаний, которые требуют сильной умственной деятельности, звучат стремно, зато можно скастовать большой взрыв.
Go проектировался как прагматичный язык с несложным и компактным стандартом. И никаких «магических» штук вроде multidispatch traits там нет. Я конечно понимаю, что программирование это сама по себе магия с точки зрения рядового человека, но на нашем девелоперском поле тоже есть некие магические направления, Rust я вынужден отнести к одному из них. Особенно глядя на синтаксис.
Go проектировался как прагматичный язык с несложным и компактным стандартом. И никаких «магических» штук вроде multidispatch traits там нет. Я конечно понимаю, что программирование это сама по себе магия с точки зрения рядового человека, но на нашем девелоперском поле тоже есть некие магические направления, Rust я вынужден отнести к одному из них. Особенно глядя на синтаксис.
Рад, что не сошёлся свет клином на C/++ и Java. Хорошая альтернатива, через пару лет, при должном развитии, можно будет внедрять в серьёзные серьёзности.
Они еще там же объявили о том, что разработка будет вестись подобно тому, как разрабатывается разрабатывается Firefox или Chrome: 3 канала с шестинедельными итерациями. Стабильный релиз каждые 6 недель.
Хочется чтобы книгу по Rust выпустили. Документация это конечно хорошо, она не заменяет хорошую книгу…
На днях, кстати, они закончили переписывание с нуля туториала и сделали более подробный и актуальный Guide: doc.rust-lang.org/guide.html
Если руки дойдут, попробую написать несколько UEFI-драйверов на Rust, заодно проверю степень интеграции с C и напишу интеграцию со сборочной системой UDK2014.
На первый взгляд системного программиста на С — язык однозначно торт, остается попробовать его в реальных проектах.
На первый взгляд системного программиста на С — язык однозначно торт, остается попробовать его в реальных проектах.
Rust сочетает в себе эффективность С и С++ с безопасностью Java.
Не совсем понимаю что значит «безопасность Java».
Вот может кто то объяснить, можно ли сделать такое на Rust?
Тоесть, чтобы функция могла как временный объект принять, так и ссылку.
template<class Point>
void callMe(Point &&p){
...
}
callMe( Point(1,2) );
Point p(1,2);
callMe(p);
Тоесть, чтобы функция могла как временный объект принять, так и ссылку.
Угу. s.draw(Point{x: 10, y: 11,}); Он здесь как — копирует Point (аля memcpy)? Или как в случае с С++ Point создается раз, данные не memcpy'тся?
P.S. Ассемблерный код конечно страшыйн выдает:))
P.S. Ассемблерный код конечно страшыйн выдает:))
Уверяют, что лишних копий не будет, и что move семантика в расте более бесшовная, чем в C++.
Вообще надо проверить, о результатах доложу.
Вообще надо проверить, о результатах доложу.
В FAQ написано что move как в С++11 в rust нет.
move Rust'a рабоает через memcpy :)) doc.rust-lang.org/complement-design-faq.html#no-move-constructors
move Rust'a рабоает через memcpy :)) doc.rust-lang.org/complement-design-faq.html#no-move-constructors
то есть оптимальным образом) в C++ в лучшем случае будет memcpy. (поля нужно скопировать в любом случае, если есть указатели, то memcpy то будет применён к непосредственно ним, а не к данным по указателю)
Не совсем, в приведенном примере работает perfect forwarding, и в случае если ссылка Point&& p привяжется к rvalue-expression, даже memcpy не будет. Будет применен copy/move elision. На этом принципе работают всякие emplace/emplace_back/emplace_front в стандартных контейнерах.
elision как раз равносилен memcpy. Одно всегда можно заменить другим, при этом наблюдаемое поведение не изменится. Это чисто техническая оптимизация, и ребята из rust ее сделают, если это будет необходимо, как мне кажется.
Я говорю о том, что копирования не будет вообще никакого. Конечно же это оптимизация (причем прописанная в стандарте). Вопрос ведь был в том, насколько это дешево. Отсутствие memcpy точно дешевле, чем его присутствие.
А про наличие copy/move elision у них ничего не сказано? Если Вы, конечно, читали их доки целенаправленно.
Прочёл статью и стало интересно, что такого можно сделать на Rust, чего нельзя сделать на Haskell? Гуру просветите. И кстати, а как в чудо Rust'е контроллируются побочные эффекты?
В Rust у вас zero-cost-абстракции. В Haskell этого нет, к сожалению, а если и есть — то за гранью возможностей большинства программистов. Также в Rust безопасность работы с памятью обеспечивается не за счёт сборщика мусора, а за счёт мощного статического анализа.
Побочные эффекты в Rust не контролируются в том смысле, что в Haskell. Монад здесь нет :) На типы высшего порядка очень большой запрос в сообществе, но в версии 1.0 их не случится. Однако система типов позволяет контролировать определённые паттерны, которые в языках вроде C и C++ ведут к сегфолтам и гонкам.
В целом, бессмысленно сравнивать Haskell и Rust, у них совершенно разные ниши. Haskell не является системным языком, он не живёт без рантайма и сборки мусора, в отличие от Rust, поэтому их области применения различны.
Побочные эффекты в Rust не контролируются в том смысле, что в Haskell. Монад здесь нет :) На типы высшего порядка очень большой запрос в сообществе, но в версии 1.0 их не случится. Однако система типов позволяет контролировать определённые паттерны, которые в языках вроде C и C++ ведут к сегфолтам и гонкам.
В целом, бессмысленно сравнивать Haskell и Rust, у них совершенно разные ниши. Haskell не является системным языком, он не живёт без рантайма и сборки мусора, в отличие от Rust, поэтому их области применения различны.
1) Насколько я знаю без трассирующего сборщика мусора нельзя собрать некоторые «частные» случаи, например циклические ссылки. Непонятно как в Rust решили эту проблему. Но если решили, определённо тянет на открытие.
2) Не контроллируются побочные эффекты? Это затрудняет формальную верификацию программы. + Огромное поле для потенциальных ошибок. То есть, в итоге мы получаем тот же C++ только задизайненный чуть более на современный лад.
В общем сложилось впечатление, что лучше бы они к Haskell написали ключик компилятора, который бы делал результат компиляции «ближе» к железу, чем пилить ещё один 100500-й язык программирования.
2) Не контроллируются побочные эффекты? Это затрудняет формальную верификацию программы. + Огромное поле для потенциальных ошибок. То есть, в итоге мы получаем тот же C++ только задизайненный чуть более на современный лад.
В общем сложилось впечатление, что лучше бы они к Haskell написали ключик компилятора, который бы делал результат компиляции «ближе» к железу, чем пилить ещё один 100500-й язык программирования.
Давайте будем объективными. Haskell непригоден для системного программирования в силу своей высокоуровневости и необходимости рантайма, и никакие «ключики компилятора» это не исправят. Другая проблема (опять же, будем объективными) — Haskell слишком отличается от привычных языков, и аудиторию системщиков на него не перетянуть, несмотря на все потенциальные гарантии и даже если бы Haskell и работал без рантайма. Попытка уже есть — видели ATS? На benchmarksgame он валил C по скорости, хотя потом его оттуда почему-то убрали. Тем не менее, им никто не пользуется, именно из-за того, что ML-подобный язык с соответствующей системой типов непрактичен для низкоуровневого программирования.
В Rust возможно реализовать умные указатели, которые будут использовать сборку мусора. Сейчас же в Rust есть тип
Тут вопрос в том, насколько часто вам нужны графоподобные структуры объектов. Да, если вам нужно много работать с такими структурами, вам сейчас придётся писать больше кода, чем потребовалось бы в языке типа C++, Java или Haskell. Но я бы не сказал, что такие ситуации встречаются часто, особенно в системном программировании, где существуют типы-значения.
Кроме того, циклические ссылки — это далеко не самая главная проблема работы с памятью на низком уровне. Утечки памяти, use-after-free, double free, многопоточные гонки данных гораздо страшнее, и их гораздо сложнее отлавливать. С последними, например, никакой сборщик мусора вам не поможет в принципе. И с этими проблемами Rust справляется на ура благодаря статическому анализу. Сейчас не существует языка, в котором есть похожий статический анализатор. Есть Cyclone, но он больше исследовательский, а не практический язык, и насколько я знаю, анализ в Rust всё-таки мощнее.
Насколько я знаю без трассирующего сборщика мусора нельзя собрать некоторые «частные» случаи, например циклические ссылки. Непонятно как в Rust решили эту проблему. Но если решили, определённо тянет на открытие.
В Rust возможно реализовать умные указатели, которые будут использовать сборку мусора. Сейчас же в Rust есть тип
Rc<T>, который предоставляет указатель с подсчётом ссылок, и да, для него есть специальный тип Weak<T>, который решает проблему циклических ссылок. Поэтому да, делать ссылающиеся на себя структуры немного неудобно.Тут вопрос в том, насколько часто вам нужны графоподобные структуры объектов. Да, если вам нужно много работать с такими структурами, вам сейчас придётся писать больше кода, чем потребовалось бы в языке типа C++, Java или Haskell. Но я бы не сказал, что такие ситуации встречаются часто, особенно в системном программировании, где существуют типы-значения.
Кроме того, циклические ссылки — это далеко не самая главная проблема работы с памятью на низком уровне. Утечки памяти, use-after-free, double free, многопоточные гонки данных гораздо страшнее, и их гораздо сложнее отлавливать. С последними, например, никакой сборщик мусора вам не поможет в принципе. И с этими проблемами Rust справляется на ура благодаря статическому анализу. Сейчас не существует языка, в котором есть похожий статический анализатор. Есть Cyclone, но он больше исследовательский, а не практический язык, и насколько я знаю, анализ в Rust всё-таки мощнее.
Все тьюринг-полные языки эквивалентны в в смысле того, что на них можно сделать, так что вопрос в такой формулировке некорректный. Другое дело — что на Rust что-то делать удобнее, чем на Haskell. Языки-то сильно отличаются на самом деле, Rust не функциональный, ближе к железу, обладает другой моделью памяти, не ленив.
В Rust отсутствуют исключения, и вместо них есть тип Result. Не значит ли это, что в любой мало-мальски сложной программе везде прийдётся писать try!(...) при вызове каждой функции, которая может завершиться с ошибкой?
Да, есть такая проблема. Частично решение уже есть — можно использовать комбинаторы вроде
and_then(). В обсуждении есть ещё несколько RFC, которые предлагают различные варианты решения.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mozilla наметила план для выпуска Rust 1.0