Architecture Decision Recordプログラミング言語
目次:
概要
課題
ソフトウェアのためのプログラミング言語を選択する必要があります。主なニーズは 2 つあります: Web アプリケーションに適したフロントエンドのプログラミング言語と、サーバーアプリケーションに適したバックエンドのプログラミング言語です。
決定
フロントエンドには 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: システム管理で最も人気のある言語。優れた分析ツール。良い Web フレームワーク。しかし、Google には Go を優先して見放された。
Ruby: 史上最高の開発者体験。最高の Web フレームワーク。最も優しいコミュニティ。しかし非常に遅い。パッケージ化がやや難しい。
Rust: 最良の新しい言語。ゼロ抽象化を重視。並行処理を重視。しかし、比較的小さなエコシステム。また、一部の種類のコンパイラ最適化に意図的な制限がある。たとえば直接メモリアクセスは明示的に unsafe にする必要がある。
TypeScript: JavaScript に型を追加。優れたトランスパイラー。JavaScript から TypeScript への移植を重視する開発者の増加。Microsoft による強力な支援。
VM には、実行時の機能を提供する追加の複雑さなど、今は必要ないトレードオフがあると判断しました。
私たちの中核となる決定は、2 つの横断的な懸念によって推進されていると考えています:
最速の実行速度と最も緊密なシステムアクセスのためには、JavaScript と C を選ぶでしょう。
最速に近い実行速度と最も緊密に近いシステムアクセスのためには、TypeScript と Rust を選びます。
VM 言語が欲しい場合に選ぶであろう、VM 言語と Web フレームワークに名誉ある言及を贈ります:
Clojure と Luminus
Java と Spring
Elixir と Phoenix
影響
フロントエンド開発者は TypeScript を学ぶ必要があります。開発者の主な経験が JavaScript の使用である場合、おそらく学習曲線は容易です。
バックエンド開発者は Rust を学ぶ必要があります。開発者の主な経験が C/C++ の使用である場合は中程度の学習曲線で、Java、Python、Ruby、または同様のメモリ管理言語の使用である場合は困難な学習曲線になる可能性が高いです。
TypeScript と Rust はどちらも比較的新しいです。つまり、多くのツールにはまだこれらの言語の文書がありません。たとえば、devops パイプラインをこれらの言語用に設定する必要がありますが、今のところ、評価している devops ツールのいずれにも、これらの言語のデフォルトの例はありません。
TypeScript と Rust のコンパイル時間はかなり遅いです。これは、言語が新しいことによる部分もあるかもしれません。オンデマンドコンパイル、コンパイルの並行処理など、遅いコンパイル時間を軽減する方法を検討する必要があるかもしれません。
これらの言語に対する IDE のサポートは、まだ遍在しておらず、まだ第一級ではありません。たとえば、JetBrains は Python 用に第一級のサポートを持つ PyCharm IDE を販売していますが、Rust に第一級のサポートを持つ IDE は販売していません。代わりに、JetBrains は Python 言語サポートに対しておそらく 80% の Rust 言語サポートを提供する Rust プラグインを使用できます。
関連
関連する決定
これらの言語に沿ったエコシステムの選択を目指します。
たとえば、これらの言語に対して優れた機能を持つ IDE を選択したい。
たとえば、フロントエンドの Web フレームワークについては、素の JavaScript を目指す傾向のあるフレームワーク(例: React)よりも、TypeScript を目指す傾向のあるフレームワーク(例: Vue)に決める可能性の方が高い。
関連する要件
ツールチェーン全体がこれらの言語をサポートしなければなりません。
関連する成果物
一部のシークレットを環境変数にエクスポートする可能性があります。
関連する原則
二度測って一度作る。速度よりも一定の安全性を優先しています。
実行時間はコンパイル時間よりも価値がある。開発者の利用よりも顧客の利用を優先しています。
メモ
ここにメモを記入。