Rust набирает обороты и энтузиазм. Время компиляции Rust, не так много. Инкрементную компиляцию реализовать нелегко, что, возможно, и понятно. В конце концов, трудно исчерпывающе проверить большое количество возможных взаимодействий и комбинаций, которые являются ошибками, не проверив всесторонне множество возможных взаимодействий и комбинаций, которые являются ошибками. Rust — это взвешивание и спецификация эффектов одной строки кода в сочетании со всеми остальными строками кода. Может быть, это стоит столько, сколько стоит.
Здесь я выхожу на сцену правильно, с полусырой идеей. Почему бы нам не съесть свой торт и не съесть его тоже? Почему бы не запускать две разные компиляции каждый раз, когда мы компилируем одновременно. Обычная длинная, тщательная компиляция, а также «предварительная компиляция», которая сбрасывает большую часть тщательных проверок, которые делают Rust, Rust. (Звучит намного лучше, чем «небрежная компиляция» или «небезопасная компиляция», не так ли?)
С какой стати утруждаться созданием небрежной компиляции, которая, вероятно, позволяет пропустить многие виды ошибок? Потому что первое, что вы делаете после компиляции, — запускаете очень быстрый тест в поисках самых глупых ошибок — которые встречаются часто, даже если их легко исправить. Затем вы исправляете их — и (стон) перекомпилируете. Значительная часть времени программиста уходит на скучную работу по исправлению ошибочных утверждений (т. е. ложных предупреждений) и очевидных глупых опечаток. Они часто всплывают сразу же, практически без тестирования. Таким образом, гораздо более быстрая, но менее эффективная предварительная компиляция в большинстве случаев была бы достаточно хороша, чтобы указать на такие ревущие; таким образом позволяя программистам выполнять большую часть своей рутинной работы, в то время как компиляция реальной задницы уныло продолжается. Вы используете крайне ненадежный исполняемый файл, но это лучше, чем заставлять программистов пялиться в стены (если только им это не нужно) или переключаться на другую задачу.
Когда глупые ошибки будут сглажены, просто запустите еще одну длинную компиляцию. Тот, который будет иметь больше шансов быть полезным, и вы сможете ускорить его продвижение.
Можно сказать, что мы проанализировали задачу компиляции и разбили ее на две отдельные задачи: 1) создание исполняемого файла, достаточно точного, чтобы указывать на действительно глупые очевидные ошибки, и 2) совершенно другая задача компиляции точно и с достаточной строгостью. для создания исполняемых файлов, которые вы, возможно, захотите запустить в производство. Задача 1) не требует долгой и точной компиляции, но является наиболее частой задачей. Так что это заслуживает отдельного внимания.
Конечно, проблема в том, что когда вы нажимаете «компилировать», вы не знаете, какой тип компиляции должен произойти — может быть, это компиляция с опечатками или глупыми ошибками, которую не стоит тщательно тестировать, но опять же , может быть, после быстрого теста он выглядит довольно хорошо и заслуживает каждой проверки, которую может сделать компилятор, и дальнейшей работы или стресс-тестирования после этого. Поскольку мы не знаем, какой тип компиляции мы делаем в любой момент времени, давайте сделаем оба. Если есть глупые ошибки, мы сэкономим время и дадим высокооплачиваемым (и быстро надоедающим) программистам чем-то заняться, пока идет тщательная, настоящая компиляция.
Да, это неприятный компромисс. Нет вопросов. Это то, что я называю «гибридным решением». Это и А, и Б; или часть А и часть В; иногда А, а иногда Б — и такие запутанные решения часто упускают из виду. Мы все предпочли бы мыслить дихотомиями: А ИЛИ Б. Мы все предпочли бы иметь один правильный ответ. Но иногда, если мы рассматриваем только эти более простые ответы, мы оставляем позади некоторые очень полезные, достаточно хорошие решения.
Почти по определению гибридные решения не идеальны; они не выполняют работу так, как вам действительно хотелось бы. Но, тем не менее, они могут быть лучшим доступным решением.
Эта стратегия основана на степенных законах — компилируйте, выполняя только 20 % проверок, которые чаще всего терпят неудачу, и вы, вероятно, получите программу, которая работает достаточно хорошо, чтобы выявить 80 % ошибок кода — все самые глупые из них. Конечно, это не самые опасные или важные ошибки, но кого это волнует, потому что вы можете исправить их в то время, когда в противном случае вы ждали бы эту долгую компиляцию.
Этот подход может особенно хорошо сработать для самых зеленых программистов на Rust, снижая уровень их разочарования. Возможно, его придется адаптировать для опытных программистов на Rust, которые терпят неудачу по разным причинам.
Мы могли бы даже с пользой для дела разбить компиляцию на 3 одновременных компиляции: одна занимает от 10 до 20 процентов времени правильной компиляции, другая занимает половину времени, а третья занимает все время. компиляция "время-это-делает". Если применяются степенные законы, компиляция в половину времени обычно помечает каждую проблему, которая была бы у полной компиляции, а также (обычно) не ломается, когда ее отпускают на тестовых данных, чего не было бы при полной компиляции.
Здесь может помочь изменить последовательность событий внутри компилятора Rust, чтобы сдвинуть к концу наименее вероятные и наиболее трудоемкие проверки/задачи, но это следует учитывать более квалифицированным людям.
