В идее сейчас есть два плагина — Scala (официальный) и SBT (сторонний). Но начиная с 13й версии поддержка SBT встроена в официальный плагин Scala, поэтому никаких других плагинов для SBT не нужно ни в идее, ни в SBT.
Единственный минус — пока что официальный плагин не поддерживает SBT-консоль и выполнение SBT-команд (это запланировано), поэтому если это нужно, то нужно воспользоваться сторонним плагином для SBT. Хотя опять же 13я идея умеет открывать полноценный терминал внутри себя, так что особой нужды в стороннем плагине нет.
Кстати, для IDEA, начиная с 13й версии, уже совершенно не нужны сторонние плагины для SBT. Встроенный плагин для идеи сам умеет загружать и анализировать SBTшные проекты, почти как с Maven или Gradle.
Да, есть такая проблема. Частично решение уже есть — можно использовать комбинаторы вроде and_then(). В обсуждении есть ещё несколько RFC, которые предлагают различные варианты решения.
Да, «crates» так называются ещё с очень старой версии языка, когда был ещё первый Cargo. Но это, наверное, единственный такой термин. Даже «borrowed pointers» теперь называются просто ссылками.
А термин «package» уже занят — так называются пакеты Cargo. В пакете может быть много ящиков :) — максимум одна библиотека и много выполняемых бинарников.
Rust — не функциональный и не объектно-ориентированный язык, без карринга, глобального вывода типов и сборки мусора. Хотя, конечно, Rust ближе к OCaml чем к Haskell. С другой стороны, система типов Rust не имеет аналогов — других языков, основанных на понятии владения и заимствования, фактически, нет (Cyclone близок, но он скорее исследовательский язык, чем практический). Да, Rust вдохновлялся OCaml, но это совершенно разные языки.
Да, всё так как вы говорите. Но вы сравните время, сколько существует OCaml и сколько существует Rust, который даже до стабильной версии ещё не добрался. Задатки есть, поэтому добавить поддержку дополнительных платформ будет, по крайней мере, не невозможно. Кроме того, процесс разработки языка очень открытый, поэтому если кому-то это действительно надо и есть желание поучаствовать в развитии языка, всегда можно присылать патчи и RFC.
Давайте будем объективными. Haskell непригоден для системного программирования в силу своей высокоуровневости и необходимости рантайма, и никакие «ключики компилятора» это не исправят. Другая проблема (опять же, будем объективными) — Haskell слишком отличается от привычных языков, и аудиторию системщиков на него не перетянуть, несмотря на все потенциальные гарантии и даже если бы Haskell и работал без рантайма. Попытка уже есть — видели ATS? На benchmarksgame он валил C по скорости, хотя потом его оттуда почему-то убрали. Тем не менее, им никто не пользуется, именно из-за того, что ML-подобный язык с соответствующей системой типов непрактичен для низкоуровневого программирования.
Насколько я знаю без трассирующего сборщика мусора нельзя собрать некоторые «частные» случаи, например циклические ссылки. Непонятно как в Rust решили эту проблему. Но если решили, определённо тянет на открытие.
В Rust возможно реализовать умные указатели, которые будут использовать сборку мусора. Сейчас же в Rust есть тип Rc<T>, который предоставляет указатель с подсчётом ссылок, и да, для него есть специальный тип Weak<T>, который решает проблему циклических ссылок. Поэтому да, делать ссылающиеся на себя структуры немного неудобно.
Тут вопрос в том, насколько часто вам нужны графоподобные структуры объектов. Да, если вам нужно много работать с такими структурами, вам сейчас придётся писать больше кода, чем потребовалось бы в языке типа C++, Java или Haskell. Но я бы не сказал, что такие ситуации встречаются часто, особенно в системном программировании, где существуют типы-значения.
Кроме того, циклические ссылки — это далеко не самая главная проблема работы с памятью на низком уровне. Утечки памяти, use-after-free, double free, многопоточные гонки данных гораздо страшнее, и их гораздо сложнее отлавливать. С последними, например, никакой сборщик мусора вам не поможет в принципе. И с этими проблемами Rust справляется на ура благодаря статическому анализу. Сейчас не существует языка, в котором есть похожий статический анализатор. Есть Cyclone, но он больше исследовательский, а не практический язык, и насколько я знаю, анализ в Rust всё-таки мощнее.
В Rust у вас zero-cost-абстракции. В Haskell этого нет, к сожалению, а если и есть — то за гранью возможностей большинства программистов. Также в Rust безопасность работы с памятью обеспечивается не за счёт сборщика мусора, а за счёт мощного статического анализа.
Побочные эффекты в Rust не контролируются в том смысле, что в Haskell. Монад здесь нет :) На типы высшего порядка очень большой запрос в сообществе, но в версии 1.0 их не случится. Однако система типов позволяет контролировать определённые паттерны, которые в языках вроде C и C++ ведут к сегфолтам и гонкам.
В целом, бессмысленно сравнивать Haskell и Rust, у них совершенно разные ниши. Haskell не является системным языком, он не живёт без рантайма и сборки мусора, в отличие от Rust, поэтому их области применения различны.
далеко не всегда оптимальный генерируемый код по сравнению с другими языками (по скорости)
Справедливо для всех языков, в принципе. С -O2 Rust очень близок к C и регулярно переплёвывает разрекламированный Go.
великоватые бинарники
Есть такое — из-за того, что в бинарник статически линкуется рантайм. Отключите рантайм и получите размер чуть больше, чем соответствующая программа на C. В целом, это не видится разработчикам языка (да и не только им) такой уж большой проблемой, с учётом того, сколько сейчас стоит дисковая память.
отсутствие компилятора (как и эмит-бэкенда) для не-интел платформ
Странное утверждение. Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка. А ещё см. здесь.
Я сейчас перевожу пост, опубликованный разработчиками, в течении нескольких дней будет готово — выложу на Хабр. Вслед за ним авторы языка планируют написать ещё несколько статей, посвящённых основным фичам языка и экосистемы. Rust наконец-то выходит в большой мир :)
map() в Rust — это операция на итераторе, которая создаёт другой итератор. если вам нужна другая коллекция, то вам понадобится collect(). В итоге код может выглядеть так:
let a = [1, 2, 3, 4];
let v: Vec<int> = a.iter().map(|x| x*2).collect();
collect() вообще не знает откуда он берёт данные, он просто скармливает итератор в реализацию трейта FromIterator, а эта реализация уже проходит по итератору и заполняет коллекцию. Поскольку итераторы умеют в size_hint, это получается довольно эффективно.
Проверка границ происходит в реализации итератора, который возвращает iter(). Для срезов и векторов и там используется адресная арифметика, см. здесь.
Спасибо за статью, Fossil — действительно интересная штука по своей архитектуре, но, если честно, каких-то преимуществ перед другими DVCS (в частности, перед гитом) пока не видно. На первый взгляд, набор операций, фактически, тот же самый, за исключением непривычных названий (странно, что общепринятый Carriage-Return-Line-Feed здесь назвали Carriage-Return-New-Line). Жду вторую часть :)
И кстати, «repository» переводится на русский всё же как «репозитoрий». На хабре была не так давно замечательная статья на эту тему, но я её что-то не могу найти…
Здесь разница в коннотации. «pure» обычно подразумевает что-то чистое в смысле «чистый спирт» — нечто, свободное от примесей. Чистое в смысле «не грязное» — это как раз «clean».
Единственный минус — пока что официальный плагин не поддерживает SBT-консоль и выполнение SBT-команд (это запланировано), поэтому если это нужно, то нужно воспользоваться сторонним плагином для SBT. Хотя опять же 13я идея умеет открывать полноценный терминал внутри себя, так что особой нужды в стороннем плагине нет.
Кстати, для IDEA, начиная с 13й версии, уже совершенно не нужны сторонние плагины для SBT. Встроенный плагин для идеи сам умеет загружать и анализировать SBTшные проекты, почти как с Maven или Gradle.
and_then(). В обсуждении есть ещё несколько RFC, которые предлагают различные варианты решения.А термин «package» уже занят — так называются пакеты Cargo. В пакете может быть много ящиков :) — максимум одна библиотека и много выполняемых бинарников.
В Rust возможно реализовать умные указатели, которые будут использовать сборку мусора. Сейчас же в Rust есть тип
Rc<T>, который предоставляет указатель с подсчётом ссылок, и да, для него есть специальный типWeak<T>, который решает проблему циклических ссылок. Поэтому да, делать ссылающиеся на себя структуры немного неудобно.Тут вопрос в том, насколько часто вам нужны графоподобные структуры объектов. Да, если вам нужно много работать с такими структурами, вам сейчас придётся писать больше кода, чем потребовалось бы в языке типа C++, Java или Haskell. Но я бы не сказал, что такие ситуации встречаются часто, особенно в системном программировании, где существуют типы-значения.
Кроме того, циклические ссылки — это далеко не самая главная проблема работы с памятью на низком уровне. Утечки памяти, use-after-free, double free, многопоточные гонки данных гораздо страшнее, и их гораздо сложнее отлавливать. С последними, например, никакой сборщик мусора вам не поможет в принципе. И с этими проблемами Rust справляется на ура благодаря статическому анализу. Сейчас не существует языка, в котором есть похожий статический анализатор. Есть Cyclone, но он больше исследовательский, а не практический язык, и насколько я знаю, анализ в Rust всё-таки мощнее.
Побочные эффекты в Rust не контролируются в том смысле, что в Haskell. Монад здесь нет :) На типы высшего порядка очень большой запрос в сообществе, но в версии 1.0 их не случится. Однако система типов позволяет контролировать определённые паттерны, которые в языках вроде C и C++ ведут к сегфолтам и гонкам.
В целом, бессмысленно сравнивать Haskell и Rust, у них совершенно разные ниши. Haskell не является системным языком, он не живёт без рантайма и сборки мусора, в отличие от Rust, поэтому их области применения различны.
Справедливо для всех языков, в принципе. С -O2 Rust очень близок к C и регулярно переплёвывает разрекламированный Go.
Есть такое — из-за того, что в бинарник статически линкуется рантайм. Отключите рантайм и получите размер чуть больше, чем соответствующая программа на C. В целом, это не видится разработчикам языка (да и не только им) такой уж большой проблемой, с учётом того, сколько сейчас стоит дисковая память.
Странное утверждение. Rust работает поверх LLVM, что, в частности, означает свободную поддержку ARM. Версия для Android, кстати, официально поддерживается разработчиками языка. А ещё см. здесь.
Да, каждый двигался относительно другого, но ускорялся только один из них. Поэтому и возникает «асимметрия».
map()в Rust — это операция на итераторе, которая создаёт другой итератор. если вам нужна другая коллекция, то вам понадобитсяcollect(). В итоге код может выглядеть так:collect()вообще не знает откуда он берёт данные, он просто скармливает итератор в реализацию трейтаFromIterator, а эта реализация уже проходит по итератору и заполняет коллекцию. Поскольку итераторы умеют в size_hint, это получается довольно эффективно.Проверка границ происходит в реализации итератора, который возвращает iter(). Для срезов и векторов и там используется адресная арифметика, см. здесь.
Мой будущий парсер тоже не будет использовать регулярки, кстати.
И кстати, «repository» переводится на русский всё же как «репозитoрий». На хабре была не так давно замечательная статья на эту тему, но я её что-то не могу найти…
Ну и при мёржах он автоматически вызывается.