Discourse는 이미 메모리 안전성이 보장됩니다. Ruby는 메모리 안전성이 있는 언어이며, 모든 가비지 컬렉션 언어는 그러합니다. 이 점에서 Rust와의 주요 차이는 안전성 체크가 언제 수행되는가입니다. Rust는 컴파일 타임에, Ruby는 런타임에 이를 수행합니다.
Rust는 오직 일부 유형의 오류만 처리합니다. 주로 C++의 가비지 컬렉션 부재로 인한 오류입니다. 포인터를 사용하여 이론적으로 가능한 성능 이점을 유지하면서 이를 가능하게 한 것은 분명히 멋진 일이지만, 사용자가 경험하는 유형의 버그를 방지하는 것은 결코 아닙니다. 예를 들어, <=를 의도했는데 <를 사용하여 오프 바이 원(off-by-one) 오류가 발생하더라도 Rust가 저를 구해 주지 않습니다. 작업이 완료된 후 성공 메시지를 생성하는 것을 잊어버린 경우에도 Rust가 저를 구해 주지 않습니다.
실제로 버그를 방지하는 것은 Discourse가 이미 채택하고 있는 테스트 주도 개발(TDD) 방식입니다. 마스터 브랜치에서 바로 배포하여 안정성을 기대할 수 있는 프로젝트는 매우 드물지만, Discourse는 그 중 하나입니다.
백엔드와 프론트엔드 모두에 JavaScript를 사용하는 "현대적인 플랫폼"이 여기저기 쏟아져 나오고 있습니다. Ruby의 인기는 Rust보다 2위 뒤처져 있습니다(Kotlin이 그 사이에 위치하므로), 따라서 현재로서는 결코 드문 언어가 아닙니다. 물론 10년 후에는 상황이 달라질 수 있지만, Rust로의 재작성조차도 10년 후에는 기술 부채가 될 것입니다.
그 발언이 얼마나 순진한지 전달하기가 어렵기 때문에 모두가 그 아이디어를 비웃고 있습니다. 저는 개발자들이 3년 동안 코드 리팩터링을 해왔고, 이제야 wxWidgets/ShuttleGUI에서 Qt/QML로의 포트링을 시작할 준비가 된 것을 보고 있습니다. 참고로 이는 C++에서 C++로의 마이그레이션이며, 단지 다른 UI 킷으로의 전환일 뿐입니다. 동작이 동일하게 유지되는 것을 보장하면서 코드를 변환하는 것은 그저 어려운 일입니다. 12~16일은 아무도 작업을 시작하기 전에 계획에만 소요될 시간이 될 것입니다.