매우 긍정적인 내용의 글이고 내 경험과도 맞아떨어짐. 다만 어두운 전망을 꼽으라면 이런 부분임:
"async는 static 바운드, 취소 안전성, 트레이트와 dyn 관련 제한 등으로 인해 비교적 높은 복잡도 비용을 가지고 있음. 현재로선 이 문제가 풀릴 기미가 없음. 동기/비동기 프리미티브 간의 분기와 생태계의 고유한 특성이 async tax(추가 비용)을 높임. Effects에 기반한 솔루션도 딱히 희망적이지 않음."
"1.0 이전 Rust에는 libgreen이라는 해법이 있었음. bifurcation(분할) 없는 사용자 공간에서 동시성을 구현했지만, 성능, 이식성, 유지보수 비용이 상당해 결국 제거됨. 엔지니어링 역량만 충분하다면 다시 고민해볼 만한 가치가 있다고 생각함. 언젠가 std::{fs, net}와 fiber::{spawn, select}를 generator로 zero-cost wrapping한 PoC를 만들고 싶음"
"'static bound이 복잡도를 높게 만든다"라는 논의는 Tokio async 러ntime의 설계 선택일 뿐 Rust 전체의 디자인이라고 보긴 어렵다는 의견임. Embassy async runtime은 이런 바운드 없이도 동작하지만, 대신 pinning을 직접 관리해야 함. 'static bound는 사실 복잡도 낮추려는 취지임
2022년 말 Rust에 빠져 공부한 사람으로서, 2015년 같이 더 힘들었던 시절에 언어를 배운 분들의 경험담이 항상 흥미로움. Rust가 더 성숙한 시점에 배울 수 있어서 이미 가파른 러닝 커브가 다소 완화된 느낌을 받았고, 그 점에서 운이 좋았다고 생각함. 요즘은 글에서 언급한 Rust 초창기 경험담을 Zig에서 다시 겪고 있는 기분임. Zig는 Rust 초창기와 비슷한 시점에 있는 것 같음. 그래도 이미 재밌게 사용 중임
"찾은 것보다 더 나은 상태로 남겨둘 것"이라는 문화가 강함. 툴이나 언어가 헷갈렸다면 사용자 잘못이 아니라는 생각이 자리잡음. 내가 혼동을 겪었다면 다른 이들도 겪을 테니, 발견할 때마다 개선하는 게 모두에게 큰 이득임. 나무 심는 데 두 번째로 좋은 때가 오늘이라는 속담이 적용됨. 이런 문화 덕분에 예전에 Rust를 시도했다가 좌절했던 사람이 1년 뒤라면 충분히 더 개선된 경험을 할 수 있음. 그래서 Rust 입문자에게 줄 최고의 조언은 "6개월만 기다려봐"였음
MSFT, Google 같은 빅테크나 Linux 등 대형 오픈소스 프로젝트에 채택된 언어라면 이미 생태계가 충분히 성숙했다는 증거임. 하지만 Zig는 아직 기존 도구들에 비해 (큰) 변화를 보여주진 못해서 그런 확신이 없음
Rust는 함수형 프로그래밍을 장려하는 느낌을 받음. 원래는 내부 상태를 advance마다 변경하는 파서를 만들다, 가변성과 빌림체계(borrowing) 때문에 힘들어서 stateless 파서로 바꿔야 했음. 내부 인덱스 수정 대신 인덱스를 반환하는 구조로 변경하게 됨. 이런 식으로 기존 방식이 잘 안 먹혀서 Rust에서 새롭게 접근해야 하는 경우가 흔한지 궁금함
나도 비슷한 경험이 있음. 단순한 경우라면 mutable, 명령형 스타일로도 문제 없지만, 복잡도가 커질수록 함수형 스타일로 바꾸고 변경을 최대한 피하게 됨. Borrow checker랑 라이프타임 때문에 전통적인 패턴이 어렵고 자연스럽게 함수형으로 가게 됨. 함수형으로 구현하는 게 익숙치 않으면 힘들 수 있지만, 컴파일러가 더 만족스러워지는 경험임
Async/await가 Rust를 사용하지 않는 유일한 이유임
사실 async/await는 Rust를 써야 할 주요한 이유 중 하나라고 생각함. 동시성 패턴을 훨씬 간단하게 만들어 주기 때문임. 초반엔 뭔가 악성 전염병처럼 모든 코드가 결국 async가 되어야만 하는 느낌이었는데, async 코드와 상호작용하는 법 알게 되니 편해짐. 보통 spawn, spawn_blocking, futures::stream이 90%의 활용도를 차지하고, 적절하게 "경계"를 세워두면 async가 전파될 필요도 없음
어느 정도 이해는 됨. 하지만 나는 Rust에서 async/await가 딱 맞아떨어져서 가장 큰 사용 이유가 됨. 문법도 좋아하고 function colouring 문제도 별로 신경 쓰지 않음. 특히 tokio를 쓸 때 필요한 표준 함수의 async 버전이 다 있어서 솔루션이 잘 풀리는 느낌임. 이런 부분이 배리어를 만들 수도 있지만, 동시성 프로그램 짜기 훨씬 쉽고 퍼포먼스도 괜찮아서 만족함. 취소(cancellation) 같은 건 좀 헤매기도 하지만, 그건 내 실력 문제라고 생각함
Hacker News 의견
"async는 static 바운드, 취소 안전성, 트레이트와 dyn 관련 제한 등으로 인해 비교적 높은 복잡도 비용을 가지고 있음. 현재로선 이 문제가 풀릴 기미가 없음. 동기/비동기 프리미티브 간의 분기와 생태계의 고유한 특성이 async tax(추가 비용)을 높임. Effects에 기반한 솔루션도 딱히 희망적이지 않음."
"1.0 이전 Rust에는 libgreen이라는 해법이 있었음. bifurcation(분할) 없는 사용자 공간에서 동시성을 구현했지만, 성능, 이식성, 유지보수 비용이 상당해 결국 제거됨. 엔지니어링 역량만 충분하다면 다시 고민해볼 만한 가치가 있다고 생각함. 언젠가 std::{fs, net}와 fiber::{spawn, select}를 generator로 zero-cost wrapping한 PoC를 만들고 싶음"