Rust vs C vs Assembly programming languages - FFmpeg developer explains | Lex Fridman Podcast - https://www.youtube.com/watch?v=k92DumKjoqs

Rust 프로그래밍 언어에 대해 어떻게 생각하세요? 이건 좀 밈이 된 주제죠. Kiran과 저는 의견이 많이 다릅니다. 저는 메모리 안전성이라는 개념 측면에서 그들이 하는 일이 가치 있다고 생각합니다. 그런데 어셈블리 수준의 속도를 달성할 수 있을까요? 수작업 어셈블리는요? 아니요. 그건 당연한 거고, C는 가능할 수도 있지만 저는 Rust에서 에스페란토 같은 느낌을 받아요. 마치 "우리가 이걸 해결할 거야, 이런 방식으로"라는 느낌이랄까요. 좀 지나치게 이상주의적이에요. 실제 문제를 해결하기보다 자기 중요성에 집중하는 경향이 있어요. 저한테는 싱클레어 C5가 생각납니다. 싱클레어 컴퓨터의 클라이브 싱클레어 경이 차를 만들면서 "모두가 이 전기차를 타고 다닐 거야"라고 했는데 Rust가 그런 느낌이에요. 커뮤니티가 사람들을 움직이게 하려면 지금 있는 것만큼, 아니면 그보다 더 나은 걸 만들어야 한다는 걸 잘 이해하지 못하는 것 같아요. 네, 사람들이 Rust로 재작성을 하고 있지만 Core utils 같은 것들이 필요한 기능의 85~90%만 구현된다면, 마지막 1%가 시간의 99%를 차지하죠. 일론의 유명한 말처럼, 프로토타입은 쉽고 이런 건 쉽지만 진짜 전기차를 만들려면 지금 있는 차만큼, 아니면 더 나은 차를 만들어야 해요. Rust는 아직 그 단계가 아닙니다. FFmpeg에 Rust 코드가 들어오는 걸 반대할 사람은 없겠지만 동일한 수준으로 작동하고 같은 단위 테스트를 지원해야 해요. 완벽해야 하고, 무작위로 망가지면 안 됩니다. 마음대로 ABI를 바꿔서도 안 되고요. 컴파일러 구현체도 아직 하나뿐인 걸로 알고 있는데, 맞죠? 지금 있는 것만큼, 아니면 더 나아야 하는데 "여기 내 메모리 안전 유토피아가 있어요"라고만 해서는 충분하지 않아요. 그게 목표라는 건 우리 모두 동의하더라도요. 저는 Rust를 많이 써봤는데, 주요 경험이 두 가지였어요. 하나는 VLC 안에 Rust 모듈을 추가하는 것이었는데, VLC가 인기를 얻은 이유 중 하나이자 핵심 아키텍처 결정은 VLC가 매우 작은 코어와 수많은 모듈로 이루어져 있다는 것이에요. 그래서 모듈을 C, Objective-C 등 C와 상호운용 가능한 언어로 작성할 수 있죠. 그래서 Rust 모듈도 만들어봤고 제가 직접 일부를 작성했어요. 또한 제 새 스타트업인 Kyber는 주로 Rust로 만들어진 오픈소스 프로젝트입니다. Rust는 메모리를 신경 쓰는 더 나은 C라는 점에서 정말 훌륭하고, 다른 언어로는 할 수 없는 메모리 소유권 관련 작업을 가능하게 해줘요. 하지만 새 프로젝트를 처음부터 Rust로 시작할 때는 좋지만 기존 코드와 연동할 때는 매우 좋지 않아요. 일부 Rust 커뮤니티는 모든 걸 Rust로 재작성하면 더 나아질 거라 믿는데 답은 그렇지 않다는 거예요. 제 수년간의 엔지니어, 매니저, 스타트업 CTO 경험상 재작성하지 마세요. 재작성하지 마세요. 코드베이스에 처음 합류한 많은 사람들의 본능적 반응은, LLM 이전에는 특히, 과거에 그렇게 구현된 지혜를 이해하지 못하기 때문에 "재작성해야 해"라고 하는 거예요. 그래서 수천 개의 JavaScript 프레임워크가 생겨난 거고요. 이유는 매우 중요한데요, 코드를 작성하는 것은 코드를 읽는 것보다 훨씬 쉽기 때문입니다. LLM에서도 볼 수 있어요. 코드 작성은 할 수 있지만 분석은 훨씬 어렵거든요. 그래서 매우 복잡한 코드에 접했을 때 이해가 안 되는 거예요. 다른 사람의 코드를 이해하는 건 사고 과정이 없기 때문에 훨씬 더 많은 노력이 필요하죠. 제가 농담 삼아 Perl 같은 언어에 대해 이야기하는데, 문법이 매우 복잡해서요. 제가 프로그래밍에서 최고의 지적 능력을 발휘해서 최고의 코드를 작성한다 해도 6개월 후에는 제 자신도 이해 못 할 거예요. 코드 읽기가 더 어렵기 때문입니다. 그래서 도착했을 때 모든 지혜와 비즈니스 로직, 문서화되지 않은 이유들을 이해하지 못하고 "내가 다시 쓸게"라고 하는 거예요. 하지만 그렇게 하면 안 되죠. Kiran이 말했듯이 coreutils를 Rust로 재작성하면 금방 80%에 도달하고 90%는 조금 더 걸리고 나머지는 반대편에서 더 오래 걸리죠. 그래서 새 프로젝트에는 훌륭해요. 파일 파싱, 네트워킹 관련은 메모리 검사기인 빌림 검사기 덕분에 정말 훌륭해요. 그 외에는 달리 할 말이 없어요. 우리 경우는 좀 다른데요, Dav1d나 x264 같이 어셈블리로 된 런타임이 많은 소프트웨어를 생각해보세요. C 부분을 Rust로 재작성하면 더 안전해지겠죠. 하지만 어셈블리 부분에 도달하면 수작업 어셈블리를 작성하기 때문에 메모리 어디든 접근할 수 있어요. 그래서 보안을 위해 C 부분을 Rust로 재작성해도 수작업 어셈블리를 쓰면 보안을 모두 무너뜨리게 됩니다. 메모리 어디든 점프할 수 있으니까요. 그래서 제 생각엔 안전한 어셈블리, 즉 컴파일 타임에 어셈블리를 검사하는 것이 필요한데 이게 바로 Videolan의 Dav1d와 x264에서 진행 중인 checked assembly 프로젝트와 유사해요. 컴파일 타임에 어셈블리를 계측해서 메모리 어디로든 점프하지 않는지 확인하는 거죠. 그렇지 않으면 C 일부를 Rust로 재작성해도 동일한 성능을 원한다면 인라인 어셈블리를 쓸 수밖에 없고 그러면 전체 보안 모델이 무너지거든요. 이게 제가 Rust에 대해 생각하는 바입니다.