저도 나름대로 Rust를 주력 언어로 사용하는 개발자인데 화는 나지 않았으나 좀 극단적인 예시("그 프로그램을 종료할 때 너무 느리며"라며 링크된 영상에서도 Rust 프로젝트에서의 사례와 직접적 관련은 없는, Visual Studio를 종료할 때 각 개별 컴퍼넌트의 소멸자가 호출되면서 너무 오래 걸린다는 사례를 들고 있습니다)를 들고 오는 게 아닌가 싶긴 합니다.
성능상 여러 컴퍼넌트의 Clean-up이 한 번에 처리되는 것이 필요한 경우에는 개별 컴퍼넌트에 대해 Drop을 구현하는 대신 해당 컴퍼넌트들의 수명을 들고 있는 타입에서 Clean-up을 한 번에 수행하도록 Drop을 구현하는 방식을 택할 수 있을 것 같습니다. 해당 컴퍼넌트를 그 타입의 API를 통해서만 생성할 수 있게 하는 안전장치를 두면 더 좋을 거고요.
물론 위 글의 저자분이 우려하는 바는 RAII를 사용하는 관행이 Linux 코드베이스에 들어올 경우 방대한 코드베이스에서의 복잡성 속에서 굉장히 암시적인 성능 우려가 있는 코드가 누적되면서 장기적으로 Visual Studio와 유사한 일이 벌어질 수 있다는 점일 것 같은데 이는 충분히 우려할만한 지점인 것 같습니다. 다만 다른 댓글에서 말씀하신 것처럼 RAII가 제공하는 안정성도 있으니 선택은 다소 트레이드오프라고 봅니다.
저도 나름대로 Rust를 주력 언어로 사용하는 개발자인데 화는 나지 않았으나 좀 극단적인 예시("그 프로그램을 종료할 때 너무 느리며"라며 링크된 영상에서도 Rust 프로젝트에서의 사례와 직접적 관련은 없는, Visual Studio를 종료할 때 각 개별 컴퍼넌트의 소멸자가 호출되면서 너무 오래 걸린다는 사례를 들고 있습니다)를 들고 오는 게 아닌가 싶긴 합니다.
성능상 여러 컴퍼넌트의 Clean-up이 한 번에 처리되는 것이 필요한 경우에는 개별 컴퍼넌트에 대해 Drop을 구현하는 대신 해당 컴퍼넌트들의 수명을 들고 있는 타입에서 Clean-up을 한 번에 수행하도록 Drop을 구현하는 방식을 택할 수 있을 것 같습니다. 해당 컴퍼넌트를 그 타입의 API를 통해서만 생성할 수 있게 하는 안전장치를 두면 더 좋을 거고요.
물론 위 글의 저자분이 우려하는 바는 RAII를 사용하는 관행이 Linux 코드베이스에 들어올 경우 방대한 코드베이스에서의 복잡성 속에서 굉장히 암시적인 성능 우려가 있는 코드가 누적되면서 장기적으로 Visual Studio와 유사한 일이 벌어질 수 있다는 점일 것 같은데 이는 충분히 우려할만한 지점인 것 같습니다. 다만 다른 댓글에서 말씀하신 것처럼 RAII가 제공하는 안정성도 있으니 선택은 다소 트레이드오프라고 봅니다.