Rust 2024 Roadmap
Rust는 꾸준히 발전하고 있는 언어로써 그 방향성을 정하기 위해 로드맵을 발표합니다. 본 글은 지난 8월 12일 발표된 Rust Project Goals for 2024에서 언급된, 3개의 주력 목표를 설명합니다.
Goal 1. Bring the Async Rust experience closer to parity with sync Rust
비동기 Rust를 이용한 Network 프로그래밍은 현재 가장 많은 Rust 개발자가 사용하고 있는 기능입니다. 비동기 Rust를 이용해 하나의 서버로 많은 요청을 처리할 수 있고, garbage collector가 없기 때문에 소형화에도 유리합니다. 또한 24시간 돌아가는 Network 시스템의 관리를 위해서도, Rust의 신뢰성은 매우 좋은 장점이 됩니다.
하지만 비동기 Rust는 아직 갈길이 참 멉니다.
- Trait(현재는 일부 제공), Closure, Drop 등에 대한 비동기 기능을 제공하지 않고
- 예기치 못한 오류를 유발할 수 있는 edge case들이 많이 남아있습니다.
- 또한 여러 runtime 중 하나를 선택해야 하며, 상호 호환성 역시 담보하기 어렵습니다.
그렇기에 이전부터 Rust 조직은 비동기/동기 언어 일치성 강화에 집중해왔습니다.
2023년 12월에 async fn 문법과 반환 위치에서의 impl trait 문법이 안정화되었고,
std::future::poll_fn 등의 보조 도구를 안정화하며, 비동기 오류 메시지를 개선해왔습니다.
하지만 Rust의 조직적 부채의 한 면으로써, 비동기 전문가 그룹이 부재해 명확한 비전과 일관성을 유지하기 어려운 상황입니다.
이러한 맥락에서 2024년 하반기 목표는 아래와 같이 수립되었습니다.
Send bound 문제 해결
Send bound 문제란, trait 내 async fn의 반환 future가 Send trait을 요구할 때, 이를 구현할 방법이 현재 없다는 문제입니다. 이와 관련해서 여러 논의가 있고, 이 중 RFC #3654가 가장 선호되는 해결책입니다.
비동기 작업 그룹 재구성
비동기 작업 그룹을 아래의 필요를 충족하기 위해 보다 영구적인 구조로 탈바꿈시킬 것입니다.
- 비동기 관련 주제에 대한 포럼을 제공합니다.
- 비동기 Rust 책의 소스 코드, arewewebyet, futures-rs crate와 같은 비동기 관련 저장소를 관리합니다.
- 비동기 관련 문제에 대해 일반적인 팀 (ex. lang, libs-api)에 조언을 제공합니다.
async closure 안정화
현재 async closure는 보통의 rust closure를 이용하고 있고, 이런 접근법은 환경의 값을 빌려오는 것을 허용하지 않습니다.
하지만 async closure를 제공하기 위해서는 이 기능이 필수적이기에 우리는 Fn, FnMut, FnOnce bound의 async equivalent를 구현하려 합니다.
최종 목표
이 Goal의 궁극적인 목표는 비동기를 기반으로 다음과 같은 기능을 제공하는 것입니다.
- 동기 Rust와 동일한 핵심 언어 기능: async trait, dyn dispatch, async closure, async drop
- 신뢰할 수 있고 표준화된 추상화
- 간편한 시작 경험
- 기본적으로 좋은 성능과 조절을 통한 극대화된 성능
- 비지니스 요구에 맞게 사용자 지정 런타임을 쉽게 채택할 수 있도록 함
Goal 2. Resolve the biggest blockers to Linux building on stable Rust
Rust For Linux(RFL) 프로젝트는 실험적 상태로 Linux 커널에 수용되었습니다. 이는 Rust가 Locking, Linked List, Allocation 등의 C primitives와 상호 운용할 수 있어야함을 의미합니다. 하지만 현재 Rust에서는 이러한 저수준 기능이 대부분 unsafe로 구현되어 있습니다.
이러한 unsafe Rust에 대한 의존성은 Rust가 실험적 상태를 탈피하는 데 가장 큰 장애물입니다. 신뢰성 보장이 없기 때문에 각 코드는 특정한 버젼의 컴파일러로만 빌드할 수 있고, 이는 여러 커널 소스를 하나의 컴파일러로 빌드하려는 시도를 방해합니다.
RFL 맞춤형 Arc 타입
Rust는 포인터 타입을 고정하지 않는 것이 장점입니다.
흔히 많이 쓰는 Box, Rc, Arc 등의 타입들은 엄밀히 말해선 라이브러리에서 정의된 타입입니다.
이러한 타입들은 그 범용성과 편리성을 위해 비안정 기능을 활용하고 있기 때문에 안정성 관리가 중요합니다.
하지만 자신만의 smart pointer 타입을 정의하는 경우가 드물기 때문에 이는 보통 문제가 되지 않지만,
RFL에서는 독자적인 Arc 타입을 정의해 사용하고 있으며 아직 몇가지 불편한 점이 존재합니다.
- RFC #3519에서 정의된 ‘arbitrary self types’ 문제. smart pointer type에 wrapping된
Arc<Self>타입이 self type으로 사용될 수 있도록 하는 문제. - 동적 디스패치를 통해
Arc<dyn Trait>로 하여금 Trait method를 활용할 수 있도록 한다. 이를 위해서는CoerceUnsized와DynDispatchtriat을 안정화할 필요가 있다. 이를 위한 bypass를 RFC #3621에서 제안하였다.
RFL on Rust CI
Rust는 특정 중요한 외부 프로젝트를 CI에 통합해 컴파일러나 표준 라이브러리의 변경사항의 영향을 조기에 파악하도록 합니다. RFL은 이러한 CI 통합 대상으로 충분한 자격을 갖춘 프로젝트입니다.
상수의 정적 포인터 지원
RFL 프로젝트는 읽기 전용 메모리에 vtable을 생성할 필요가 있습니다(고유 주소 필요 없음). 현재 구현은 const_mut_refs 및 const_refs_to_static 기능에 의존하고 있습니다. 몇 가지 질문이 해결되어야 하지만, 큰 어려움은 없습니다.
이외에도 인라인 컴파일러의 Labeled goto와 offset_of! 의 안정화가 필요합니다.
Goal 3. Rust 2024 Edition
주요한 목표는 아래의 nightly edition들을 release하는 겁니다.