Async Rust: 스케줄러는 어디에 있는가?

동시성에는 스케줄링을 담당할 런타임이 필요하며, async 대신 스레드를 쓰면 그 역할이 Tokio에서 커널로 옮겨갈 뿐임 Rust가 런타임을 크레이트로 분리한 것은 임베디드, no_std, FFI 비용, 제로 비용 추상화라는 목표에 맞는 선택이지만, 런타임 간 호환성과 Send + 'static 제약 등의 부담을 낳음 async Rust의 복잡성은 동시성 자체의 문제와 스케줄러를 라이브러리에 둔 설계의 문제로 나눠야 하며, 모든 용도에 최적인 스케줄러나 항상 최소 크기인 Future를 기대할 수는 없음 Tokio의 암묵적 실행기 문맥은 함수 시그니처에 드러나지 않는 의존성을 만들고, 같은 함수도 호출하는 스레드에 따라 런타임 패닉을 일으킬 수 있음 Zig처럼 I/O 인터페이스를 명시적 매개변수로 전달하면 스케줄러 교체와 런타임 독립성을 확보할 가능성이 있지만, 아직 실전에서 검증되지 않았으며 Rust에 전면 도입하려면 표준 라이브러리 API 재설계가 필요함 async Rust에 쌓인 불만들 async Rust에 대한 흔한 불만은 5×5 빙고판을 채울 만큼 다양하며, 언어 기능, 런타임, 메모리 관리, 취소 안전성 문제가 서로 얽혀 있음 빌림, 함수 색상, 런타임 의존성 Scoped task trilemma에서는 대략 동시성, 병렬성, 빌림 중 둘만 선택할 수 있음 leakpocalypse와 연결된 문제로, 메모리 누수가 가능한 Rust에서는 소멸자 실행을 보장할 수 없으며 초기 scoped threads API는 이 때문에 데이터 경합을 허용했음 함수 색상(function coloring) 논쟁은 Bob Nystrom의 글에서 널리 알려졌으며, Without Boats의 논의를 비롯해 용어의 의미 자체에도 합의가 없음 async 클로저는 도입까지 약 6년이 걸렸음 반환하는 Future가 클로저의 캡처를 빌릴 수 있어 빌려주는 방식(lending)이 필요하며, 관련 논의는 고차 타입으로도 이어짐 Tokio 중심주의는 Tokio만을 중요한 런타임으로 취급하거나 Tokio에만 해당하는 특성을 async Rust 전체의 특성으로 오인하는 문제임 Corrode.dev의 정리에서 관련 내용을 확인할 수 있음 “그냥 스레드를 쓰라”는 견해는 async가 필요한 사람이 거의 없으며, 동시 연결 1만 개 이상을 처리하는 서버가 아니라면 스레드 풀로 충분하다는 식으로 나타남 소멸, 실행, 생태계 분리 복잡한 컴파일러 오류와 실...