История изменений

Исправление DarkEld3r, 19.04.21 17:45 (текущая версия) :

Я просто большую часть карьеры писал GUI, и потому для меня самоочевидно, что проверщик заимствований довольно мало проблем решает.

С GUI у раста всё печально: есть кучка библиотек разной степени готовности, ну и байндинги к разным фреймворкам. Но я не уверен, что проблема в языке. Новыx фреймворков вообще особо не наблюдается, разве что flutter. И всё чаще встречается электрон вместо нормальныx приложений.

Утверждение про бороу чекер для меня совсем не очевидно.

В императивщине же вполне себе принято делать

Хороший пример, в расте я запишу это вот так:

let a = if condition {
    2
} else {
    1
}

И переменная не будет мутабельной зря, а значит и не надо думать меняется ли она где-то ещё. Если условий несколько, то запись будет даже короче:

let a = match condition {
    x => 2,
    z => 3,
    _ => 1,
}

Мелочи? Да. Удобнее? Тоже да. А если вспомнить, что в расте повсюду Option/Result (или даже Result<Option<T>, E>), то это становится ещё значимее. И весьма вероятно, что условие выше было бы записано как-нибудь вроде let a = opt.unwrap_or(1).

Кстати, для работы с плюсовым std::variant паттерн матчинг был бы весьма удобен.

Там ведь внезапно может появиться необходимость подключать и даже компилировать либы на других языках, или использовать либы из пакетов дистра системы.

Эта необходимость появилась сразу и всё работает. Не напрямую через карго, который как раз не хотят превращать в универсальный комбайн для всех на свете языков, а благодаря тому, что у библиотеки может быть произвольный билд скрипт. Традиционно делается тонкий враппер, который и умеет собирать или подключать готовую библиотеку.

Да, карго — это монстрокобмайн, который выполняет совершенно разнородные задачи. Что само по себе является причиной ожидать альтернатив по мере популяризации раста.

Я бы не назвал эти задачи прям разнородными. Насчёт появления альтернатив: поживём - увидим. Я бы поставил на то, что в течении пяти лет альтернатив не появится.

Кстати, у хаскеля как раз есть два популярных инструмента. По моим ощущениям (человека, который на хаскель смотрит издалека) более новая и совершенная побеждает (или победила). Да, какое-то время будет разброд и шатание из-за разделения экосистемы (или необходимости поддерживать и то и другое). Но если в итоге победит более совершенный инструмент, то никакой беды не вижу. Хуже когда есть несколько плюс-минус одинаковых альтернатив, каждая из которых продолжает развиваться.

но иногда отклонение от правил делает код намного более читаемым

Безусловно. Вопрос в том насколько часто. Опять же, в моей практике это возникает не так часто. Когда clang-format только появился, то он нередко уродовал код, особенно код с макросами. С rustfmt проблем было намного меньше. Возможно в том числе потому, что в расте больше вещей фиксированы, а не отданы на откуп программисту. Подозреваю, что сейчас и clang-format подтянулся.

Кстати, забавно: ты сначала сказал, что о форматировании спорят, только если заняться нечем. А теперь заявляешь, что как раз предпочитаешь «идти против течения» и форматировать по-своему. Мне вот как раз кажется, что если человек начинает бунтовать против стандартного стиля (при условии автоматического и не убогого форматирования), то с ним что-то не так.

в частности, отклонения от правил могут применяться для того, чтобы обратить внимание на какой-то кусок кода

Для этого можно (и нужно) использовать комментарии.

и если единственное, что он может сделать на ревью — это проверить соответствие формальным критериям, то проект умрет и на нем нечего ловить

Про «единственное, что может делать» я не говорил. Хотя, пожалуй, одни из лучших ревьюверов, с которыми мне доводилось работать, были людьми весьма педантичными и могли найти как весьма хитрые и не очевидные нюансы, так и пройтись по именованию или форматированию.

А вообще зачем нужны «формальные критерии» и прочие стайлгайды, если их постоянно нарушать? Если люди не ерундой занимаются, то там как раз будут описаны полезные лучшие практики.

Если проект существует больше пары месяцев, то неизбежно возникает ситуация, когда JSON имеет более одного формата. Что с этим делать?

Зависит от ситуации. Новая версия может получаться по другому эндпоинту или новые поля будут опциональными. Не вижу проблемы.

У вас получилось два подобных API в разных форматах, что ли?

Скорее это были немного разные API, но структуры данных переиспользовались. Скажем, структуры вроде BlockHeader фигурировала как в растовом коде, так и отдавалась в виде JSON.

Кстати, ещё про сериализацию: на соседнем плюсовом проекте вся объектная модель умеет сериализоваться (используется cereal). И во всех соответствующих классах (которых дофига) присутствует код вроде такого:

template <class Archive>
void serialize( Archive & ar )
{
    ar( x, y, z );
}

И да, при добавлении поля надо не забыть добавить его в этот метод.

Исходная версия DarkEld3r, 19.04.21 17:45: