Hacker News 의견

• Async/await와 단일 스레드

  • 자바스크립트 모델처럼 단일 스레드에서의 async/await는 단순하고 잘 이해되어 있음.
  • 스레드를 사용하면 여러 CPU가 문제를 처리할 수 있고, Rust는 락 관리를 도와줌.
  • 다른 우선순위의 스레드를 가질 수 있으며, 계산에 제한이 있는 경우 필요함.
  • 멀티 스레드 async/await는 복잡함. 계산에 제한이 있는 섹션에서는 모델이 붕괴될 수 있음.
  • Rust에서 멀티 스레드 계산은 잘 작동하지 않음. 문제점으로는:
    • Futex 혼잡 붕괴: 일부 저장소 할당자에서 문제가 될 수 있음.
    • 불공정한 뮤텍스의 기아: 표준 Mutex와 crossbeam-channel 채널이 불공정함.

• Async/await 대 스레드

  • 비판은 복잡성에 관한 것이 아니라, 선택에 따라 생태계가 분열되고 하나가 열등해지는 것에 대한 것임.
  • Rust 생태계는 IO 작업을 하려면 전부 async/await를 사용해야 한다고 결정함.
  • Rust가 async/await 이외의 것들을 더 조합 가능한 추상화로 만들었다면 불만이 사라졌을 것임.

• 기사에 대한 문제점

  • 웹 서버 예시 하나만 제시되었고, 스레드에 대해 잘못 해결됨.
  • 프로그래머들은 OS 스레드가 아닌 개념적, 의미적 스레드를 원함.
  • OS 스레드는 비용이 많이 들고, 우리는 저렴한 스레드를 원함.
  • 웹 서버 예시에서의 타임아웃 구현 문제점.

• 다루지 않은 순간들

  • async/await는 단일 스레드에서 실행되므로 락이나 동기화가 필요 없음.
  • async/await에서의 오류 전파는 명확하지 않음.
  • 네트워크 I/O에서 백프레셔도 언급되어야 함.

• 취소에 관한 중요한 점

  • 미래의 어떤 작업도 쉽게 취소할 수 있음.
  • 스레드에서의 취소는 복잡하고, 강제 스레드 중단은 신뢰할 수 없음.
  • Rust의 async 모델에서는 모든 futures에 외부에서 타임아웃을 추가할 수 있음.

• Async/await에 대한 마케팅 같은 캠페인

  • async/await는 기술적 실수였으며, 커뮤니티에 큰 비용을 초래함.
  • Rust는 여전히 가장 좋은 언어이지만, 이 논쟁이 영원히 이어질까 걱정됨.

• Async/await 대 파이버

  • Rust는 이전에 그린 스레드를 가졌었고 의도적으로 제거됨.
  • futures를 언제든지 드롭할 수 있는 능력이 큰 비용을 수반함.
  • async/await의 조합성을 칭찬하는 것은 이상함.

• Rust의 async/await 주요 이점

  • 스레드나 동적 메모리가 없는 상황에서도 작동할 수 있음.
  • 동시성을 사용하여 코드를 간결하게 작성할 수 있음.

• Async/await에 대한 오해

  • 단일 스레드에서의 동시성 메커니즘이 필요한 이유를 이해하지 못하는 사람들이 있음.
  • UI 프로그래밍, GPU와의 통신, 런타임 간 통신 등에 async/await가 유용함.

• Async/await 대 스레드 선택 이유

  • async/await는 클라이언트/요청/작업 상태의 메모리 사용량을 줄일 수 있음.
  • 상태 압축은 메모리 속도가 느린 현대에서 성능에 중요함.
  • async/await와 CPS는 클라이언트당 메모리 사용량을 줄이는 데 효과적임.