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의 강력한 후원.
우리는 VM에 당장은 필요하지 않은 일련의 트레이드오프, 예를 들어 런타임 기능을 제공하는 추가적인 복잡성이 있다고 판단했습니다.
우리의 핵심 결정은 두 가지 횡단 관심사에 의해 좌우된다고 믿습니다:
가장 빠른 런타임 속도와 가장 긴밀한 시스템 접근을 위해서는 JavaScript와 C를 선택할 것입니다.
거의 가장 빠른 런타임 속도와 거의 가장 긴밀한 시스템 접근을 위해서는 TypeScript와 Rust를 선택합니다.
VM 언어를 원한다면 선택했을 VM 언어와 웹 프레임워크에 대한 언급도 있습니다:
Clojure와 Luminus
Java와 Spring
Elixir와 Phoenix
영향
프런트엔드 개발자는 TypeScript를 배워야 합니다. 개발자의 주된 경험이 JavaScript 사용이라면 이는 아마 쉬운 학습 곡선일 것입니다.
백엔드 개발자는 Rust를 배워야 합니다. 개발자의 주된 경험이 C/C++ 사용이라면 이는 아마 중간 정도의 학습 곡선이고, Java, Python, Ruby 또는 유사한 메모리 관리 언어 사용이라면 어려운 학습 곡선일 것입니다.
TypeScript와 Rust는 둘 다 비교적 새롭습니다. 이는 많은 도구가 아직 이 언어들에 대한 문서를 갖고 있지 않다는 뜻입니다. 예를 들어 데브옵스 파이프라인을 이 언어들에 맞게 설정해야 하는데, 우리가 평가 중인 데브옵스 도구 중 어느 것도 아직 이 언어들에 대한 기본 예제가 없습니다.
TypeScript와 Rust의 컴파일 시간은 상당히 느립니다. 이는 일부 언어가 새롭기 때문일 수 있습니다. 온디맨드 컴파일, 컴파일 동시성 등으로 느린 컴파일 시간을 완화하는 방법을 살펴볼 수 있습니다.
이 언어들에 대한 IDE 지원은 아직 보편적이지 않고 일급이 아닙니다. 예를 들어 JetBrains는 Python에 대한 일급 지원을 위해 PyCharm IDE를 판매하지만 Rust에 대한 일급 지원을 갖춘 IDE는 판매하지 않습니다. 대신 JetBrains는 Python 언어 지원에 비해 Rust 언어 지원의 약 80%를 제공하는 Rust 플러그인을 사용할 수 있습니다.
관련 항목
관련 결정
이 언어들과 부합하는 생태계 선택을 지향할 것입니다.
예를 들어 이 언어들에 대한 좋은 기능을 가진 IDE를 선택하고자 합니다.
예를 들어 프런트엔드 웹 프레임워크로는 순수 JavaScript를 지향하는 프레임워크(예: React)보다 TypeScript를 지향하는 프레임워크(예: Vue)로 결정할 가능성이 더 높습니다.
관련 요구사항
전체 도구 체인이 이 언어들을 지원해야 합니다.
관련 산출물
일부 비밀 정보를 환경 변수로 내보낼 수 있을 것으로 예상합니다.
관련 원칙
두 번 재고 한 번 만들기. 우리는 일부 속도보다 일부 안전성을 우선합니다.
런타임은 컴파일 타임보다 더 가치가 있습니다. 우리는 개발자 사용보다 고객 사용을 우선합니다.
메모
여기에 메모를 적으십시오.