Hacker News 의견들

• 모든 프로젝트나 프로그래머가 Rust나 Zig를 쓰지 않는 이유를 굳이 정당화할 필요는 없다고 생각함
  Hacker News나 다른 플랫폼에서 이 언어들이 과도하게 밀어붙여지는 경향이 있음
  C로 충분히 좋은 결과를 내고 있고, 사용자들도 만족한다면 외부에서 왈가왈부할 이유가 없음

  • 새 언어들이 주목받는 건 당연한 일임
    기술 발전에 관심 있는 사람들이 새로운 언어의 가능성을 탐구하는 건 자연스러운 흐름임
    다만 외부에서 의견을 말할 자유는 있지만, 프로젝트가 들을 의무는 없음
  • Rust의 설계 철학과 최근 Linux 커널의 Rust 버그 사례를 보면, Rust가 완벽한 해결책은 아님
    Rust는 버그 노출을 줄이지만, 여전히 같은 종류의 버그가 존재함
    C 개발자는 경쟁 조건에 더 민감하게 반응하는 경향이 있고, Rust는 ‘안전’ 주석에 과신할 위험이 있음
    또한 Rust에서는 수정이 단순하지 않아 리팩터링 부담이 커질 수 있음
    결국 Rust는 흥미로운 언어지만 만능은 아니며, 강요해서는 안 된다고 생각함
  • 요즘은 오히려 OOP에 대한 회의론이 커지고 있음
    Rust나 Zig 같은 언어는 전통적인 객체지향 패턴을 벗어나려는 의도를 갖고 있음
    OOP는 한때 ‘깨달음’을 주는 개념적 틀로 매력적이었지만, 실제로는 복잡성을 늘리고 모듈성을 해치는 경우가 많음
  • Rust가 모든 면에서 더 낫고 버그를 줄여준다면 사람들이 칭찬하는 게 이상하지 않음
    손드릴 대신 전동드릴을 쓰는 게 당연한 것처럼, 더 나은 도구가 있으면 그걸 쓰는 게 자연스러움
  • 최근 미국 정부가 메모리 안전하지 않은 언어(C 등) 사용을 중단하라고 권고했음
    하지만 안전한 C 코드를 작성할 수 있는 도구와 교육도 충분히 발전할 필요가 있음

• 나는 꽤 진지한 Rustacean이지만, 모든 프로젝트를 Rust로 다시 쓰는 건 합리적이지 않다고 생각함
  이미 잘 검증된 C 프로젝트를 Rust로 옮기면 단기적으로는 오히려 버그가 늘어날 가능성이 큼
  다만 일부는 Rust로의 재작성에 도전 중이며, 예를 들어 Limbo: SQLite를 Rust로 완전 재작성한 프로젝트가 있음

  • Limbo는 흥미롭지만 멀티프로세스 접근 불가라는 제약이 큼
    SQLite의 주요 장점 중 하나가 여러 프로세스에서 동시에 접근 가능한 점인데, 이게 빠지면 활용 범위가 좁아짐
  • Rust 개발자들이 굳이 SQLite의 승인을 기다릴 필요는 없음
    직접 새 버전을 만들어보고 성공 여부를 실험하면 됨
  • 개인적으로는 SQLite를 포팅하기보다 Rust로 새로운 임베디드 DB를 만드는 게 더 합리적이라 생각함
  • Limbo가 어떻게 발전할지 지켜볼 예정임

• RediSearch를 Rust로 마이그레이션한 경험이 있음
  이는 최근 CVE 취약점이 많았기 때문이었음
  SQLite에는 이런 문제가 없다면 Rust로 옮길 이유가 약함
  Rust의 강점과 한계를 이해하려면 수십 년의 시간이 필요할 것 같음
  특히 GUI 애플리케이션에서 Rust의 효용은 아직 불분명함

  • C의 안정성과 ‘지루함’은 수십 년의 시행착오 끝에 얻은 결과임
    Rust가 같은 수준의 신뢰를 얻으려면 2040년쯤은 되어야 할지도 모름
  • SQLite 같은 시스템에는 Ada/SPARK 같은 언어가 더 적합할 수도 있음

• Linus가 언급했듯이, Rust에는 OOM(Out of Memory) 복구 메커니즘이 필요함
  관련 내용은 LKML 토론 링크에서 볼 수 있음

  • 하지만 Rust의 언어 기능 자체는 기본적으로 스택 할당 중심이라 malloc을 직접 호출하지 않음
    임베디드나 커널 코드에서는 할당 기능을 완전히 끌 수도 있음
    즉, Rust는 이미 메모리 제어권을 완전히 제공함
  • (여담) 해당 페이지의 CSS를 개선하는 코드도 공유됨
  • Linus의 지적은 맞지만, 본인 진영의 문제도 정리할 필요가 있음

