Комментарии 18
> Всё её прелесть в возможности установить внешние плагины на ваш cargo.
Не только плагины же, а любые приложения с crates.io (где в cargo.toml есть bin-секция).
Не только плагины же, а любые приложения с crates.io (где в cargo.toml есть bin-секция).
Нормально ли живёт с multirust?
А как обновлять-то установленные приложения?
Команда fmt позволяет автоматически форматировать код. Близкий аналог есть в Go.Скажем УРА, товарищи!
И ещё у неё есть конфиг!
github.com/rust-lang-nursery/rustfmt#configuring-rustfmt
github.com/rust-lang-nursery/rustfmt#configuring-rustfmt
А вот это как раз не радует. Нельзя разрешать разные стили форматирования.
Категорически не согласен. Разные проекты/команды имеют полное право устанавливать свои стандарты кодирования. Или 640Кб одного формата хватит на всех? По дефолту форматирование настроено на то, что использует core team, так что проще всего использовать его из коробки. Но если команда решит для своего проекта подправить какие-то мелочи, она может это сделать. И положить rustfmt.conf в репозиторий, так что все члены команды смогут поддерживать одинаковое форматирование, просто запуская cargo fmt перед коммитом.
Вашими устами да мёд пить. Кроме команды, которую можно надрессировать выбранному стилю (что тоже не всегда удаётся), будет ещё и весь остальной мир, библиотеки которого нужно будет подключать к проекту. И получится как в C++, шаг вправо — шаг влево, в сторону сторонней библиотеки — и перед тобой разверзается портал в другой мир…
А какая, извините, мне разница, как отформатирован код у библиотеки, которую я просто прописал в Cargo.toml? Абсолютно пофиг. Ибо заглядывать я туда буду дай бог раз в год. Если и потребуется лезть в сторонний код, то только если там какой-то баг, но только для того, чтобы запостить багрепорт или PR. Что бывает не так уж часто.
Не знаю… но опыт Golang и ядра Linux говорит в пользу единого стиля форматирования.
Решение Go в этом плане вообще граничит с диктатурой (никакой подсветки синтаксиса! один стандарт кодирования на всех!). Совершенно другая идеология, по сравнению с растом. Да, можно, конечно, вспомнить про питон и PEP8, но этот пеп носит рекомендательный характер, проверяльные утилиты гибко настраиваются под стандартны любой команды (PEP8 по дефолту), так что в этом плане питон ближе к расту. В общем прокрустово ложе go fmt скорее исключение из правил.
Linux — самостоятельный проект со своим стилем форматирования, про что я и говорил: внутри проекта команда может устанавливать любые стандарты. Но они же не навязывают свои стандартны всем, кому попало (понятно, что если хочешь контрибутить в проект, то должен выполнять командные правила, но если нет, то ты волен сам решать, как писать на Си).
Так что оба примера мимо кассы.
Linux — самостоятельный проект со своим стилем форматирования, про что я и говорил: внутри проекта команда может устанавливать любые стандарты. Но они же не навязывают свои стандартны всем, кому попало (понятно, что если хочешь контрибутить в проект, то должен выполнять командные правила, но если нет, то ты волен сам решать, как писать на Си).
Так что оба примера мимо кассы.
Да, не путайте подключаемые сторонние библиотеки, и код, который контрибутиться ко мне в проект. Если мне в какой-то мой проект придёт PR с новой фичей/багфиксом, то это претендент на включение в мой код, и должен соответствовать правилам проекта. Если я включаю стороннюю библиотеку как зависимость, то это чужой код, и автор библиотеки мне ничего не должен. В общем принцип простой: не лезь в чужой монастырь со своим уставом, и в Тулу со своим самоваром.
Дрессировать никого не нужно. Есть тулза, которая всё приводит в нужный вид. Всё, что нужно, сказать членам команды запускать cargo fmt перед коммитом. Или вообще повесить на git/hg хук. Всё. Нулевые накладные расходы.
Немного срывает шаблон расширение .exe у бинарников в листинге явно с линуксовой машины.
Кросс-компиляция?
Кросс-компиляция?
Я думаю, что это какой-то шелл для виндоуса.
Машина явно виндусовая:
Машина явно виндусовая:
mould path: «C:\\DEVELOPMENT\\rust-dev\\mould»
Это Windows + MSYS2. Раньше использовал VisualStudio, чтобы отлаживать C, всё перенёс на Rust, теперь Win не требуется.
Хотя в Linux всё же удобнее. Например, Ctrl+C не всегда корректно обрабатывается. Если запустить cargo run, прервать выполнение сервера нельзя, приходится в диспетчере отлавливать, потому привык к паре:
Тем не менее сборка и продакшн у меня в EC2 на CentOS. Ни разу не возникли проблемы с переносимостью. Оба варианта компилируются как родные.
Хотя в Linux всё же удобнее. Например, Ctrl+C не всегда корректно обрабатывается. Если запустить cargo run, прервать выполнение сервера нельзя, приходится в диспетчере отлавливать, потому привык к паре:
cargo build && RUST_LOG=debug ./target/debug/main.exe
Тем не менее сборка и продакшн у меня в EC2 на CentOS. Ни разу не возникли проблемы с переносимостью. Оба варианта компилируются как родные.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rust 1.5: Cargo с блэкджеком