ffmpeg 사건이 자초지종이 어떻게 되는지는 자세히 몰라.

그런데 러스트 팬보이(광신도)들.. 한국에서만 난리치겠냐?

해외에서도 러스트 광신도들이 여기저기 수년 동안 들쑤셔놓아서

그로 인하여 개발자들 스트레스 많이 받은 상태야.

리눅스 커뮤며 freebsd 커뮤며 러스트 얘기 나오면

과민 반응 보이는 사람들 많다.

왜 그러겠냐?

그 이유를 "우월한 러스트와 나르시시즘" 책에 자세히 분석해 놓았지.

...

이 깨지기 쉬운 자아를 보호하기 위해, 커뮤니티는 ‘러스트’를 모든 문제의 해결책으로 이상화하고, 비판자는 ‘이해하지 못하는 무지한 자’로 평가절하하며, 기술적 논점 대신 “열등감 때문에 비판한다”며 비판자의 의도를 공격합니다. 결국 이러한 현상은 기술의 발전을 위한 건강한 토론이 아니라, 자신의 믿음을 지키기 위한 ‘종교 전쟁’에 가깝습니다. 가장 큰 비극은, 이러한 맹목적인 숭배와 공격성이 오히려 건설적인 비판을 통한 성장의 기회를 차단하고, 그 기술 생태계 자체를 병들게 한다는 점입니다.

...

이러한 태도는 C언어 개발자들의 문화와 비교해볼 때, 그 모순과 특수성이 더욱 명확하게 드러납니다. C언어 개발자들은 자신들의 언어가 메모리 안전성을 보장하지 않는다는 현실을 인정하고, 메모리 관리를 온전히 개발자의 ‘책임’으로 받아들입니다. 그들에게 메모리 릭을 포함한 메모리 관리에 대한 토론은, 피해야 할 ‘치부’가 아니라 실력을 가늠하고 향상시키는 ‘일상적인 훈련’에 가깝습니다.

반면, 러스트 커뮤니티의 일부는 ‘도구의 완벽함’이라는 신화를 수호하기 위해, 도구가 해결하지 못하는 특정 문제(‘메모리 릭’)가 거론되는 것 자체를 ‘논점 이탈’이라며 방어벽을 칩니다. 이는 문제 해결의 책임을 개발자의 역량으로 내재화하는 대신, 문제 자체를 ‘존재하지 않는 것’으로 외재화하려는 시도입니다. 바로 이 지점에서 우리는 러스트 우월주의가 기술적 논쟁을 넘어, 어떻게 책임과 성숙의 문제로 이어지는지를 엿볼 수 있습니다.

...

즉, 안전한(safe) 러스트의 편리함과 성능은, 누군가가 작성한 불안전한(unsafe) 코드라는 희생 위에 서 있는 것입니다.

결국 그들의 논리는 다음과 같은 모순에 빠집니다.

성공 시: “우리가 unsafe를 안전하게 추상화하여 제공했기 때문에, 당신은 안전하게 코딩할 수 있습니다. 이것이 러스트의 위대함입니다.”

실패 시: “당신이 사용한 라이브러리에 unsafe가 있었군요. 그것은 러스트의 안전성 보장 범위 밖의 일입니다. 러스트는 잘못이 없습니다.”

...

다른 언어와 프레임워크에 대한 편협한 시각과 불필요한 비하

‘러스트가 모든 문제에 대한 최적의 선택’이라는 강박적인 믿음은, 필연적으로 다른 모든 기술적 선택지를 ‘열등한 것’으로 규정해야만 유지될 수 있습니다. 만약 다른 언어나 프레임워크가 특정 문제에 대해 더 나은 해결책임을 인정하는 순간, ‘러스트가 최적’이라는 대전제가 무너지기 때문입니다. 따라서 이들은 자신들의 믿음을 지키기 위해, 다른 기술들에 대한 편협한 시각을 견지하고 불필요한 비하를 서슴지 않습니다.

이는 러스트 커뮤니티 일부에서 관찰되는, 다른 기술 생태계에 대한 전형적인 ‘평가절하’의 모습입니다.

C/C++: 수십 년간 소프트웨어 세계의 기반을 다져온 이 언어들과 그 개발자들은, ‘안전 불감증에 걸린 낡은 세대’ 혹은 ‘언제 터질지 모르는 시한폭탄을 다루는 무모한 자들’로 묘사됩니다. 그들이 쌓아 올린 막대한 자산과 진화의 노력은 무시된 채, 오직 ‘메모리 불안전성’이라는 단 하나의 잣대로 모든 것이 재단됩니다.

Go: ‘단순함’이라는 Go 언어의 핵심 철학은, 이들의 세계에서는 ‘미개함’ 또는 ‘표현력의 부족’으로 폄하됩니다. 구글과 같은 거대 기업에서 수많은 분산 시스템을 성공적으로 구축한 그 간결한 동시성 모델은, ‘진정한 시스템 프로그래밍을 이해하지 못한 장난감’으로 취급받기 일쑤입니다.