• “C보다 빠른 범용 언어는 없다”는 주장은 개발자 시간을 무시한 단편적 비교임
  C로 5시간 걸려 4초짜리 프로그램을 만드는 것보다, 다른 언어로 5분 만에 5초짜리를 만드는 게 현실적일 수 있음

  • 하지만 SQLite처럼 사용자 CPU 시간이 압도적으로 많은 소프트웨어에서는 C의 효율이 훨씬 중요함
    사용자 수가 많을수록 미세한 속도 차이도 누적 가치가 큼
  • 결국 사용자 시간을 중시한다면, C의 성능 최적화는 여전히 큰 의미가 있음

• Rust가 ‘지루하고 안정적인’ 언어가 되려면 아직 멀었음
  C는 보수적인 위원회가 관리하며 호환성을 철저히 지키는 반면, Rust는 문제 해결을 위해 호환성보다 혁신을 우선함

  • Rust는 언어 자체는 가끔 호환성을 깨지만, 도구 체계는 안정적임
    예전 버전의 코드를 새 컴파일러로도 계속 빌드할 수 있음
  • Rust는 구버전 코드를 구버전 컴파일러로 자동 처리해 레거시 부담을 줄이는 방식을 택함
    이는 C++처럼 과거 기능을 계속 짊어지는 접근보다 낫다고 생각함
  • C의 보수성은 ‘이상한’ 게 아니라 안정성의 상징임
  • C는 원래 한 명의 강한 의견을 가진 사람이 설계했기 때문에 명확한 방향성이 있었음
    반면 C++이나 Common Lisp처럼 위원회 설계 언어는 복잡성이 커졌음
    Rust도 규모가 커서 임베디드나 핵심 시스템에는 신중히 써야 함
  • Rust도 언젠가는 안정기에 접어들 수 있을 것 같음

• “잘 작동하는 걸 굳이 깨뜨리지 말자”는 태도에 공감함
  언어 발전의 역사는 문제를 해결하려다 새로운 복잡성을 만드는 과정의 반복 같음

  • Mozilla가 Rust를 만든 이유는 C++의 문제 때문이지만, Rust는 단순히 C++의 대체물이 아님
    C는 “Worse is Better” 철학의 대표 사례로, 단순함 덕분에 수십 년간 성공했음
    Rust는 반대로 “Right Thing™”을 지향함
    오늘날 대부분의 환경에서 직접 구현 부담이 줄었기 때문에, 이제는 더 나은 선택이 될 수 있음
    하지만 이미 성공한 프로젝트를 굳이 옮길 필요는 없음
    새 프로젝트라면 Rust가 더 나은 선택일 가능성이 큼

• C의 단순함과 안정성은 과소평가된 장점임
  언어 자체를 계속 바꾸기보다 표준 라이브러리나 생태계를 다듬는 게 낫다고 생각함

  • 다만 C에도 여전히 UB(정의되지 않은 동작) 이 많아 주의가 필요함
    단순함뿐 아니라 결정적 동작 보장도 중요함
  • Clojure처럼 단순하고 우아하며 안정적인 언어를 선호함
  • C는 새로운 기능을 추가하더라도 대부분 논란 없는 실용적 개선임
    예를 들어 designated initializer, compound literal, alignas, memset_explicit 같은 기능들이 마음에 듦

• 개인적으로 C가 여전히 최고라고 생각함
  Rust는 좋은 아이디어가 많지만 단점도 뚜렷한 언어임
  아직은 Rust의 문제점을 냉정하게 논의하기 어려운 분위기임

  • Rust의 단점이 무엇인지 구체적으로 지적하면 논의가 더 생산적일 것 같음
    예를 들어 학습 곡선이나 패키징 복잡성 같은 부분이 있을 수 있음
  • “Rust는 끔찍한 언어”라는 주장에는 구체적 근거가 필요함

• “모든 시스템이 C 라이브러리를 호출할 수 있다”는 말은 이제 사실이 아님
  Rust나 Zig도 이 요구사항을 충족함
  다만 Rust의 표준 라이브러리는 OOM 시 복구 대신 패닉하는 경우가 많고, 문서화도 부족함

  • Rust와 Zig는 명시적으로 extern "C"나 export를 써야 C ABI 호환이 됨
    그렇지 않으면 ABI가 정의되지 않아 오히려 C++보다 불안정할 수 있음
    특히 Rust crate를 배포하는 리눅스 배포판에서는 이 문제가 더 커질 수 있음