메모리 안전성이 플랫폼에 큰 도움이 될까요?
성능도 향상될 수 있을 것입니다.
또한 Rust를 사용하면 끝없이 반복되는 디스코스 버그 문제를 줄일 수 있다고 생각합니다.
Rust로 재작성되지 않은 채로, 디스코스가 현대적인 플랫폼으로서 살아남을 수 있을까요?
Rust 개발의 용이성과 효율성을 고려하면 인력 문제는 되지 않을 것입니다.
여러분의 생각은 어떠신가요?
직접 포팅을 자원하신 건가요? 
Jeff는 왜 Ruby를 사용하는지에 대한 블로그 글을 썼습니다:
아마도 Rust(예)가 등장하기 전에 작성된 글일 테지만, 분명 몇 가지 근거를 제시해 줄 것입니다.
맞아요, 하지만 마이크로소프트도 러스트(Rust)로 향하고 있죠.
제프는 이제 러스트가 더 우월하다는 걸 분명히 알고 있을 거예요.
피와 땀과 눈물을 흘리면 12~16일 안에 해낼 수 있어요. 아직 은퇴하기엔 좀 젊죠.
루비나 포스트그리스의 새 버전으로 업그레이드하는 데 최소 12~16일은 걸린다고 확신합니다. 루비 코드가 약 60,000줄이거든요.
레일즈(Rails)를 대체할 것은 무엇일까요?
마이크로소프트는 매우 깊은 자금력과 자원을 갖추고 있습니다.
코어와 모든 플러그인을 다시 작성해야 합니다.
이 경우 로드맵도 보류되어야 합니다.
가능성은 있습니다. 하지만 테스트와 디버깅도 필요합니다.
현재 디스코urse 사용자는 사이트가 깨질 가능성이 높습니다.
개인적으로 팀이 이 작업을 진행한다면, 디스코urse2 메타와 같은 플러그인 포크를 포함하여 베타 테스터와 함께 장기간 포크로 작업해야 한다고 생각합니다.
따라서 현재 자원을 분산하여 기존 Ruby를 유지하면서 이식 작업을 병행하는 것은 합리적이지 않을 것입니다.
실수인가요? 월(months)을 의미하신 건가요?
Discourse와 유사한 규모와 범위의 프로젝트 중, 이렇게 짧은 기간 내에 해당 포팅이 완료된 사례가 하나라도 있는지 알려주실 수 있나요?
데이비드 메긴슨이 서술한 프로세스가 꽤 익숙하게 들릴 것 같은데요:
엘리트(고수) 개발자들은 현재 사용 중인 프로그래밍 언어를 사용하는 무리(riff-raff)가 너무 많다는 것을 깨닫고, 자신의 평범한 동료들과 더 잘 구별될 수 있는 무언가를 찾기 시작합니다.
엘리트 개발자들은 현재 겪고 있는 불편함 목록을 들고, 그런 불편함이 apparently 더 적은 것으로 보이는 새로운, 잘 알려지지 않은 언어를 찾습니다.
엘리트 개발자들은 새로운 언어의 개발을 주도하기 시작하며, 코드 기여, 라이브러리 작성 등을 수행한 후 새로운 언어를 전도합니다. 서브-엘리트(시니어) 개발자들은 엘리트 개발자들을 따라 새로운 언어로 이동하여 책, 교육 등에 대한 시장을 창출하고, 언어의 개발과 테스트를 가속화합니다.
막대한 영향력을 가진 서브-엘리트 개발자들(엘리트 개발자들은 프로덕션 개발 팀보다는 연구 프로젝트에서 고립된 상태로 일하는 경향이 있음)은 직장 내에서 새로운 언어 사용을 추진하기 시작합니다.
대다수의 일반 개발자들은 새로운 언어를 배우기 위해 책을 사고 수업을 들어야 한다는 사실을 깨닫습니다.
엘리트 개발자들은 현재 사용 중인 프로그래밍 언어를 사용하는 무리(riff-raff)가 너무 많다는 것을 깨닫고, 자신의 평범한 동료들과 더 잘 구별될 수 있는 무언가를 찾기 시작합니다.
어떤 기술을 사용하느냐는 중요하지 않습니다, 그것이 동작하고, 당신과 사용자 모두가 그것에 만족하는 한 말입니다.
그것이 새로운 것들의 아름다움입니다: 항상 새로운 것이 등장합니다. 새롭고 반짝이는 것들을 추구하는 것이 우연히도 당신의 목표가 되지 않도록 하세요. 까마귀 개발자(magpie developer)가 되는 것을 피하고, 반짝이고 새로운 것을 추구할 때 선별적으로 접근하면, 당신은 더 나은 개발자가 될 수 있을 것입니다.
와. 농담이었길 바라요.
여기서 물어볼 수도 있겠네요, 아시는 분 계실지도 몰라서요 
아니, 왜 그렇게 말해?
아마도 Rust 애호가들이 Discourse를 사용 중이기 때문일까요? 아니면 포트팅에 단 이틀의 업무일만 걸린다면, 그냥 운동 삼아 재미로 이미 해버렸을까요?
이 스레드에 너무 충격을 받아서 오늘 약은 안 먹어도 될 것 같아요 
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일은 아무도 작업을 시작하기 전에 계획에만 소요될 시간이 될 것입니다.
제가 가장 생산적인 개발자는 아닐지 몰라도, Poll 플러그인을 Glimmer Components로 마이그레이션하는 데만 3주가 걸렸어요 (게다가 언어 변경도 아닌데 말이죠!)
Rust나 Ruby에 대해서는 잘 모르지만, 지난 1년간 CDCK 팀이 Ember 5와 Glimmer 컴포넌트로 프론트엔드를 재작성한 작업에서 놀라운 성과를 거두었다고 느낍니다. 실제로 표준화된 컴포넌트와 스타일을 갖춘 프론트엔드 재구성과 함께 진행되었습니다. 이 작업 뒤에 담긴 조율된 노력과 목적에 깊은 인상을 받았습니다. 
따라서 제 생각에는 그들이 현대화할 부분을 올바르게 선택한 훌륭한 결정을 내렸다고 생각합니다. 덕분에 Discourse가 현대적인 느낌을 유지하고 사용하기 즐거운 플랫폼으로 남을 수 있었기 때문입니다!
Manuel님, 스타일(CSS) 관련해서 어디에 문서화가 되어 있나요? 주요 변경 사항으로 무엇을 꼽으시나요? 현재 Discourse의 CSS 코드 구조가 이전보다 작업하기가 더 어려워졌다고 느끼시나요?
스타일 측면에서 제가 주요 변화로 보는 것은 다음과 같습니다.
저에게는 이로 인해 Discourse를 커스터마이즈하는 것이 훨씬 쉽고 정확해졌습니다. 하지만 개인의 작업 지식 수준에 따라 다를 거라고 생각합니다. CSS에 익숙하지 않고 단순히 몇 가지 조정만 하고 싶은 분들에게는 이제 학습 곡선이 더 가팔라졌을 수도 있다고 생각합니다.
문서화에 관해서는 스타일 가이드를 확인해 보실 수 있으며, 사용 가능한 커스텀 프로퍼티를 스캔하는 가장 쉬운 방법은 브라우저의 개발자 도구를 사용하는 것입니다. Documentation 도 재구성되고 있습니다. 현재 #documentation:developer-guides에는 Themes & Components와 Interface 두 섹션이 있습니다. 하지만 단순히 몇 가지 커스텀 스타일을 선언하는 것과 컴포넌트를 작성하는 것 사이에는 큰 차이가 있습니다. 이 중 일부는 개발자 토픽 사이에 너무 깊이 묻혀 있는 건 아닌지 궁금합니다. 
다른 언어로 포팅할 계획이라면 Go가 더 나은 선택지일 것으로 예상합니다. 웹 관리자가 선호할 만한 장점 중 하나는 정적 바이너리를 제공하기 때문에 재빌드가 필요 없다는 점입니다. 이는 컨테이너가 대부분 불필요해짐을 의미합니다. 사실 Discourse에서 절실히 필요한 기능 중 하나는 웹 서버와 다른 머신에서 앱을 빌드할 수 있는 능력입니다. 현재 최소 사양의 가장 저렴한 VPS에서는 빌드하는 데 거의 10분이 걸립니다. 워크스테이션에서 로컬로 빌드한 후 최종 바이너리를 웹 서버로 전송하여 실행할 수 있다면, 이 시간은 훨씬 단축될 것입니다. Go와 같은 언어는 크로스 컴파일을 매우 쉽게 수행할 수 있으므로, M1 Mac에서 빌드한 후 x86 웹 서버에 배포하거나(또는 ARM으로만 빌드, 전송, 배포하는 것도 가능) 할 수 있습니다.
현재 빌드 중에 가장 많은 시간을 차지하는 것은 프론트엔드 컴파일인 것 같습니다. 따라서 "Go를 쓸지 말지"는 빌드 시간과는 무관합니다.
Rust도 Go도 프론트엔드를 대체하는 것이 아닙니다 …
(참고로 저도 Go를 좋아합니다 … )