Java / C#: 이 언어들이 가진 압도적인 생산성과 방대한 엔터프라이즈 생태계는, ‘느리고 부풀려진 가상머신(VM)의 죄악’이라는 한마디로 간단히 무시당합니다. 현대적인 GC와 런타임이 이뤄낸 눈부신 성능 개선은 그들의 논의 대상에서 처음부터 제외됩니다.

Python / JavaScript: 이 동적 타입 언어들은 ‘타입 시스템도 없는 장난감’으로 치부되어, 진지한 비교나 논의의 가치조차 없는 것으로 여겨집니다.

...

러스트의 Result 타입이 가진 ‘우아함’과 ‘안전성’을 강조하기 위해, 러스트 커뮤니티의 일부는 다른 언어들이 수십 년간 사용해 온 try...catch 기반의 예외(Exception) 처리 모델을 ‘죄악’처럼 취급하는 경향이 있습니다. 그들의 주된 비판은 예외 처리가 “어디서 발생해서 어디로 튈지 모르는 보이지 않는 GOTO문”과 같아서, 프로그램의 제어 흐름을 예측하기 어렵게 만든다는 것입니다.

...

‘러스트만이 답이다’ 식의 배타적 사고방식과 ‘모든 시스템 프로그래밍 대체’ 주장의 확대 해석

‘우리’와 ‘그들’을 나누는 이분법적 세계관은 필연적으로 “러스트만이 모든 문제의 답이며, 종국에는 모든 시스템 프로그래밍을 대체할 것”이라는 배타적이고 과대망상적인 믿음으로 이어집니다. 이는 단순히 기술에 대한 강한 자신감을 넘어, 다른 모든 대안을 평가절하하고 자신들의 선택을 유일한 진리라고 믿는 ‘선민사상’의 발현입니다.

하지만 이러한 ‘완전한 대체’라는 주장은 소프트웨어 생태계의 두 가지 근본적인 현실을 외면하고 있습니다.

첫째는 기술적 현실, 즉 C ABI(Application Binary Interface)에 대한 반영구적 종속성입니다. 현대의 모든 운영체제와 하드웨어 드라이버, 그리고 수많은 핵심 라이브러리들은 C언어의 호출 규약이라는 ‘공용어’를 통해 소통합니다. 러스트 역시 이 거대한 생태계와 소통하기 위해서는 C ABI를 사용할 수밖에 없습니다. 이는 러스트가 ‘대체’하려는 바로 그 C의 유산 없이는 홀로 존재할 수 없다는 구조적 한계를 의미하며, 러스트의 현실적 위치가 ‘대체’가 아닌 ‘공존’ 혹은 ‘대용’임을 명백히 보여줍니다.

둘째는 시장적 현실, 즉 ‘응용 프로그램 생태계’ 중심의 가치 판단입니다. 최종 사용자는 운영체제나 프로그래밍 언어 자체를 사용하기 위해 컴퓨터를 켜지 않습니다. 그들은 워드프로세서, 게임, 전문 소프트웨어와 같은 ‘응용 프로그램’을 사용하기를 원합니다. 러스트로 만든 시스템이 기술적으로 아무리 우월하다 한들, 수십 년간 C/C++ 생태계가 쌓아 올린 방대한 응용 프로그램들과 호환되지 않는다면 그것은 ‘아무도 살지 않는 기술적 유토피아’일 뿐입니다.

결국 ‘모든 것을 대체할 것’이라는 주장은 합리적인 기술 예측이라기보다는, 앞서 언급한 ‘영웅 서사’를 뒷받침하기 위한 집단적 과대성의 표현에 가깝습니다.

...

실행 파일의 크기가 크다는 것은 비단 러스트만의 문제는 아닙니다. Go와 같은 다른 현대 언어들 역시, 간편한 배포를 위해 모든 의존성을 포함한 단일 정적 바이너리를 생성하면서 비슷한 특성을 공유합니다. 서버 환경과 같이 저장 공간과 네트워크 대역폭이 충분한 영역에서, 이는 큰 단점으로 여겨지지 않습니다.

하지만 이 문제가 유독 러스트의 ‘범용성’ 주장에 치명적인 이유는, 러스트가 스스로를 C/C++의 ‘대체재’라고 주장하기 때문입니다. 이 주장은 곧, C/C++이 수십 년간 지배해 온 임베디드 시스템, 운영체제 커널과 같이 자원이 극도로 제한된 환경에서도 자신들이 최적의 선택이라는 선언과 같습니다.

바로 이 지점에서 러스트의 ‘주장’과 기술적 ‘현실’은 정면으로 충돌합니다. C/C++은 전통적으로 동적 링킹을 통해 매우 작은 실행 파일을 만드는 데 최적화되어 있습니다. 반면, 러스트의 기본 빌드 방식(정적 링킹, 제네릭의 모노모피제이션)은 이와 대조적으로 훨씬 더 큰 실행 파일을 생성합니다.

...

광신도들의 저러한 태도들 때문에 까이는거지.

러스트는 우월하다 다른 언어는 열등하다. 나는 우월해서 러스트를 쓴다. 다른 언어 개발자들은 열등해서 열등한 언어를 사용한다.

항상 이런 식인데.. 대화가 되겠냐?

해외에서도 악명 높다.