Да, не путайте подключаемые сторонние библиотеки, и код, который контрибутиться ко мне в проект. Если мне в какой-то мой проект придёт PR с новой фичей/багфиксом, то это претендент на включение в мой код, и должен соответствовать правилам проекта. Если я включаю стороннюю библиотеку как зависимость, то это чужой код, и автор библиотеки мне ничего не должен. В общем принцип простой: не лезь в чужой монастырь со своим уставом, и в Тулу со своим самоваром.
Решение Go в этом плане вообще граничит с диктатурой (никакой подсветки синтаксиса! один стандарт кодирования на всех!). Совершенно другая идеология, по сравнению с растом. Да, можно, конечно, вспомнить про питон и PEP8, но этот пеп носит рекомендательный характер, проверяльные утилиты гибко настраиваются под стандартны любой команды (PEP8 по дефолту), так что в этом плане питон ближе к расту. В общем прокрустово ложе go fmt скорее исключение из правил.
Linux — самостоятельный проект со своим стилем форматирования, про что я и говорил: внутри проекта команда может устанавливать любые стандарты. Но они же не навязывают свои стандартны всем, кому попало (понятно, что если хочешь контрибутить в проект, то должен выполнять командные правила, но если нет, то ты волен сам решать, как писать на Си).
Дрессировать никого не нужно. Есть тулза, которая всё приводит в нужный вид. Всё, что нужно, сказать членам команды запускать cargo fmt перед коммитом. Или вообще повесить на git/hg хук. Всё. Нулевые накладные расходы.
А какая, извините, мне разница, как отформатирован код у библиотеки, которую я просто прописал в Cargo.toml? Абсолютно пофиг. Ибо заглядывать я туда буду дай бог раз в год. Если и потребуется лезть в сторонний код, то только если там какой-то баг, но только для того, чтобы запостить багрепорт или PR. Что бывает не так уж часто.
Категорически не согласен. Разные проекты/команды имеют полное право устанавливать свои стандарты кодирования. Или 640Кб одного формата хватит на всех? По дефолту форматирование настроено на то, что использует core team, так что проще всего использовать его из коробки. Но если команда решит для своего проекта подправить какие-то мелочи, она может это сделать. И положить rustfmt.conf в репозиторий, так что все члены команды смогут поддерживать одинаковое форматирование, просто запуская cargo fmt перед коммитом.
Статья интересная, хотя бы тем, что благодаря ей я узнал про HL7, поэтому, конечно, плюс.
Но зачем тогда её переводить на русский и выкладывать на русскоязычном ресурсе, если «сохранены оригинальные названия, т.к. конкурс в первую очередь для англоязычной аудитории»? Переводите тогда всё, а если нужна точность — в скобках оригинальные названия и термины.
А то получается так, как в анекдоте: либо трусы снимайте, либо крестик наденьте.
Я бы плюсанул в карму, но плюсовать можно только тех, у которых есть публикации. В итоге только минусовать можно, а те, кто хочет поставить плюс, тупо не могут это сделать. Напиши какую-нибудь статью, будет проще плюсы получать =)
Самое смешное, что как раз do-нотация есть в виде макроса. Проблема в том, что она недостаточно общая, нельзя её написать для всех монад сразу без HKT, нужно реализовать отдельно для каждого монадического типа. А HKT вводить не торопятся.
На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.
Понятно, что внутре будет не просто одна только неонка, а сложная алгоритмически-ёмкая реализация, но для пользователя языка это просто новый синтаксис.
Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
Всё равно не вижу большой проблемы. Ну появится тип Gc<T>, наравне с Rc<T>, Arc<T> и Box<T>, ну и что? Семантика работы с ним будет аналогичная, использование — только явное, то есть не будет так, что ты делаешь let x = 123; и оно внезапно подхватывается актичным сборщиком мусора, который будет следить за x.
Linux — самостоятельный проект со своим стилем форматирования, про что я и говорил: внутри проекта команда может устанавливать любые стандарты. Но они же не навязывают свои стандартны всем, кому попало (понятно, что если хочешь контрибутить в проект, то должен выполнять командные правила, но если нет, то ты волен сам решать, как писать на Си).
Так что оба примера мимо кассы.
640Кбодного формата хватит на всех? По дефолту форматирование настроено на то, что использует core team, так что проще всего использовать его из коробки. Но если команда решит для своего проекта подправить какие-то мелочи, она может это сделать. И положить rustfmt.conf в репозиторий, так что все члены команды смогут поддерживать одинаковое форматирование, просто запуская cargo fmt перед коммитом.Кросс-компиляция?
github.com/rust-lang-nursery/rustfmt#configuring-rustfmt
Но зачем тогда её переводить на русский и выкладывать на русскоязычном ресурсе, если «сохранены оригинальные названия, т.к. конкурс в первую очередь для англоязычной аудитории»? Переводите тогда всё, а если нужна точность — в скобках оригинальные названия и термины.
А то получается так, как в анекдоте: либо трусы снимайте, либо крестик наденьте.
tryвполне может вырасти do-нотация, как в скале случилось сfor.На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.
Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
let x = 123;и оно внезапно подхватывается актичным сборщиком мусора, который будет следить за x.