나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2025-09-22 13:34:14

Rust(프로그래밍 언어)


[[프로그래밍 언어|'''프로그래밍 언어
{{{#!wiki style="font-family: Times New Roman, serif; display: inline;"
]]
{{{#!wiki style="min-height: calc(1.5em + 5px); margin: 0 -10px -5px"
{{{#!wiki style="display: inline-table; min-width: 40%; min-height: calc(1.5em + 5px)"
{{{#!folding [ 목록 ]
{{{#!wiki style="margin: -5px -1px"
<colbgcolor=royalblue><colcolor=#fff> ※ 나무위키에 등재된 프로그래밍 언어 목록
AActionScript · AdaT · AgdaTP · ALGOLT · ApexT · APL · awk · AssemblyT
BBASIC
C파일:C언어 로고.svg CT · 파일:C C#T · 파일:C++ 로고.svg C++T · CarbonT · 파일:clojure_logo.png ClojureS · COBOLT · CoffeeScript · Common LispS · CrystalT
D파일:external/upload.wikimedia.org/D_programming_language_logo.png DT · 파일:Dart 심볼.svg DartT
EElixir · 파일:Elm_logo.svg.png elmT · Erlang
F파일:fsharp-logo.png F#T · Factor · 파일:fennel-logo.svg FennelS · 파일:forth.png Forth · FortranT
GGNU Octave · 파일:Go 로고.svg GoT · Groovy
H파일:Haskell 로고 심볼.svg HaskellT · HolyCT
I
J파일:Java 로고.svg JavaT · 파일:JavaScript 로고.svg JavaScript · 파일:julia-dots.svg Julia
K파일:Kotlin 심볼.svg KotlinT · Krait
LLeanTP · 파일:LISP_logo.svg LISPS · 파일:Lua 로고.svg Lua
MMATLAB · MaxV · MojoT · Moonlight
N파일:Nim 왕관 로고.svg NimT · 파일:Nix 로고.svg Nix
OOberonT · Objective-CT · 파일:ocaml.svg OCamlT
PPascalT · Perl · 파일:PHP 로고.svg PHP · Processing · Prolog · 파일:Python 심볼.svg Python
QQ#T
R파일:R 로고.svg R · 파일:racket-logo.svg RacketS · Raku · ReasonMLT · RocqTP · 파일:Ruby 로고.svg Ruby · 파일:Rust 로고.svg파일:Rust 로고 화이트.svg RustT
SSAS · 파일:Scala 로고.png ScalaT · SchemeS · 파일:스크래치(교육 플랫폼) 로고.svg ScratchV · sed · Shell Script · Smalltalk · 파일:Swift 심볼 배경.svg SwiftT
T파일:Typescript_logo_2020.svg TypeScriptT
UUdon
VVisual Basic · Visual Basic .NET · Visual Basic for Applications · vvvvV
WWave
XXSharp
Y
ZZenScript · 파일:Zig 로고마크.svg ZigT
한글누리 · V · 씨앗 · 약속 · 파일:엔트리 아이콘.svg 엔트리V · 창조
T: 정적 타입 프로그래밍 언어 · P: 증명 보조 언어 · S: LISP 방언 및 S-표현식 기반 언어 · V: 시각적 프로그래밍 언어 }}}}}}}}}{{{#!wiki style="display: inline-table; min-width: 40%; min-height: calc(1.5em + 5px)"
{{{#!folding [ 순위 ]
{{{#!wiki style="margin: -5px -1px -10px"
{{{#!wiki style="min-height: calc(1.5em + 5px); margin: 0 -10px -5px"
{{{#!wiki style="display: inline-table; min-width: 25%; min-height: calc(1.5em + 5px)"
{{{#!folding [ IEEE Spectrum 2024 ]
{{{#!wiki style="margin: -5px -1px"
<tablewidth=100%><tablebgcolor=transparent><colbgcolor=#11a500><colcolor=#fff> 스펙트럼 부문 상위 10개 프로그래밍 언어 <colbgcolor=#ff1100><colcolor=#fff> 직업 부문 상위 10개 프로그래밍 언어
1 Python 1 SQL
2 Java 2 Python
3 JavaScript 3 Java
4 C++ 4 TypeScript
5 TypeScript 5 SAS
6 SQL 6 JavaScript
7 C# 7 C#
8 Go 8 HTML
9 C 9 Shell
10 HTML 10 C++ }}}}}}}}}{{{#!wiki style="display: inline-table; min-width: 25%; min-height: calc(1.5em + 5px)"
{{{#!folding [ Stack Overflow 2024 ]
{{{#!wiki style="margin: -5px -1px"
<colbgcolor=#ffa500><colcolor=#fff> 2024년 Stackoverflow 설문조사 상위 25개 프로그래밍 언어
1 JavaScript <colbgcolor=#ffa500><colcolor=#fff> 14 Rust
2 HTML & CSS 15 Kotlin
3 Python 16 Lua
4 SQL 17 Dart
5 TypeScript 18 어셈블리어
6 Bash 19 Ruby
7 Java 20 Swift
8 C# 21 R
9 C++ 22 Visual Basic
10 C 23 MATLAB
11 PHP 24 VBA
12 PowerShell 25 Groovy
13 Go }}}}}}}}}{{{#!wiki style="display: inline-table; min-width: 25%; min-height: calc(1.5em + 5px)"
{{{#!folding [ TIOBE 2025 ]
{{{#!wiki style="margin: -5px -1px"
<colbgcolor=#2777c2><colcolor=#fff> 2025년 4월 TIOBE 검색어 점유율 상위 20개 프로그래밍 언어
1 Python <colbgcolor=#2777c2><colcolor=#fff> 11 Fortran
2 C++ 12 Scratch
3 C 13 PHP
4 Java 14 R
5 C# 15 Ada
6 JavaScript 16 MATLAB
7 Go 17 Assembly language
8 Visual Basic 18 Rust
9 Delphi / Object Pascal 19 Perl
10 SQL 20 COBOL }}}}}}}}}{{{#!wiki style="display: inline-table; min-width: 25%; min-height: calc(1.5em + 5px)"
{{{#!folding [ PYPL 2025 ]
{{{#!wiki style="margin: -5px -1px -10px"
<colbgcolor=green><colcolor=#fff> 2025년 5월 PYPL 검색어 점유율 상위 20개 프로그래밍 언어
1 Python <colbgcolor=green><colcolor=#fff> 11 Swift
2 Java 12 Go
3 JavaScript 13 Kotlin
4 C/C++ 14 MATLAB
5 C# 15 Ada
6 R 16 Ruby
7 PHP 17 Dart
8 Rust 18 Lua
9 TypeScript 19 VBA
10 Objective-C 20 PowerShell }}}}}}}}}}}} }}}}}}}}}}}}
실행 방식 · 분류 · 언어 목록(분류:프로그래밍 언어 문법) · 언어별 예제 · 틀:프로그래밍 언어 문법 · 틀:난해한 프로그래밍 언어
<colcolor=#1f2023,#fff> 러스트
Rust
파일:Rust 로고.svg파일:Rust 로고 화이트.svg
최초 개발자 그레이던 호어
개발 모질라 재단러스트 재단
최초 출시 2012년 1월 20일 ([age(2012-01-20)]년 전)
최초 안정 버전 출시 2015년 5월 15일 ([age(2015-05-15)]년 전)
안정 버전 1.90.0 (2025년 9월 18일)
라이선스 아파치 라이선스, MIT 라이선스#
파일:홈페이지 아이콘.svg | 파일:GitHub 아이콘.svg파일:GitHub 아이콘 화이트.svg | 파일:cargo.rs.png | 파일:디스코드 아이콘.svg | 파일:레딧 아이콘.svg

1. 개요2. 역사3. 언어의 특징
3.1. 안전한 메모리 관리
3.1.1. 소유권과 수명3.1.2. 가변성
3.2. 철저한 에러 관리3.3. 편리한 열거형3.4. 트레이트
3.4.1. 특수한 트레이트
3.5. 위생(하이지닉) 매크로3.6. 비동기 프로그래밍3.7. 제네릭
4. 개발 도구별 특징
4.1. 안전하고 강력한 컴파일러4.2. 강력한 툴체인4.3. 여러 IDE의 지원
5. 주목받고 있는 언어
5.1. 개발자들이 가장 좋아하는 언어5.2. 대기업에 주목받고 있는 언어5.3. 운영 체제 개발 언어
6. 사용 현황 및 전망
6.1. 전망6.2. 기존 언어와의 비교
6.2.1. Rust vs. C++
6.2.1.1. 결론
6.2.2. Rust vs. Zig6.2.3. Rust vs. Carbon
6.3. 사용 현황
6.3.1. Rust를 사용하는 기업 및 단체6.3.2. Rust로 제작된 것들
7. 비판8. 학습 자료
8.1. 도서
8.1.1. The book8.1.2. 그 외
8.2. 유튜브8.3. 웹 사이트
9. 기타10. 관련 링크


1. 개요


#!syntax rust
fn main() {
    println!("Hello, world!");
}


러스트 재단에서 개발되고 있는 메모리 안전성성능 및 편의성에 중점을 둔 프로그래밍 언어이다. 가비지 컬렉터 없이 메모리 안전성을 제공하는 대표적인 언어다. C++의 대체재로서 등장했다.

2. 역사

자세한 내용은 Github의 rust-lang/rust 릴리스 참고.

개발 초기에는 OCaml로 컴파일러가 제작되었다. 이후 언어가 발전함에 따라 컴파일러는 Rust 자체로 재작성되었다.

2015년 5월 15일에 첫 안정 버전인 1.0 버전이 출시되었다.

2018년 12월 6일에 발표된 1.31.0 버전을 기점으로 Rust 2018 Edition으로 에디션이 변경되고 1.31.0 이전 버전은 Rust 2015 Edition으로 정의됐다.

1.56.0 이후 버전은 Rust 2021 Edition이 적용됐다.

1.85.0 이후 버전은 Rust 2024 Edition이 적용된다. (가이드북)

원래는 2006년에 모질라 소속의 개발자인 그레이던 호어의 개인 프로젝트였으나, 모질라 재단의 차기 웹 브라우저 엔진 프로젝트인 Servo를 개발하는 데에 쓰기 위해 2009년부터 함께 연구 프로젝트로 편입됐다.[1] 자세한 내용은 Servo 참고.

2021년 2월부터는 러스트 재단으로 분리되어 AWS, Google, 화웨이, MS, 모질라 재단을 초기 회원사로 발족했다.

Go보다는 3년 늦게 나왔지만[2] 그나마 비슷한 시기에 등장했다는 점과 두 언어 모두 C/C++를 서로 다른 방향에서 대체하려 한다는 점 때문에 라이벌 관계로 엮이기도 한다.

3. 언어의 특징

현대적인 시스템 프로그래밍 언어로 C/C++와 동등한 수준의 속도를 유지하면서 안전성과 동시성을 향상시키는 것을 목표로 설계되었다. 그래서 '안전한 코드'에서는 포인터 역참조와 같이 메모리 관리 실수를 범하기 쉬운 일부 기능들의 사용을 제한한다. 모든 변수는 RAII[3]가 강제되며, 컴파일러는 모든 변수의 수명과 참조자의 유효성을 검증한다.

함수형 프로그래밍 언어로부터 발전된 타입 시스템을 도입했으며, 객체 상속 대신 다른 언어에서의 인터페이스와 비슷한 트레이트라는 개념을 기반으로 다형성을 달성한다.[4] 타입이 강제되는 매크로를 사용해 언어를 확장하는 것이 가능하며, 현대적인 모듈 시스템을 통해 쉽게 모듈화될 수 있다.

null 포인터 에러가 언어 차원에서 존재하지 않는다. 필요한 경우에는 Option<T>이라는 제네릭 열거형에 감싸서 사용한다. 그리고 matchif let를 사용하는 패턴 매칭을 통해 가능한 경우들에 대해 개발자가 적절한 제어를 하도록 유도한다. 이렇게 존재가 애매모호한 상태를 언어 설계 차원에서 피하여 개발자가 실수할 가능성을 상당히 줄였다. 타입의 모호함도 방지하기 위함인지 ++--와 같은 전/후위 연산자가 존재하지 않는다.

-C overflow-checks, 또는 디버그 모드와 같은 컴파일러 설정에 따라 integer overflow와 같은 버그도 런타임에 검증할 수 있다. 흔히 오해하는 바와 다르게 Rust의 integer overflow는 UB(undefined behavior)도 아니고 허용되는 동작이며, 통상적인 2의 보수 오버플로 동작으로 반드시 정의된다(specified).## 이로 인해 정수 연산의 가환성 보장을 이용한 C 수준의 최적화는 불가능해지나,# 그만큼 런타임에서도 안전성을 챙길 수 있다. 오버플로가 허용되는 것과 별개로 권장되지 않는 동작인 것은 여전하기에# 표준 라이브러리checked_add, overflowing_add와 같은 함수를 사용해 검증을 항상 강제할 수도 있다.

이 언어를 대표하는 키워드 몇 개를 나열해 보면 안전성, 속도, 병렬 프로그래밍, 함수형 프로그래밍, 시스템 프로그래밍이 있다.

3.1. 안전한 메모리 관리

Rust는 메모리 관리의 안전성이 상당히 고려된 언어이다.[5] 무분별한 참조를 막는 제약이 있고 오버헤드가 없는, 안전한 메모리 관리를 위해 후술할 소유권(ownership)과 수명(lifetime)이라는 다른 언어에는 없는 생소한 개념을 이용해 컴파일 단계에서 borrow checker를 통해 메모리 안전성을 검증한다.

Rust는 시스템 프로그래밍 언어로서 무비용 추상화(zero-cost abstraction)를 지향하기 때문에 별도의 쓰레기 수집을 사용하지 않는다.[6] 그리고 C/C++와 마찬가지로 시스템에서 메모리를 직접 할당받아 사용하는 것이 기본이다.[7] 안전한 코드에서는 포인터를 역참조하여 직접 값을 가져오거나 함수를 호출하는 것이 금지된다. unsafe 스코프에서는 허용되지만 이를 통해 달성하고자 하는 목적과 이점이 확실해야 한다. 예를 들면 (기존 라이브러리를) 안전한 코드로 래핑하거나 하드웨어를 직접 다루는 경우 등이 있다.

포인터 접근에 필요한 산술 연산에서 integer overflow가 발생하게 되면 undefined behavior가 유발되고 보안 취약점으로 이어진다. 릴리즈 모드 등 컴파일러 설정에 따라 이 같은 오류를 런타임에 검증하지 않을 수 있는데, 표준 라이브러리의 checked_add와 같은 기능을 사용하여 검증을 강제하고 실패하는 경우에 대한 동작을 추가할 수 있다. 개발자가 unsafe 스코프에서 역참조를 할 포인터에 산술 연산을 하기 위해서는 이러한 점 외에도 여러가지 규범을 고려하여 undefined behavior가 발생하지 않도록 신중히 작성해야 한다.

3.1.1. 소유권과 수명

안전성과 성능을 모두 달성하기 위해 고려된 개념으로 기존에는 없던 생소한 개념이 다수 있다. 처음부터 본 문단을 완전히 이해할 필요는 없으며 간략한 코드를 직접 작성해 보면서 모르는 점이 있을 때 참고하면 된다.

소유권(ownership)은 객체의 생성과 소멸을 관리하기 위한 개념으로 스택 영역상에 존재하는 모든 값은 그 값이 대입된 변수나 구조체 필드, 넘겨받은 함수 인자 등의 변수에 귀속된다. 각 변수는 자기에게 귀속된 값에 대한 소유권을 가지며 다른 변수에게 값을 대입하면 그 이름으로 소유권이 이전되고 기존 변수는 파기된다. 그러므로 기존 변수에 대한 소멸자는 호출되지 않는다. 참조자도 별개의 객체로서 피참조 객체에 종속될 뿐이지 각자 소유권을 갖고 있음에 유의해야 한다. 힙에 할당된 값은 스택에 할당되는 객체에 같이 묶여 자동적으로 관리된다.

a = b와 같은 연산은 기본적으로 복사 연산이 아닌 이동 연산이다. 이동 연산은 값의 소유권을 새로운 변수로 이전하며 기존 변수는 파기한다. 다만, 단순히 메모리값을 복사만 해도 되는 타입에는 Copy 트레이트를 객체에 부여하여 복사 연산을 수행하도록 할 수 있으며 이 경우 기존 변수가 파기되지 않는다. 모든 정수와 실수 같은 primitive 타입에는 이 특성이 항시 부여되어 있고, Vec과 같이 힙에 할당된 포인터가 있어서 값을 단순히 복사하는 것으로 객체를 복제할 수 없는 경우에만 clone()을 호출하면 되기 때문에 프로그래밍할 때 거슬리는 수준은 아니다.

스코프(scope)는 코드를 둘러싸는 중괄호 내부를 말하는데, 스코프 내에서 할당이 이루어진 값은 이를 벗어나면 소멸하게 된다. 스코프 안밖으로 소유권을 이전할 수도 있는데 이동 연산으로 기존 변수를 파기하게 된다. 값이 할당이 해제되지 않으면서 자신의 스코프 밖으로 나갈 수 있는 방법은 두 가지가 있다. 스코프 마지막 줄에 세미콜론을 생략해서 소유권을 외부로 넘기거나, 외부의 객체가 내부에서 만들어진 객체의 소유권을 가져가면 된다. 값을 스코프 안쪽으로 집어넣기만 할 수도 있는데 함수 인자를 통해 소유권을 함수로 넘기면 함수가 끝나는 시점에 값의 할당 해제를 발생시킬 수도 있다.

함수에 넘겨진 인자는 함수가 기본적으로 소유권을 가지게 된다. 함수가 반환하는 변수는 함수 외부로 소유권을 넘겨준다.[8] 만약 소유권을 넘겨주지 못한 채로 함수나 해당 스코프가 종료되면 거기에 묶여 있던 변수도 수명이 끝나게 된다. 참조자는 참조자 객체 자신의 수명만 끝나게 되므로 피참조 객체의 수명보다 항상 짧기만 하면 된다.

빌린 참조(borrowed reference, borrowed pointer)는 말 그대로 값을 다른 변수로부터 빌려오는 참조를 말한다. 빌린 참조는 C/C++에서의 포인터나 참조자처럼 다른 변수를 참조할 수 있는데, 참조 변수는 피참조 변수보다 항상 수명이 짧아야 한다. 쉽게 말하자면, '도서관에서 책을 빌렸으면 적어도 도서관이 망하기 전에는 책을 반납하시오'와 같다.[9] 책을 반납하러 도서관에 왔더니 이런 일이 생기면 안 된다는 소리이다. 멀티스레드 참조와 같은 상황으로 인해, 수명을 컴파일 타임에 결정할 수 없는 경우 컴파일 에러가 발생하게 된다.[10]

수명 파라미터(lifetime parameter)는 참조자의 수명을 명시하기 위한 일종의 제네릭으로 참조 관계가 난잡한 상황에서도 컴파일러가 유효성을 검증할 수 있도록 하는 중요한 개념이다. 참조자를 인자로 받는 함수나 참조자를 가지는 구조체 및 튜플에 정의하게 되며, (아직은 모를) 피참조 객체의 수명에 묶이게 된다. 만일 이러한 타입의 객체가 피참조 객체의 수명보다 길면 컴파일러가 에러를 표시한다. 각각의 수명 파라미터는 독립 관계나 종속 관계로 지정할 수 있다. 'b: 'a로 표시하면 'b'a보다 수명이 같거나 길어야 한다. 정확한 참조 관계를 이해하지 못해 잘못 설정할 경우 컴파일 에러로 골치를 앓을 것이다. 초보자 입장에서는 활용 방법이 잘 와닿지 않을 수 있으므로 관련 예제를 찾아보거나 ttf_parser와 같은 크레이트의 소스 코드를 읽어보는 것이 도움이 된다.

Rust는 이렇게 소유권과 수명을 컴파일 타임에 추적할 수 있도록 설계됐으며, 스택 영역에 할당되는 객체와 변수의 생성과 소멸 시기를 컴파일 타임에 모두 결정하고 검증하며 dangling 포인터를 방지한다. 소유권 개념을 스마트 포인터와 혼동하는 경우가 있는데, 스마트 포인터는 힙 영역에 할당되는 객체를 자동적으로 관리하기 위한 것으로 객체의 수명이 런타임에 결정된다.

힙 영역에 할당하는 객체의 경우, Rust 표준 라이브러리에서 제공되는 BoxRc를 통해 스마트 포인터를 사용할 수 있다. Rc와 같은 reference counting(참조 횟수 계산) 스마트 포인터의 경우, 순환 참조에 의한 메모리 누수가 여전히 발생할 수 있다는 점에 유의하자. 이 경우 참조 횟수를 추가하지 않는 Weak를 상황에 맞게 사용해서 해결할 수 있다.

3.1.2. 가변성

Rust 언어에서는 모든 변수의 가변성을 명확하게 컴파일 타임에 구분한다. 변수 수정에 관한 규칙은 다음과 같다.
초보자 입장에서 상수와 가변성을 갖지 않는 변수를 헷갈려 하는 경우가 있다. 상수는 컴파일 타임에 결정되는 값이며, 가변성을 갖지 않는 변수는 기본적으로 변경을 허용하지 않을 뿐이다. RefCell이나 UnsafeCell를 사용하는 변수나 그에 대한 참조자는 가변성 없이도 내부 데이터를 변경할 수 있다.

가변성은 동시성을 제어하기 위해 설계된 것은 아니다. 멀티스레드에서 변경 가능한 변수를 록이나 뮤텍스 없이 공유하는 것은 대부분의 경우에서 바람직한 방법이 아니다. 멀티스레드 환경에서는, 변경 가능한 변수를 std::sync::Arcstd::sync::Mutex와 같이 동시성 제어를 제공하는 타입으로 묶어서 안전하게 관리할 수 있다.

3.2. 철저한 에러 관리

Rust에는 예외가 없다. 대신 성공적인 반환 타입 T와 에러 타입 EResult<T, E>[11] enum으로 감싸, 반환값과 에러 둘 중 하나를 담고 있는 결과를 값으로 표현할 수 있도록 한다.

Rust는 에러 처리를 철저히 관리해 프로그램의 안정성을 보장한다. 실행이 실패할 수도 있는 경우 경우 함수에서 Result<T, E>를 반환하게 만드는 것이 코드를 작성하는 올바른 방법이다. 이는 "대부분의 에러는 프로그램을 완전히 멈춰야 할 정도로 심각하지는 않다."라는 Rust의 철학에 따른 언어 설계다.

다른 언어의 예외와 비교하면 오버헤드가 거의 없기 때문에 Rust의 모토인 무비용 추상화(zero-cost abstraction)에 부합한다. C++의 경우 예외를 처리할 때 스택 되감기를 하여 5000~10000 cycle에 달하는 오버헤드가 발생하기 때문에 예외 자체를 비활성화하는 경우도 허다하나, 표준 라이브러리를 사용하는 이상 예외를 피할 수 없다는 단점이 있다. Rust에서는 Result<T, E> enum 값을 사용하기 때문에, 에러 처리가 단순한 return문과 기능적으로 같으며 에러 발생 시의 오버헤드가 존재하지 않는다.

러스트 개발자들도 에러 처리가 귀찮다는 것을 알기 때문에 편의성을 높여주는 기능들이 러스트에 내장되어 있다. 예를 들면, 다음과 같이 함수를 호출해 발생한 에러를 그대로 반환할 수도 있다.
#!syntax rust
fn foo() -> Result<i32, MyError> {
    let number: i32 = bar()?; // bar()에서 에러가 발생하면 이를 즉시 반환한다.
    let added: i32 = number + 3;
    Ok(added)
} 

또한 러스트에는 타입 유니온[12]이 없기 때문에 여러 에러를 한데 묶기 위해선 enum을 별도로 선언해야 한다.
#!syntax rust
use std::error::Error;

#[derive(Debug)]
enum MyError {
    CaseOne,
    CaseTwo(SecondError),
    CaseThree(ThirdError),
}

impl Error for MyError {}

Enum이 다양한 오류 타입을 표현하는 데에 자주 사용되는 것은 Rust가 기본적으로 변수 값을 스택 메모리에 저장하기 때문이다. Result<T, E> 값에 들어 있는 에러 타입 E가 스택 메모리 상에서 몇 바이트를 차지하는지는 반드시 컴파일 시에 정해져야 한다. Enum 변수의 경우 각 variant 중 가장 큰 항목이 enum의 메모리 사용량을 결정하기 때문에 여러 타입 중 하나라는 것을 표현하기에 적합하다. Rust는 Java나 Python 등의 언어와 달리 변수의 값을 힙 영역으로 보내지 않으며, 이렇게 함으로써 C++ 수준의 성능을 달성한다.

이와 같이 enum을 선언하고 impl문을 작성하는 것의 귀찮음을 해소하기 위한 anyhow, thiserror 등 매크로 기반 서드 파티 크레이트도 존재한다.

3.3. 편리한 열거형

여타 언어들의 열거형(enum)은 단순히 상수들에 이름을 붙인 것이지만, Rust의 enum은 대수적 자료형에서의 합 타입(sum type)의 일종으로, 각각의 열것값(variants)마다 다른 타입을 가지는 것이 가능하다.

보통 각각의 열것값을 구조체나 튜플로 정의하여 내부에 값을 포함하게 되며, 다른 compound type과 마찬가지로 이때 해당 값의 소유권이 이동된다. 다른 타입들과 마찬가지로 impl을 통해 메서드를 추가하거나 트레이트를 구현하는 등 다양한 용도로 활용할 수 있으며, 해당 enum 타입의 크기는 열것값 중 가장 큰 것의 크기에 따라 컴파일 타임에 결정된다.[13]

간단한 예시는 다음과 같다.
#!syntax rust
enum Action {
    Hello(String),
    Call { country: u16, number: String },
    ThankYou(String, i32),
    Unknown,
}

let action = Action::Hello(String::from("namu"));

match action {
    Action::Hello(name) => println!("hello {} again !", name),
    Action::Call { country, number } => println!("call at +{}{}", country, number),
    _ => println!("sorry, i do not know that action :("),
}

이렇게 enum을 설계함으로서 enum의 유연성을 극대화시켰으며, 그 결과로 러스트에서는 다른 언어의 switch에 해당하는 match 구문이 자주 쓰인다. match 구문을 이용하면 열것값에 따라 분기하면서 구조 분해까지 한 번에 할 수 있다.

이때 주의할 점은, match는 가능한 모든 분기를 검사하도록 강제된다는 것이다.(exhaustiveness check)
#!syntax rust
enum State {
    Running,
    Waiting,
    Terminated,
}

let process_state = State::Waiting;

match process_state {
    State::Running => do_something(),
    State::Terminated => cleanup_process(),
    // error[E0004]: non-exhaustive patterns: `Waiting` not covered
    // State가 가질 수 있는 값의 종류는 3가지이지만, 위 코드에서는 2가지밖에 검사되지 않았다.
    // 에러를 없애려면 나머지 경우를 처리하는 코드를 추가한다.
    // State::Waiting => todo!()
    // 남은 패턴을 한 번에 처리하려면 _(wildcard pattern)을 사용한다.
    // _ => todo!()
};
러스트 컴파일러는 enum 타입에 대한 정보를 가지고 주어진 match 식이 가능한 모든 경우를 체크했는지 컴파일 타임에 검사한다. 만약 컴파일러가 충분히 똑똑하지 못했다면, 위 코드는 대기 중인 프로세스를 처리하지 못하고 루프를 반복해서 돌기만 하는 버그를 일으켰을 수 있다. 덕분에 enum과 match 구문을 효과적으로 사용하는 러스트 개발자는 버그를 미연에 방지할 수 있으며, 조금 더 확신을 가지고 개발에 집중할 수 있다.

특히나 이 match 구문은 함수형 프로그래밍 언어 사용자들이라면 익숙할 패턴 매칭 기능이다. elixir만큼 자유로운 매칭까지는 아니지만 범위 매칭, @ 바인딩, 매치 가드 등 편리하고 핵심적인 기능을 제공한다. Rust에서는 함수형 언어의 개념 중 하나인 모나드를 enum을 통해 간단하게 구현할 수 있으며, 그 예로는 Result<T, E>, Option<T> 등이 있다. 다른 언어들은 언어 차원에서 모나드를 지원하기 위한 특수 문법이 존재하지만, Rust에서 이들은 enum으로 표준 라이브러리에 정의되어 있다.
#!syntax rust
enum Option<T> {
    None,
    Some(T),
} 
SomeT를 소유하기 때문에 이를 앞서 본 것과 동일한 match문으로 검사하여 값이 있는지 없는지를 실수 없이 검증할 수 있다.

3.4. 트레이트

Rust는 객체 상속을 제공하지 않는다. 상속을 사용하면 복잡해지고 유연성이 떨어지기 때문이다. 대신 트레이트(인터페이스)에서 상속을 허용하여 유연성과 재사용성을 동시에 확보했다. 트레이트는 객체의 특성을 나타냄과 동시에 그 특성과 관련한 인터페이스[14]를 제공한다. 객체에 Clone 트레이트를 구현하면 복제가 가능함을 나타냄과 동시에 clone() 메소드가 제공되어, 객체의 특성과 메소드가 하나의 묶음으로써 존재하게 된다.

트레이트는 객체와 달리 변수를 가질 수 없으며 상속이 가능하다. 그리고 impl T for A 블록을 작성해서 어떤 클래스에 트레이트를 구현하게 되면, 구현된 메서드를 사용할 수 있다. 트레이트에 메서드의 기본 구현이 있는 경우, 기본 구현을 그대로 사용하도록 하는 것도 가능하다.

트레이트가 가지는 중요한 역할 중 하나는, 제네릭 인자에 트레이트를 써서 인자로 들어갈 타입에 필요한 조건(특성)을 붙이는 것이다.[15] 이는 다른 언어의 덕 타이핑과 유사한 개념이며, Iterator를 구현한다면 (타입은 잘 모르겠지만) 순회 가능할 것이고, Fn을 구현한다면 클로저일 것이고, Ord를 구현한다면 (역시 구체적인 타입은 몰라도) 크기를 비교 가능한 값임을 알 수 있다. 예를 들어 값 세 개를 오름차순으로 정렬하는 제네릭 함수는 이렇게 만들 수 있다.

덕 타이핑에서 한 단계 더 나아가, '어떤 트레이트를 구현하는 타입이라면 이런 연산을 할 수 있을 것' 이라고 정의한 것이 바로 연산자 오버로딩(operator overload)이다. 가령 복소수를 표현하는 구조체를 만들고 Add를 구현해 복소수끼리의 덧셈을 정의했다면 일반 숫자를 다루듯이 + 연산자를 사용할 수 있다. 역참조 연산자인 * 또한 오버로딩 할 수 있으며, DerefDrop트레이트를 수동으로 구현해서 스마트 포인터를 만들 수 있다.

객체지향이 보편적으로 쓰이는 게임이나 시뮬레이션 등에서 이러한 특징은 큰 약점이 될 수도 있다고 생각할 수 있으나 그렇지는 않다. 라이브러리 단에서 procedual macro를 제공하여 자동적으로 구현이 되도록 하거나 trait 기본 구현을 제공할 수 있다. 이를 통해 인터페이스의 재사용성뿐만 아니라 객체 구현의 재사용성도 어느 정도 달성이 가능하다.

3.4.1. 특수한 트레이트

몇몇 트레이트(Trait)는 컴파일러에게 특수한 취급을 받는다. 이중 몇몇은 특수한 성질을 나타낼 때 쓰이고 몇몇은 문법적 추가 요소(Syntactic Sugar)로서 작동한다. 이들 중 대부분은 std::marker, std::ops에서 찾을 수 있다. 이때 marker는 말 그대로 내용이 비어 있어 아무 동작도 안 하지만 trait bound에 사용할 수 있는 트레이트를 말한다.

이 외에 for문에서 쉽게 사용될 수 있도록 하는 Iterator/IntoIterator 등의 trait 등도 존재한다.

3.5. 위생(하이지닉) 매크로

Rust의 매크로는 다음의 특징을 가지고 있다.

C/C++에서의 매크로는 단순한 문자열 치환이다. 예를 들어 MUL5(x) (x * 5)라고 한다면 MUL5(3)(3 * 5)로 치환될 것이다. 이것은 문맥에 따라 수많은 잠재적인 문제를 만들 수 있다. Rust의 매크로는 LISP의 하이지닉 매크로 개념을 상당수 차용했다. 컴파일러가 단순한 텍스트 중복이 문제가 안 되도록 알아서 잘 처리한다.

C/C++의 매크로에서는 MUL5(3)에서 3이 곱셈이 가능한지, 실수인지 이런 여부를 판단할 수 없다. Rust의 매크로 시스템에서는 MUL5(x)에 들어온 인자가 변수의 이름인지, 문자열인지, 네임스페이스인지, 람다 함수인지 등을 알 수 있다.

또한, Rust의 매크로는 메타 프로그래밍을 지원한다. 메타 프로그래밍은 컴파일 타임에 모든 것이 결정되는 프로그램을 작성하는 것으로서, 입력되는 매개 변수에 따라 넣을 코드를 결정하거나 미리 계산하도록 할 수 있다.

Rust에서 제네릭과 메타 프로그래밍이 분리되어 지원되는 것은, C++에서는 템플릿 문법이라는 하나의 도구를 이용해 일반화 프로그래밍(제네릭)과 메타 프로그래밍 두 가지를 지원하는 것과 대비되는 점이다. 물론, Rust에서 메타 프로그래밍이 매크로로 분리됐다고 해도, 메타 프로그래밍 자체가 여전히 어려운 것은 변함이 없다.

3.6. 비동기 프로그래밍

Are we async yet?

Rust는 언어 차원에서 비동기 프로그래밍을 지원하고 있으며, Python, C# 같은 다른 언어에서 사용되는 async/await 구조의 비동기 구문을 비슷한 형태로 사용할 수 있다. 몇년동안 nightly 기능으로 개발되다가, 2019년 11월 7일 v1.39.0 버전부터 안정(stable) 기능이 되었다.Async-await on stable Rust!

다른 언어에서 흔히 사용되는 비동기 프로그래밍 패턴 중 Future 개념은 코루틴[16]인 대표적인 예이다. 이러한 개념을 구현한 Future# 트레이트와 async/await 문법을 사용하면 되는데, JavaScript와 같은 Promise 기반의 언어와 달리 비동기 함수를 실행할 실행자(Executor)가 별도로 존재한다. Promise 객체는 객체가 생성됨과 동시에 자동으로 스케줄링이 되지만, Future 객체는 객체 생성 순간에는 아무것도 실행되지 않는다. 실행자는 실질적으로 작은 스케줄러 역할을 수행하며 이에 대한 구현은 서드 파티에게 맡긴다. 현재 tokio가 가장 널리 쓰이는 실행자 구현체이다.[17]

Futureasync 함수 선언을 통해 자동적으로 구현된다. Future는 기본적으로 스레드 간에 이동될 수 있기 때문에 어떤 스레드에서 일시 정지됐다가 다른 스레드에서 재개하는 것도 가능하다. 그러나 async 함수에서 포인터와 같이 Send가 구현되지 않은 타입을 다루게 되면, FutureSend가 구현되지 않으며 비동기 프로그래밍에 상당한 제약 사항이 발생한다.# 이러한 문제를 해결하려면 async 함수에서 그러한 타입을 직접 다루지 않고 별도의 함수에서 처리하도록 해야 한다.

Rust에서 비동기 프로그래밍을 시작해 보고 싶다면 Asynchronous Programming in Rust(한글판)를 읽어보는 것을 추천한다. 아직 미완성이기는 하지만 Rust 언어에서 코루틴과 실행자를 구성하는 대략적인 구조를 이해하는 데 도움이 되며, 부족한 내용은 표준 라이브러리 API 명세을 참고하거나 구글 검색으로 관련 내용을 찾아보면 보충할 수 있다.

3.7. 제네릭

Rust에서도 C++, C#, Java 등 대중적인 정적 타입 프로그래밍 언어들에서 흔히 제공하는 일반화 프로그래밍(Generic Programming) 패러다임을, 제네릭이라는 기능으로 제공하고 있다.

다만, Java나 C#이 제공하는 제네릭과, Rust가 제공하는 제네릭(그리고 C++ 템플릿)은 언어 설계 단계에서 채택한 정책이 서로 크게 다르다.

예를 들면, Java의 제네릭은 컴파일했을 경우 단 하나의 코드가 생성된다. 이후에 여러 가지 다른 타입의 인자가 주어졌을 경우, 각 인자의 타입을 지워서(type erasure) 이미 생성해 둔 하나의 코드에 적용시키는 방식이다. 이에 반해서, C++ 템플릿은 컴파일했을 경우 해당 프로그램 전체의 사용 패턴을 확인해서 적용된 모든 타입의 인자에 해당하는 코드가 각각 따로 생성된다.

즉, Java의 경우에는 코드 생성 과정이 단순하고 생성된 코드 크기가 훨씬 작다는 장점을 선택한 대신 매번 실행 시에 type erasure 과정을 거치는 오버헤드를 감수하기로 한 것이고, C++의 경우에는 매번 실행시에 오버헤드가 전혀 없다는 장점을 선택한 대신에 생성 코드 크기가 커질 수도 있고 컴파일 타임이 길어질 수도 있다는 것을 감수하기로 한 것이다. Rust는 C++의 방식을 채용하므로, 런타임 성능을 강조하고 컴파일 타임을 약간 희생하는 방식이다.

하지만, Rust의 제네릭과 C++의 템플릿 방식 사이에도 차이점이 존재한다. Rust의 경우 위의 다른 항목에서 설명한 트레이트 덕분에 코드 생성에 필요한 정보가 컴파일러에게 보다 많이 제공될 수 있다. 이를 통해 Rust 컴파일시에 C++보다 더 많은 체크와 최적화가 이론적으로 가능하다.[18]

4. 개발 도구별 특징

4.1. 안전하고 강력한 컴파일러

안전성을 위해 컴파일에 최대한 오류가 많이 걸러지게 설계된 Rust의 특성상 컴파일러가 매우 강력하다. 대부분의 예외나 에러는 컴파일러에서 잡히고, [19] 오류를 잘 검출하는 것뿐만 아니라, 오류가 난 이유와 과정, 해결 방법 제안 등 컴파일 단계에 많은 정보를 제공한다. 따라서 일단 컴파일이 된다면 런타임 에러가 상대적으로 덜 발생하게 된다.

컴파일 단계에서 여러 const 관련 기능, 상술한 C, C++ 라이브러리와의 정적 링크를 위한 코드 생성, 극도로 strict한 타입 관리, 에러 발견 등 최대한 많은 작업을 처리하려고 하기 때문에 컴파일 속도가 느린 편에 속한다. 하지만 이것은 컴파일러에 도입한 incremental compile[20]을 통해 부분적으로 해결했다.

Rust는 C나 C++의 코드를 오버헤드 없이 코드에 이식할 수 있는데, 그 Cross-Language LTO라는 기능도 이 컴파일러의 기능이다.

4.2. 강력한 툴체인

표준화된 패키지 관리 시스템이 존재하지 않는 C++와 다르게 패키징 및 공개(publish), 의존성 관리, 버전 관리, 워크스페이스, 빌드 캐시, 종속성 고정(lock), 빌드 스크립트 등 다양한 기능을 가지는 패키지 관리자 Cargo가 기본적으로 지원된다. 모듈들은 크레이트(crate)라고 하는 단위로 패키징되어 Crates.io (Rust 패키지 저장소)를 통해 실행 파일이나 라이브러리로 배포될 수 있으며, Cargo를 통해 빌드 및 패키지 배포를 자동화하고 필요한 종속성 및 바이너리를 Cargo를 통해 자동으로 다운로드받고 컴파일 할 수 있다.

개별 패키지 정의는 기본적으로 Cargo.toml이라는 TOML 매니페스트 파일에 기록되며, 빌드 시 해당 정의에서 직접 종속성(direct deps) 및 간접 종속성(transitive deps) 그래프를 추적하여 자동으로 다운로드 및 컴파일한 후 내부적으로 --extern, -L 등 필요에 맞는 링킹 플래그를 생성하여 rustc를 대신 실행한다. 즉, Cargo는 단일 crate만 컴파일 가능한 rustc와 다르게 dependency resolution 과정이 포함된 일종의 wrapper 역할을 수행한다.[21]

이외에도 build, run, check[22], test[23], install[24] 등 개발에 필요한 다양한 명령어들을 기본적으로 내장하고 있다.

라이브러리의 소스 코드를 정적 분석하고 주석을 읽어 타입 정보, 사용 예시, 조건부 컴파일 플래그 등이 포함된 API 문서를 자동으로 생성하는 툴인 rustdoc이 존재한다. 기본적으로 doc comment라고 하는 슬래시 세 개(///)로 이루어진 주석으로 공개된(exported) 코드 주위에 작성해 문서화를 해주면 주석에 적힌 설명을 문서에 반영하고, 코드를 HIR 단계로 컴파일한 후 HIR query를 통해 빠진 타입 정보를 채운다. librustdoc이 Cargo에 통합되어 있어 $ cargo doc으로 로컬에서 사용할 수 있으며, crates.io의 빌드 환경에도 포함되어 있어서 패키지를 공개할 시 docs.rs에 자동으로 내 패키지의 문서가 만들어진다.

이 문서 시스템을 적용한 대표적인 예는 Rust의 표준 라이브러리std 등이 있으며, rustdoc의 이러한 편리한 문서화 기능으로 인해 rust의 std 문서는 상당히 잘 구성되어 있다.

이외에도 코드 포매터rustfmt, 린터[25]clippy, UB 검사용 MIR(Mid-Level IR) 가상 머신miri, 언어 서버 프로토콜 구현체인 rust-analyzer, gdb 디버거 래퍼 스크립트인 rust-gdb 등 개발에 필요한 수많은 툴을 기본적으로 제공하고 있다.

이러한 툴체인들은 rustup이라는 버전 관리자를 통해 모든 툴체인들의 버전을 전역으로 한번에 관리하고 프로젝트별로 다른 툴체인 버전을 pin할 수 있으며, proxy 기능을 통해 rustup 또는 cargo에서 바로 실행하는 것도 가능하다.

4.3. 여러 IDE의 지원

고수준의 언어 지원은 주로 언어 서버 프로토콜을 통해 이루어지고 있다. 과거 공식 RLS 프로젝트가 있었으나 deprecate되고 중단되었으며,[26] 현재는 대부분 rust-analyzer로 넘어갔다. 본래 비공식 프로젝트였으나 2022년 2월부터 러스트 조직에 합류하여 러스트 공식 프로젝트가 되어, 현재는 rustup 툴체인에도 기본적으로 포함되어 있다.

rust-analyzer는 LSP 구현체인 만큼 Visual Studio Code, Visual Studio, Neovim, Emacs, Sublime Text 등 대부분의 에디터 및 IDE에서 플러그인 형태로 사용할 수 있으며, 각종 컴파일 오류 및 clippy 린터의 제안 표시, 코드 자동완성, overlay hint, 리팩토링 제안, Cargo 기반 symbol definition 추적 등 Rust 개발에 필요한 대부분의 기능을 제공한다.

단점으로 디버깅 기능은 내장하고 있지 않아, codelldb 등의 외부 디버거 플러그인이 필요하다. 또다른 단점으로 프로젝트 /target 폴더의 심볼 인덱싱 성능이 좋지 않은 편이다.

2023년 9월 13일에 IntelliJ IDEA로 유명한 JetBrains사에서 Rust Foundation에 가입했음을 알림과 동시에 Rust 전용 통합 개발 환경RustRover를 공개했다.# (다운로드 페이지) 8개월간의 얼리 엑세스 기간을 거친 후 2024년 5월 21일 정식 출시했으며,# 비상업 용도로 사용할 경우 무료인 정책으로 출시되었다.[27] 최초 버전에는 웹 프런트엔드 및 데이터베이스 기능이 제거된 채로 출시되었지만, 2024년 9월 5일 정책 변경과 함께 다시 지원되었다.# 이전까지 무료로 GitHub과 JetBrains marketplace에서 오픈 소스로 제공했던 intellij-rust 플러그인deprecate하며,[28] 최신 버전의 IDE와의 호환성은 계속해서 제공하지만 더 이상 버그 수정이나 새로운 기능 추가를 제공하지 않을 예정이라고 밝혔다.[29]# 현재 marketplace에 올라가 있는 rust plugin은 해당 업데이트 이후 RustRover와 함께 비공개로 관리되는 유료 확장이다.

5. 주목받고 있는 언어

5.1. 개발자들이 가장 좋아하는 언어

2015년부터 스택 오버플로 설문 조사에서 매년 가장 좋아하는 언어 중에 하나로 선정되고 있다. 2015년에는 3위에 진입했다가, 2016년부터 매년 연속 1위를 달성했다. (2017년, 2018년, 2019년, 2020년, 2021년,2022년, 2023년 설문조사 결과)

5.2. 대기업에 주목받고 있는 언어

아마존, 구글, 마이크로소프트, 페이스북, 모질라, 리눅스 재단, 디스코드, 드롭박스, npm 등 IT 관련하여 유명한 기업이나 재단이 자사 서비스에 Rust를 적극적으로 활용하고 있다.#

Visual Studio를 개발한 마이크로소프트가 Rust를 메모리 안정성이 좋고, C 및 C++를 대체할 수 있는 시스템 프로그래밍 언어라고 말했다. 심지어 Rust의 주목성에 탐이 났는지 Rust 같은 언어를 자체적으로 만들겠다는 소식이 나왔을 정도.

실제로 MS에서도 러스트를 밀어주기 위해 자사 소프트웨어 기술 지원 사이트인 Docs에 Rust 교육 과정을 추가했으며 러스트 개발과 관련된 기초적인 자료를 올려놓기 시작했다. Docs 특성상 MS에서 만든 .NET 계열이나 Azure 관련 자료가 많았는데 MS가 주도하지 않는 언어가 추가됐다는 사실 자체로도 매우 놀랍다고 볼 수 있다.

구글 또한 MS와 마찬가지로 Rust와 같은 언어를 자체적으로 만드는 시도를 해서 Carbon이라는 언어를 공개했다.

5.3. 운영 체제 개발 언어

C++은 커널 영역과 같은 저수준에서 추상화를 적절히 활용하기 어렵다는 점[30] 때문에 도입을 꺼리거나 일부분만 사용되어 왔는데 Rust가 등장하자 C++ 도입을 꺼리던 리눅스에서도 도입됐고, 윈도우나 안드로이드처럼 울며 겨자 먹기로 C++를 도입했던 운영 체제들도 C++를 빠르게 밀어내고 러스트로 대체 중이다.

마이크로소프트 윈도우NT 커널에서도 2024년에 출시된 Windows 11 버전 24H2부터 도입되기 시작했다.#

리눅스리눅스 커널에서도 6.1 버전부터 러스트를 도입하기로 결정했다.#

리눅스 기반인 안드로이드에서는 도입이 더 빨랐다.[31]

2021년 4월 6일 구글 보안 블로그에 따르면 안드로이드 오픈 소스 프로젝트(Android Open Source Project, AOSP)가 안드로이드 OS 개발 언어로 Rust를 추가하기로 했음을 밝혔다.[32] 이는 기존에 주로 CC++로 이루어지던 안드로이드 OS의 하단부 개발과 관련하여, 기존의 코드를 갈아엎겠다는 것이 아니라 새로운 프로젝트들을 Rust로 작성하는 것도 허용하고 장려하겠다는 뜻이다.[33][34] 2022년 12월 구글 보안 블로그에 안드로이드에 Rust를 도입한 이후에 얻은 성과를 공유하는 글이 올라왔다. #

Asahi Linux의 GPU 드라이버도 러스트 기반으로 개발되어 현재 OpenGL ES 3.1까지 완벽하게 지원한다. C로 처음부터 개발하자니 너무 복잡하고 잠재적인 문제점들도 많아 당시 막 리눅스에 도입되기 시작한 러스트로 개발하는 모험을 감행했고, 결과적으로 드라이버 작성을 시작한지 두 달도 안 되어서 GNOME 데스크톱을 안정적으로 실행하는 데 성공했다.

6. 사용 현황 및 전망

6.1. 전망

오버헤드 없는 안전한 메모리 관리가 가능하다는 점에서 시스템 프로그래머들이 주로 선호하는 편이다. 모질라 재단에서 개발한 만큼, 파이어폭스에서는 상당 부분을 Rust로 대체했고, 구글은 차기 운영 체제인 퓨시아에서 Rust를 사용 중이며, 아파치의 mod_ssl 모듈의 안정성을 개선하기 위해 Rust를 사용할 것이며 지원하겠다고 밝혔다. 또한 머신 러닝 라이브러리인 Tensorflow Rust 또한 지속적으로 지원하고 있다.#

페이스북도 내부 시스템 일부에 Rust를 적용한 상태라고 한다. 레딧에서는 백엔드 개발을 담당할 Rust 엔지니어를 구인한 바 있다. # 이 언어로 Redox란 운영 체제도 개발되고 있다. 또한 페이스북의 암호 화폐 리브라에서도 사용되고 있다. npmCloudflare는 기반 언어를 C에서 Rust로 교체했다. 2020년 기준 Discord가 서버와 클라이언트단 언어를 Golang에서 Rust로 교체했다. 차세대 자바스크립트 런타임인 Deno도 시스템 바인딩을 Rust로 작성했다.

그러나 전체적으로 보면 여전히 Rust의 사용률은 미진한 편이다. TIOBE 순위에서는 순위가 떨어지는데, 이는 소프트웨어 인프라가 기존 언어로 대부분 갖추어져 있고, 전문 인력을 구하기 쉽지도 않으며, 라이브러리에 대한 지원이 적기 때문으로 보인다.# 순위는 5년 동안 꾸준히 상승하고 최근 ScalaKotlin을 제치고 올라가고 있지만, 여전히 대부분의 기업은 시스템 프로그래밍에 거의 C/C++만을 사용하고 있다.

다만, 2019년 스택 오버플로 개발자 설문 조사에서 무려 파이썬자바스크립트를 제치고 83.5%의 높은 선호도로 '개발자들에게 가장 사랑받는 언어' 1위를 차지했다는 점이나 구글 트렌드나 각종 랭킹 사이트에서의 수치가 장기적으로는 증가하고 있다.

'Rust는 소유권과 수명을 직접 지정해 줘야 해 불편하고 문법이 어렵고 기능이 많아 배우기 힘들다'는 주장이 있으나, 'Rust의 주 타깃이 되는 유저들은 Rust보다 훨씬 더 어렵고 불편한 C/C++를 쓰고 있기에 문제가 되지 않는다'는 반론도 있다. 페이스북이 공개한 자료에 따르면 자사 엔지니어가 Rust를 능숙하게 익히는 데 두 달이면 충분했다고 한다.

C++ 사용자들의 가장 큰 불만은 난이도가 아니라 메모리와 관련한 실수를 하기 매우 쉽다는 것이다. Rust의 설계 목표가 비교적 안전한 시스템 프로그래밍 언어인 만큼, Rust에서 메모리 안정성을 위해 문법을 강제함으로써 발생하는 불편함과 C++에서 메모리 버그를 코드 리뷰와 디버거로 일일이 찾아내는 수고는 비교가 안 된다. 구글과 마이크로소프트에서는 Rust를 사용할 경우 자사 제품의 보안 버그 패치 비용의 70%를 절감할 수 있을 것이라는 내용의 문서도 공개했다. 구글/마이크로소프트/인텔은 이미 Rust의 개발에 깊숙이 관여하고 있으며, 각종 컨퍼런스에서 공개적으로 이를 언급하고 있다. C++11부터는 C++98와 달리 Raw pointer를 직접 사용하는 대신 컨테이너나 스마트 포인터의 사용을 적극적으로 권장하고 있어 충분한 메모리 관련 안전성을 유지하면서 코드의 작성이 가능하려는 변화를 하고 있다.

Rust는 모질라 재단을 통하여 개발이 시작된 만큼 모질라와 상당한 연관이 있는데, 2020년 8월 기부금으로 움직이는 모질라 재단이 코로나로 인해 자금 융통이 어렵다는 이유로 250명을 감축했으며, 이로 인해 Rust 개발 팀이 상당한 피해를 입었을 거라는 추측이 돌았다. # 그러나 일각에서는 Rust가 이미 모질라 재단 소속의 기여보다 외부의 기여가 많아진 상황이라, 큰 영향은 없을 것으로 보기도 했다. 실제로는 Rust 개발 팀이 아니라 Rust를 이용해 파이어폭스Gecko를 대체할 렌더링 엔진을 개발하려던 Servo 프로젝트가 리눅스 재단으로 인계되며 피해를 입은 것으로 드러났다.

2020년 9월 TIOBE에서 18위를 달성했다.

AWS는 다른 기업보다 Rust에 관심이 많은데, 실제로 Rust를 사용하여 Amazon S3(Amazon Simple Storage Service), Amazon Elastic Compute Cloud(Amazon EC2), Amazon CloudFront, AWS Lambda(서버리스) 등 서비스를 제공한다. 최근에는 러스트로 작성된 Linux 기반 컨테이너 운영 체제 보틀로켓(Bottlerocket)을 출시했다. 또한 아마존 EC2 팀은 Nitro Enclaves와 같은 민감한 애플리케이션을 포함한 새로운 AWS Nitro 시스템 컴포넌트의 선택 언어로 Rust를 사용한다. 또한 2020년 11월 아마존(AWS 클라우드 팀)이 Rust 컴파일러의 공동 리드를 맡았던 펠릭스 클록(Felix Klock)을 개발자로 영입했다. 영입을 이끈 Matt Asay는 트위터를 통해 AWS에서도 Rust가 사용되고 있으며, 안정성과 퍼포먼스에 상당한 기여를 하고 있다고 밝히기도 했다. Matt Asay 트위터. 또한 AWS는 2019년에 스폰서십을 시작으로 2021년 2월에 발족한 러스트 재단에 초기 회원사가 됐다. 이외에도 Rust 개발자를 적극적으로 구인하는 중이라고 밝히기도 했다.관련 기사 한편으로는 이를 모질라 재단의 감축으로 인한 효과라고 보는 시선도 있다.

한국인 개발자에 의해 개발된 TypeScript 컴파일러인 SWCshopify, Next.js# 등 큰 생태계를 가진 플랫폼에서 정식 채용 되면서 또다시 관심을 받았다. 또한 2020년 이후로 WebAssembly가 적극적으로 사용되면서 서버사이드뿐 아니라 브라우저에서도 Rust를 활용할 여러 방법들이 제시되는 등 웹 개발 분야에선 끊임없이 관심의 대상이 되고있다.

Ruby의 컴파일러인 YJIT의 코드베이스가 C99 에서 Rust로 대체될 예정이다. Ruby의 핵심 개발자들이 포팅에 참여해서 작업해 2022년 4월 20일, 포팅이 완료됐으며, 다른 기여자들의 리뷰를 위해 소스 코드가 공개됐다. 해당 Github 풀 리퀘스트

Linux 커널 6.1부터 일부 구성 요소 한정으로 Rust로 대체될 예정이다.#

Microsoft에서 기존 윈도우 코드를 Rust로 새로 짜는 중이라고 한다.#

2023년 들어 Rust로 GUI 앱을 만들기 위한 라이브러리와 프레임워크가 많이 생겨나고 있다. Flutter를 프론트엔드로 연결하는 RinfGTK를 프론트엔드로 연결하는 GTK4-RS가 대표적이다.

Tauri라는 일렉트론의 대체제가 있는데, 프론트엔드로는 JavaScript를, 백엔드로는 Rust를 사용한다.

반면 curl의 경우 실험적으로 추가했던 Rust로 구현된 Hyper 라이브러리 지원을 유지 보수 비용 증가 및 참여자 부족등의 이유로 제거했다. #

6.2. 기존 언어와의 비교

6.2.1. Rust vs. C++

Rust의 출시 배경은 C++에서 제공하는 개념만으로는 숙련되지 않은 프로그래머가 작성 시에 (특히 멀티스레드 환경에서) 보안 취약점이나 '정의되지 않은 동작' 오류가 발생할 위험이 높아진다는 데 있다. 전 세계 수십억 명이 사용하고 있는 윈도우크롬은 대기업에서 전문 인력으로 개발되고 있지만 매년 CVE로 분류되는 심각성 높은 메모리 버그를 해결하기 위해 보안 업데이트를 지속적으로 배포하고 있다. 현실적으로 C/C++ 언어에서 메모리 버그를 완전히 잡아내기란 어렵다. 그래서 Rust나 그외 GC 언어가 제공하는 메모리 안전성은 개발자가 로직에 집중할 수 있도록 도와 안정감을 줄 뿐만 아니라, 잠재적 보안 위협으로 지출되는 비용을 줄여 결과적으로 보안성 및 생산성 측면에서 적잖은 이점을 가져다주며, 이것이 기존 C/C++와 비교되는 큰 장점이라고 할 수 있다.

C++를 사용해 오던 개발자가 Rust에 대해 처음 접할 때 Rust의 메모리 안전성은 단순히 스마트 포인터를 통해 달성할 뿐이라고 잘못 이해하는 경우가 있다. # Rust는 언어 차원에서 모든 객체의 수명과 참조자의 유효성에 대한 정적 분석이 가능하도록 설계되었다. 스마트 포인터는 애당초 힙에 할당되는 객체인만큼 Rust의 소유권과는 설계 목적이 다를 뿐더러 RAII 레퍼 수준에 불과하므로 기술적으로 비교되지 않는다. Rust 컴파일러는 참조자 유효성을 검증하는 borrow checker가 구현되어 있고, 모든 소유권과 수명 그리고 분기까지 보수적으로 검사한다. C++ 위원회에서도 C++ Lifetime Profile이란 제안서를 통해 유사한 개념을 C++에 추가해야 한다는 언급이 나오고 있다.

C++ 창시자는 Rust를 포함한 다른 언어들의 메모리 안전성이 C++에 비해 특별한 게 없다고 주장하지만, 현실적으로 그리고 통계적으로 그의 주장이 사실과 거리가 멀다는 것이 드러나고 있다. 구글은 지난 수년간 이미 Android에서 C/C++를 다른 메모리 안전 언어로 대체함으로써 보안 취약점이 70% 이상 감소했다는 통계를 보여주었다. NSA가 공개한 가이드라인에는 C/C++가 메모리 안전 문제로 보안 취약점에 노출되기 쉽기 때문에 GC 언어나 Rust와 같은 메모리 안전 언어를 사용할 것을 권장했다. # 백악관도 NSA와 같은 주장을 공개성명을 통해 지지한 바 있는데, C++ 창시자가 이에 대해 "C스타일의 취약한 포인터 관리 문제를 피할 수 있는 기법들이 마련되어 있으며 정부가 이를 간과하고 있다"며 반박한 바 있다. # C스타일을 피한다고 하더라도 제대로된 성능을 위해서는 포인터나 참조자를 사용해야 하며 수명 관리를 잘못하면 보안 취약점으로 이어지는 건 매한가지다.

D언어처럼 Rust도 결국 사장되지 않겠냐는 언급도 있었는데, Rust는 D언어와 달리 이미 성공적인 상업적 사용 사례가 상당수 존재한다. Rust는 구글이나 아마존이 클라우드에 적극적으로 사용하고 있고, 디스코드가 Go로 작성된 서버를 필요에 따라 대체하며, 리눅스 커널 모듈을 작성하기 위한 언어로 새로 추가되기도 했다. 'C++를 대체할 것인가'와 관계없이 안전하고 빠른 고생산성 언어로서 충분히 메리트가 있다는 점을 알 수 있다. 비용을 들여가며 기존의 레거시 코드를 강제로 세대 교체 할 이유는 없다. 앞으로 세상에 내놓아지는 물건들이 RustSwift 등 이쪽 계열의 현대적인 언어들로 만들어진다면 그것만으로 Rust의 향후 생태계 조성에 대한 잠재성은 충분하다.

Rust는 C++의 단점을 상당히 해결하여 충분히 대체할 수 있을 듯 싶지만 아직 C++에 비해서 점유율이 많이 밀린다.
  1. 시장 점유율
    Rust는 아직 대부분의 기업이나 정부 기관 입장에서 생소한 편이다. 프로그래밍 언어는 대세가 바뀌기까지 짧아도 10년은 걸린다. 단적으로 Python이 현재의 인기에 도달하기까지 30년이 걸렸다. 특히나 Rust가 목표로 하는 시스템 프로그래밍, 커널 프로그래밍 등등이 대체로 보수적인 분야들이다 보니 구직이나 채용이 제한적이고 어렵기 때문에 성장이 더딘 편이다. C++로 작성된 기존의 프로그램을 유지 보수만 하는 마당에 Rust로 뭔가 덧붙이거나 다시 작성하지는 않을 것이다. 아직도 MFC 같은 레거시 라이브러리를 쓰는 경우도 적지 않다.
  2. 언어적 특성
    지난 50년간 수많은 프로그램이 필요에 따라 여러 언어로 작성되었는데, 이를 다시 새로운 언어로 재작성하려면 많은 시간과 자원이 요구된다.[35] Rust는 생소한 개념이 상당수 도입되었고 강제되는 부분[36]이 있기 때문에 재작성을 위해서는 구조를 갈아 엎어야 할 수도 있다. C언어 프로젝트는 의존성이 낮은 외부 모듈부터 바꿔나가는 식으로 재작성할 수 있겠지만, C++ 프로젝트는 기본적으로 OOP가 적극 활용되기 때문에 Rust의 개념과 잘 맞지 않고 상호작용이 어렵다. Qt와 같이 다중 상속을 사용하는 등의 복잡한 라이브러리는 바인딩이 매끄럽지 못하다.
  3. 불편함
    Rust는 강타입 언어인데다 엄격하게 검사하기 때문에 작성에 시간이 걸리는 편이다. 복잡한 참조자의 경우 수명 파라메터를 직접 지정해줘야 하는데, 이때 발생하는 에러의 복잡성에 초보 개발자들은 이해하지 못해서 골치를 앓게 된다. 모든 에러는 매칭을 통해 처리하거나 panic을 발생시켜 종료하도록 설계한 점은 명시적인 표현을 통해 개발자 실수를 줄이기 위한 결정이었으나 필연적으로 불편할 수 밖에 없다. 컴파일러가 다른 언어와 비교해서 원인을 쉽게 설명해주고 수정안을 제안해주는 편이긴 하다.
6.2.1.1. 결론
현재까지 Rust는 C++에 비해 사용자가 적어서 열세인 모습을 보이고 있다. 그러나 D언어와 달리 많은 기업에서 관심을 가지며 성공적인 도입 사례가 많은 만큼, Rust의 상대적 편의성과 안전한 코딩 방법으로 인해 장기적으로 볼 때 C++의 강력한 대안이 될 수 있다. 다만, 이미 검증된 기존 프로젝트를 뒤엎고 Rust로 재작성한다는 것은 매우 큰 개발비 비용을 초래하며 그에 비해 이득이 크지 않기 때문에 지양될 것이며, Rust는 새로운 프로젝트에서 사용될 가능성이 높다.

다만 최근 구글 보안 팀의 발표에 따르면, 장기적으로 보안이 필요한 부분에서는 잠정적인 위협이 존재하는 C++코드를 들어내고 대체하려 한다고 발표해서, 기존 코드들도 필요에 따라선 많은 회사에서 C++에서 Rust로 대체할 것으로 보인다. 심지어 2024년 2월 미국 백악관과 국방부도 C 언어 대신 Rust로 대체할 것을 촉구하고 미국 국방 고등 연구 계획국(DARPA)에서 C 언어에서 Rust로 자동 번역 하는 연구를 지속하고 있다. 그리고 이 과정에서 대한민국 KAIST 전산학부의 류석영 교수 주도 연구 팀은 C 언어의 union을 Rust의 tagged union으로 자동 변환하는 기술을 최초로 개발했다. 관련 보도.

6.2.2. Rust vs. Zig

파일:상세 내용 아이콘.svg   자세한 내용은 Zig 문서
#!if (문단 == null) == (앵커 == null)
를
#!if 문단 != null & 앵커 == null
의 [[Zig#s-|]]번 문단을
#!if 문단 == null & 앵커 != null
의 [[Zig#|]] 부분을
참고하십시오.

C++를 대체할 언어로 주목받고 있으나, Zig는 Rust보다 4년 늦게 공개되어 아직 유저 풀이 Rust만큼 넓지 않다. 무엇보다 1.0 버전이 릴리스된 후 [age(2015-05-15)]년이 지난 Rust와 다르게, Zig는 [age(2016-02-08)]년이 지나도 아직 최초 안정 버전조차 나오지 않은 채 활발하게 개발되고 있다.

6.2.3. Rust vs. Carbon

파일:상세 내용 아이콘.svg   자세한 내용은 Carbon 문서
#!if (문단 == null) == (앵커 == null)
를
#!if 문단 != null & 앵커 == null
의 [[Carbon#s-|]]번 문단을
#!if 문단 == null & 앵커 != null
의 [[Carbon#|]] 부분을
참고하십시오.

Go, Dart를 개발한 구글C++를 대체하기 위해서 2022년에 발표한 프로그래밍 언어이다. 위에 상기한 바와 같이 Rust의 최대 단점은 C++로 쓰여진 수없이 많은 기존 인프라와 호환에 문제점이 있다는 점인데, 이를 보완하기 위해 'C++와 양방향 상호 호환'을 철학으로 삼고 있다. (뉴스 기사)

다만 Carbon의 경우 제대로 된 컴파일러도, 심지어 인터프리터조차도 아직 없기 때문에 현 상황에서 비교는 무의미하다.

6.3. 사용 현황

6.3.1. Rust를 사용하는 기업 및 단체

6.3.2. Rust로 제작된 것들

7. 비판

파일:상세 내용 아이콘.svg   자세한 내용은 Rust(프로그래밍 언어)/비판 문서
#!if (문단 == null) == (앵커 == null)
를
#!if 문단 != null & 앵커 == null
의 [[Rust(프로그래밍 언어)/비판#s-|]]번 문단을
#!if 문단 == null & 앵커 != null
의 [[Rust(프로그래밍 언어)/비판#|]] 부분을
참고하십시오.

8. 학습 자료

8.1. 도서

8.1.1. The book

러스트 프로그래밍 공식 가이드
The Rust Programming Language
파일:The Rust Programming Language 2024.jpg 파일:러스트 프로그래밍 공식 가이드 2021.webp
원서 한국어 번역서
온라인 보기 한국어 번역문

이 책은 러스트의 공식 가이드이자 오픈 소스 서적인 the book을 그대로 책으로 옮겨 출판한 것이다. 국내 출판은 제이펍이 맡았다.

국내 출판서의 번역과는 별개로 the book자체를 포크해 기여자들이 자발적으로 번역한 한국어 번역이 있다. 그 외 언어에 대한 번역은 이곳에서 찾을 수 있다.

책 자체가 하나의 Git 저장소이기 때문에 최신 내용들이 제때 업데이트되며, 누구나 PR할 수 있기 때문에 오탈자 또한 적은 편이다. 종이 책 특성상 자주 개정하는건 어렵기때문에, 웬만해서는 the book을 직접 참조하는것을 추천한다.

여담으로 문서 툴로는 mdBook을 사용한다.

8.1.2. 그 외

8.2. 유튜브

8.3. 웹 사이트

9. 기타


메모리 보안이 뛰어나다는 장점이 있지만 이걸 해커가 악성코드, 랜섬웨어를 제작할 경우 이것을 분석하거나 탐지하기 매우 어렵다고 한다..

10. 관련 링크


[1] 그레이던 호어는 이 뒤로도 한동안 수석 개발자로 개발에 참여하고 있다가, 2013년에 수석 개발자 지위를 내려놓은 상태이다.[2] 첫 발표 시기와 1.0 정식판(stable release) 출시 시기 둘 다 3년씩 늦게 나왔다.[3] Resource Acquisition Is Initialization의 약자로 C++에서 유래된 개념이다. 객체의 소멸자에 자원 수명을 묶어서 스코프를 벗어나면 자동으로 자원이 해제되도록 한다.[4] 일반적인 객체 지향 프로그래밍 언어와 비교해서 상당한 차이가 있다. Rust는 의도적으로 객체 상속을 지원하지 않도록 설계되었으며, 인터페이스 역할을 하는 트레이트를 하나의 객체에 여러 개 합성하는 시스템을 가지고 있다. 트레이트는 말 그대로 객체의 특성을 나타내며 상속이 가능하다. 예를 들자면 Clone 트레이트는 객체가 복제될 수 있음을 나타내는 동시에 복제 인터페이스를 제공한다.[5] unsafe 스코프를 사용하지 않는다는 전제하에 dangling pointer, double-free, use-after-free 같은 메모리 버그를 작정하고 도입하려 해도 아예 원천적으로 불가능하다. 단, 러스트는 공식적으로 메모리 누수에 대해 보호를 보장하지는 않는다. 보다 정확히 말하자면 Rust는 모든 종류의 undefined behavior를 차단하는 것을 목표로 한다. 메모리 누수나 데드락과 같은 버그는 버그일지언정 예측 가능한 동작을 하기에 undefined behavior는 아니다.[6] 정확히는 오버헤드가 큰 '추적 기반 쓰레기 수집' 을 사용하지 않는 것이고, Rc<T>, Arc<T> 등의 스마트 포인터에 '참조 기반 쓰레기 수집'이 구현되어 있다. 이미 Rust 및 C++로 작성되는 많은 프로그램에서 스마트 포인터를 자주 사용하고 있다.[7] 1.32 이전에는 메모리 할당자인 jemalloc을 기본적으로 사용했기 때문에 속도는 좀 더 빨랐지만 OS 입장에서는 항상 사용하는 만큼만 메모리를 할당받는 것은 아니었다. 원하는 경우 라이브러리를 활용하거나 직접 구현해 메모리 할당자를 바꿀 수 있다.[8] 값이 이동할 때 새로 메모리를 할당하고 메모리를 복사할지, 그냥 주어진 메모리 영역을 그대로 쓸지 결정하는 것은 컴파일러의 몫으로, 최적화하기에 따라서는 함수로 인자를 넘기고 리턴받는 동안 단 한 번의 메모리 복사도 일어나지 않을 수도 있다. C++를 아주 잘 알고 있다면, RVO라는 약어가 익숙할 것이다.[9] 그렇지만 실제 컴파일러에서 수명과 관련한 오류를 확인하는 방식은 '책을 빌린 사람이 있으면 그 전에는 도서관 문을 닫지 마시오'가 된다.[10] std::thread::scope를 사용하는 경우 멀티스레드 참조가 가능하다.[11] C++ TS의 std::expected와 비슷하다.[12] 타입 TU의 합집합. 다른 언어에서는 주로 T | U로 표기한다. TypeScript식 표기를 기준으로 '문자열 또는 숫자를 아이템으로 가지는 배열의 타입'은 Array<number | string>와 같이 표시한다.[13] Rust의 ABI는 안정적으로 제공되지 않으므로 이러한 내용은 언제든지 바뀔 수 있다.[14] 다른 언어를 기준으로 설명하자면, Java8 이후의 Java interface와 매우 비슷하다. 물론 차이는 있다.[15] C++20의 Concepts 기능과 유사한 역할을 한다.[16] 코루틴은 서브루틴을 일시 정지하고 재개할 수 있는 구성 요소를 말한다. 쉽게 말해 필요에 따라 일시 정지할 수 있는 함수를 말하며, 이를 활용하여 I/O 처리를 극대화할 수 있다. 이는 단순히 대기해야 하는 작업이 처리되기 전에 다른 작업을 먼저 처리하도록 할 수 있기 때문이다. 멀티스레드 환경에서도 공유 자원의 접근이 필요할 때 뮤텍스의 록을 얻지 못하는 경우, 다른 작업을 먼저 처리하도록 하여 컴퓨팅 자원의 사용을 극대화할 수 있다.[17] 단순 연산뿐만 아니라 네트워크, 파일 입출력, 타이머 등의 처리를 복합적으로 수행한다. 일반 Socket을 사용할지, epoll 등의 event 기반 I/O를 사용할지는 이 실행자 구현체의 세부 사항으로 결정된다.[18] C++에서도 C++20 표준의 Concept을 통해서 Rust의 트레이트와 유사한 정보를 컴파일러에게 제공할 수 있게 됐다.[19] 심지어는 match(타 언어의 switch)에서 default가 없는 등 빠진 논리 흐름이 있으면 컴파일이 안 된다![20] 전에 컴파일했던 코드와 현재 컴파일하는 코드를 비교하여, 변경된 부분만 다시 컴파일하는 기법이다.[21] 이는 GCC, Clang 등의 단순 컴파일러 구현체와 이를 감싸는 Make, Autotools, pkg-config, CMake 등 여러 레이어를 조합해 외부 종속성을 포함한 빌드 환경을 구성하는 전통적인 C, C++ 개발환경과 유사하다.[22] 컴파일 시에 일어나는 에러를 직접 컴파일 하지 않고 적은 비용으로 확인할 수 있다. 런타임 시 발생 가능한 에러를 최대한 컴파일 타임에 잡아내는 러스트의 특성상 사용할 일이 많은 명령어이다.[23] 내장 유닛 테스트 러너. 내부적으로 테스트만을 위한 별도의 crate-type으로 빌드된다.#[24] crates.io에서 바이너리 크레이트를 즉석으로 다운로드받아 컴파일하는 명령어. 주로 CLI 툴을 설치할 때 사용한다.[25] 컴파일 시에 일어나는 에러를 확인함과 동시에 쓸데없이 장황한 코드를 깔끔하게 만드는 방법을 제공하는 툴.[26] RLS has been deprecated and is no longer supported. It has been replaced with rust-analyzer. #[27] If you are an individual wanting to use RustRover for non-commercial purposes, you can use the IDE for free. However, if you’re planning on using RustRover for commercial purposes, you need to purchase a license, as with our other products. #[28] This project is officially deprecated. #[29] The existing open-source plugin, which we’ve been working on for a number of years, has served as the building block for RustRover. This plugin will remain open source and freely available on GitHub and the JetBrains Marketplace. However, moving forward, we will be investing our efforts into RustRover, which is closed source. For the existing open-source plugin, we’ll do our best to maintain compatibility with newer versions of our IDEs, but we won’t be fixing bugs or adding new features. #[30] 표준 라이브러리가 예외를 적극적으로 사용하기 때문에 주의해서 제한적으로 사용해야 한다. 예외 없이는 객체 생성자를 실패시킬 수 없기 때문에 two-phase construction을 사용해야 하는 것은 덤이다. OOP나 템플릿을 남발하다가 난해하거나 경직되어 하나를 고치기 위해 다 뜯어고쳐야 하는 코드가 될 수도 있다. 결국 제대로 개발하기 위해서는 C++의 한계와 개발론에 대한 이해가 상당한 수준에 도달해야 한다.[31] 사실 2021년 초부터 리누스 토발즈가 리눅스 커널 개발에 러스트 도입을 가시화하기는 했다.#[32] "we’re excited to announce that the Android Open Source Project (AOSP) now supports the Rust programming language for developing the OS itself." #[33] "our memory-safe language efforts are best focused on new development and not on rewriting mature C/C++ code." #[34] 2021년 10월, AOSP 페이지에 Rust 빌드 가이드 항목이 생겼다. #[35] C++가 아니라 COBOL을 현역으로 사용하는 곳도 존재한다![36] C++가 개념을 알아서 가져다 쓰라는 자유로운 언어라면, Rust는 용도에 맞는 정해진 개념을 쓰라는 엄격한 언어에 가깝다.[37] 언어에 마스코트가 왜 필요한지 의문이 들 수도 있는데, Go, Zig 등을 비롯한 비교적 최근에 나오는 몇몇 언어들은 고유한 마스코트가 따로 존재한다. 언어는 아니지만 유니티 엔진유니티짱이라는 마스코트가 존재한다.[38] 페리스를 위한 사이트(!)도 존재한다.[39] 디스코드 서버가 아래 서버와 함께 상당히 활동적이다. 예의만 잘 지킨다면 초보자들은 질문이 생겼을 때 여기서 상당히 친절한 답변을 받을 수 있다[40] 원래 공식 서버가 아니었으나, 정식 파트너십을 맺었다