Hacker News 의견

• Rust의 async/await 문법 도입 전에는 수동으로 상태 기계를 구현했었음

  • Rust의 async/await 문법 덕분에 생산성이 크게 향상되었음
  • Rust의 async는 자동 상태 기계로 변환되어 I/O 지점에서 값을 저장해줌

• VT100 라이브러리를 작성하면서 Rust의 캡슐화 패턴 문제를 깨달았음

  • 캡슐화에 집착하는 것이 문제를 일으킴
  • 컴퓨터는 입력, 데이터 변환, 출력을 수행하는 기계임을 상기시킴

• 채널을 사용하여 데이터를 전송하는 디자인과 비교

  • 코드가 복잡해짐
  • 메시지 타입을 수동으로 구현해야 함
  • 송신기를 명시적으로 제공해야 함
  • 네트워크 전송 실패 시 결과를 얻지 못함
  • 그러나 편리한 점도 있음

• Haskell 생태계에서 논리와 실행을 분리하는 아이디어가 있음

  • tokio::select! 호출을 어떻게 캡슐화했는지 언급되지 않음
  • sans-IO 스타일로 캡슐화된 함수 구현에 관심이 있었음

• Rust의 async 함수는 상태 기계로 컴파일됨

  • sans-io와 async를 결합하려는 시도가 있었는지 궁금함
  • 주요 문제는 사용성 및 Pin 처리임

• 상태를 노출하면 async 함수가 '순수'해질 수 있음

  • OpenSSL을 async Rust에 바인딩하려고 시도했음

• Firezone이 놀라운 도구임

  • Rust-libp2p와 유사한 패턴을 발견했음

• 컴파일러가 async 코드를 sans io로 자동 변환할 수 있으면 좋겠음

  • 수동 변환은 오류가 발생하기 쉬움

• 기사와 댓글을 읽고 hexagonal 또는 ports/adapters 아키텍처 스타일을 재발명한 것 같음

• 실제 트래픽이 게이트웨이를 통해 지나가는지, 아니면 연결 설정에만 사용되는지 궁금함