Architecture Decision Record
← Приклади записів рішень

Мови програмування

Зміст:

Підсумок

Проблема

Нам потрібно обрати мови програмування для нашого програмного забезпечення. Ми маємо дві основні потреби: мову програмування для клієнтської частини, придатну для вебзастосунків, і мову програмування для серверної частини, придатну для серверних застосунків.

Рішення

Для клієнтської частини ми обираємо TypeScript.

Для серверної частини ми обираємо Rust.

Статус

Ухвалено. Ми відкриті до нових альтернатив, коли вони з’являтимуться.

Подробиці

Припущення

Клієнтські застосунки типові:

  • Типові користувачі та взаємодії

  • Типові браузери та системи

  • Типові розробки та розгортання

Клієнтські застосунки, імовірно, швидко еволюціонуватимуть:

  • Ми хочемо забезпечити швидку й легку розробку, розгортання, ітерації тощо.

  • Ми цінуємо доказовість, як-от типобезпека, і нас влаштовує трохи більше роботи для її досягнення.

  • Нам не потрібна сумісність зі застарілими системами.

Серверні застосунки мають вищі, ніж типові, вимоги:

  • Вищі, ніж типові, цілі щодо якості, особливо доказовості, надійності, безпеки тощо.

  • Вищі, ніж типові, цілі щодо роботи майже в реальному часі, тобто ми не хочемо пауз через збирання сміття віртуальною машиною.

  • Вищі, ніж типові, цілі щодо функціонального програмування, особливо для розпаралелювання, багатоядерної обробки та безпеки пам’яті.

Ми приймаємо нижчу швидкість компіляції на користь безпеки під час компіляції та швидкості виконання.

Обмеження

Ми маємо сильне обмеження щодо мов, придатних для використання з послугами основних хмарних провайдерів для функцій, як-от Amazon Lambda.

Позиції

Ми розглядали такі мови:

  • C

  • C++

  • Clojure

  • Elixir

  • Erlang

  • Elm

  • Flow

  • Go

  • Haskell

  • Java

  • JavaScript

  • Kotlin

  • Python

  • Ruby

  • Rust

  • TypeScript

Аргумент

Підсумок за кожною мовою:

  • C: відхилено через низьку безпеку; Rust може майже все робити краще.

  • C++: відхилено, бо це безлад; Rust може майже все робити краще.

  • Clojure: чудове моделювання; найкраще наближення до Lisp; чудове середовище виконання на JVM.

  • Elixir: чудове середовище виконання, зокрема розгортаність і паралелізм; чудовий досвід розробника; відносно невелика екосистема.

  • Erlang: чудове середовище виконання, зокрема розгортаність і паралелізм; складний досвід розробника; відносно невелика екосистема.

  • Elm: виглядає дуже багатообіцяюче; IBM публікує великі кейси з хорошими результатами; менша екосистема.

  • Flow: цікаве вдосконалення порівняно з JavaScript; проте розробники відходять від нього.

  • Go: чудовий досвід розробника; чудовий паралелізм; але послужний список поганих рішень, що калічать мову.

  • Haskell: найкраща функціональна мова; менша спільнота розробників; не досягла достатньо опублікованих успіхів у промисловій експлуатації.

  • Java: чудове середовище виконання; чудова екосистема; посередній досвід розробника.

  • JavaScript: найпопулярніша мова за всю історію; найпоширеніша екосистема.

  • Kotlin: виправляє так багато в Java; чудова підтримка від JetBrains; хороші опубліковані випадки перенесення з Java на Kotlin.

  • Python: найпопулярніша мова для системного адміністрування; чудові інструменти аналітики; хороші вебфреймворки; але покинута Google на користь Go.

  • Ruby: найкращий досвід розробника за всю історію; найкращі вебфреймворки; наймиліша спільнота; але дуже повільна; дещо важко пакувати.

  • Rust: найкраща нова мова; акцент на нульовій вартості абстракцій; акцент на паралелізмі; проте відносно невелика екосистема; і має навмисні обмеження на деякі види прискорень компілятора, напр. прямий доступ до пам’яті має бути явно небезпечним (unsafe).

  • TypeScript: додає типи до JavaScript; чудовий транспілятор; зростаючий акцент розробників на перенесенні з JavaScript на TypeScript; сильна підтримка від Microsoft.

Ми вирішили, що віртуальні машини мають набір компромісів, які нам зараз не потрібні, як-от додаткова складність, що забезпечує можливості часу виконання.

Ми вважаємо, що наше основне рішення зумовлене двома наскрізними міркуваннями:

  • Для найшвидшої швидкості виконання та найтіснішого доступу до системи ми обрали б JavaScript і C.

  • Для майже найшвидшої швидкості виконання та майже найтіснішого доступу до системи ми обираємо TypeScript і Rust.

Почесні згадки отримують мови для віртуальних машин та вебфреймворки, які ми обрали б, якби хотіли мову для віртуальної машини:

  • Clojure і Luminus

  • Java і Spring

  • Elixir і Phoenix

Наслідки

Розробникам клієнтської частини потрібно буде вивчити TypeScript. Це, імовірно, легка крива навчання, якщо основний досвід розробника — використання JavaScript.

Розробникам серверної частини потрібно буде вивчити Rust. Це, імовірно, помірна крива навчання, якщо основний досвід розробника — використання C/C++, і складна крива навчання, якщо основний досвід розробника — використання Java, Python, Ruby чи подібних мов із керованою пам’яттю.

TypeScript і Rust обидві відносно нові. Це означає, що для багатьох інструментів ще немає документації для цих мов. Наприклад, конвеєр DevOps потрібно буде налаштувати для цих мов, і поки що жоден з інструментів DevOps, які ми оцінюємо, не має типових прикладів для цих мов.

Час компіляції для TypeScript і Rust досить великий. Частково це може бути пов’язано з новизною мов. Можливо, нам варто подивитися, як пом’якшити повільну компіляцію, наприклад компіляцією на вимогу, паралельною компіляцією тощо.

Підтримка IDE для цих мов ще не повсюдна і ще не першокласна. Наприклад, JetBrains продає IDE PyCharm із першокласною підтримкою Python, але не продає IDE з першокласною підтримкою Rust; натомість JetBrains може використовувати плагін для Rust, який забезпечує, можливо, 80 % підтримки мови Rust порівняно з підтримкою мови Python.

Пов’язане

Пов’язані рішення

Ми прагнутимемо до вибору екосистеми, що узгоджується з цими мовами.

Наприклад, ми хочемо обрати IDE з добрими можливостями для цих мов.

Наприклад, для нашого клієнтського вебфреймворку ми з більшою ймовірністю оберемо фреймворк, що схиляється до TypeScript (напр., Vue), ніж фреймворк, що схиляється до простого JavaScript (напр., React).

Пов’язані вимоги

Увесь наш набір інструментів має підтримувати ці мови.

Пов’язані артефакти

Ми очікуємо, що можемо експортувати деякі секрети у змінні середовища.

Пов’язані принципи

Сім разів відміряй, один раз відріж. Ми надаємо пріоритет певній безпеці над певною швидкістю.

Час виконання цінніший за час компіляції. Ми надаємо пріоритет використанню клієнтами над використанням розробниками.

Примітки

Будь-які примітки тут.