Почему стоит выбрать Rust в качестве следующего языка программирования

Перевод | Автор оригинала: Ryan Levick

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

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

Я участвовал во многих дискуссиях о выборе языка программирования, и они обычно заканчиваются одним из двух способов: либо решение принимается с использованием измеримых, но неважных критериев, при игнорировании релевантных, но трудно измеримых критериев; или это сделано с использованием анекдотов и эмоциональных призывов.

Был один процесс выбора языка, в котором я участвовал, и который прошел - по крайней мере, до сих пор - довольно гладко: растущее внимание внутри Microsoft к использованию Rust.

В этой статье мы рассмотрим несколько вопросов, связанных с выбором языка программирования в целом и Rust в частности. Вот они: Какие критерии обычно используются для выбора языка программирования, особенно в крупных компаниях, и почему этот процесс редко заканчивается успешно? Почему рассмотрение Rust в Microsoft до сих пор прошло гладко, и можно ли из этого почерпнуть некоторые общие рекомендации?

Критерии выбора языка

Существует множество критериев для принятия решения о переходе на новый язык программирования. В целом, критерии, которые легче всего измерить, - это те, о которых чаще всего говорят, даже если они менее важны, чем другие, более трудные для измерения критерии.

Технические критерии

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

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

Хотя некоторые технические преимущества (например, производительность) можно измерить относительно легко, другие измерить гораздо сложнее. Например, каковы относительные достоинства системы динамической типизации (например, в Python) перед относительно многословной и малофункциональной системой (например, Java) и как это меняется по сравнению с системами с более сильной типизацией, такими как Scala или Haskell? Многие люди интуитивно считают, что к таким техническим различиям следует относиться очень серьезно при рассмотрении языка, но это не лучший способ их измерить.

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

Организационные критерии

Организационные критерии, которые являются вторым соображением, включают:

• Насколько легко будет нанять разработчиков, говорящих на этом языке?
• Насколько легко обеспечить соблюдение стандартов программирования?
• Как быстро в среднем разработчики смогут выпускать программное обеспечение?

Затраты и преимущества организационных критериев трудно измерить. У людей обычно есть расплывчатые, «интуитивные» ответы на них, которые создают твердое мнение по этому поводу. К сожалению, измерить эти критерии зачастую очень сложно. Например, для большинства может быть очевидно, что TypeScript позволяет программистам доставлять клиентам работающее, относительно свободное от ошибок программное обеспечение быстрее, чем это делает C, но где данные для подтверждения этого?

Более того, этим критериям часто бывает крайне сложно присвоить весовой коэффициент важности. Легко видеть, что Go обеспечивает соблюдение стандартизированных методов кодирования легче, чем Scala (из-за широкого использования gofmt), но чрезвычайно сложно измерить конкретные преимущества для компании от стандартизации кодовых баз.

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

Эмоциональные критерии

В-третьих, эмоциональные критерии, которые, как правило, игнорируются, если не полностью игнорируются.

Программирование программного обеспечения традиционно пыталось подражать более истинным «инженерным» методам, в которых технические соображения, как правило, являются наиболее важными. Некоторые утверждают, что языки программирования - это «просто инструменты», и их следует оценивать только по техническим критериям. Другие утверждают, что языки программирования помогают программисту в некоторых из наиболее художественных аспектов работы. Эти критерии чрезвычайно трудно измерить сколько-нибудь значимым образом.

В общем, все сводится к тому, насколько счастливы (а значит, продуктивны) программисты, используя этот язык. Такие соображения могут иметь реальное влияние на программистов, но практически невозможно измерить, как это влияет на выгоду для всей команды.

Из-за сложности количественной оценки этих критериев это часто игнорируется. Но означает ли это, что эмоциональные аспекты языков программирования не оказывают существенного влияния на программистов или программистские организации?

Неизвестные критерии

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

Эти критерии могут быть техническими (например, преимущества классов данных Kotlin перед конструкциями Java), организационными (например, насколько полезны сообщения об ошибках Elm для обучения новичков в этом языке) или эмоциональными (например, то, как Ruby заставляет программиста чувствовать себя при его написании).

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

Почему Rust?

Это возвращает нас к растущему интересу к Rust в Microsoft. Я считаю, что дискуссии о внедрении Rust пока проходят относительно гладко, потому что Rust предлагает чрезвычайно четкое и убедительное преимущество - не только по сравнению с языком, который он пытается заменить (C++), но и по сравнению с любым другим языком, практически доступным для отрасли: отличная производительность, высокий уровень контроля и безопасность памяти.

Решение Microsoft исследовать Rust (и другие языки) было принято из-за того, что примерно 70% общих уязвимостей и уязвимостей (CVE) в продуктах Microsoft были связаны с проблемами безопасности памяти в C и C++. Когда было обнаружено, что большая часть затронутых кодовых баз не может быть эффективно переписана на C# из-за проблем с производительностью, начался поиск. Rust рассматривался как единственный возможный кандидат на замену C++. Он был достаточно похож, так что не все пришлось переделывать, но у него есть отличительная трэйта, которая делает его заметно лучше, чем текущая альтернатива: возможность устранить почти 70% наиболее серьезных уязвимостей безопасности Microsoft.

Есть и другие причины, помимо безопасности памяти, производительности и контроля, которые делают Rust привлекательным (например, строгие гарантии безопасности типов, чрезвычайно любимый язык и т.д.), Но, как и ожидалось, о них было трудно говорить, потому что их трудно было измерить. В целом, большинство людей, участвовавших в процессе выбора, больше интересовались проверкой того, что эти другие аспекты языка не были ощутимо хуже, чем C++, но, поскольку измерение этих аспектов было настолько трудным, они не считались активными причинами для принятия языка. .

Однако команды Microsoft, которые уже внедрили Rust, например, для IoT Edge Security Daemon, рекламировали другие аспекты языка (в частности, «правильность» из-за продвинутой системы типов) как причины, по которым они больше всего хотели вкладывать больше средств в язык. . Эти команды не могли предоставить надежные измерения для этих критериев, но у них явно развилось интуиция, что этот аспект языка чрезвычайно важен.

При работе с Rust в Microsoft основным критерием оценки оказалась легко измеримая. Но что происходит, когда самые важные проблемы организации трудно измерить? Эти вопросы не менее важны только потому, что в настоящее время их трудно измерить.

Что теперь?

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

По этому вопросу было проведено некоторое исследование, но пока не получено ничего, что широко применялось бы в промышленности. Хотя аргументы в пользу Rust были относительно ясны внутри Microsoft, это не означает, что новые языки следует принимать только тогда, когда для этого есть одна четкая техническая причина. Мы должны научиться лучше оценивать больше аспектов языков программирования, помимо традиционных (таких как производительность).

Путь к внедрению Rust в Microsoft только начинается, и наличие только одной причины для оправдания инвестиций в Rust определенно не идеально. В то время как мы начинаем формировать коллективные анекдотические свидетельства, подтверждающие дальнейшее внедрение Rust, определенно необходимо лучше количественно оценить это понимание и иметь возможность говорить о нем в более объективных терминах.

Мы все еще не совсем уверены, как это сделать, но следите за новостями, пока мы пойдем по этому пути.