Hacker News 의견

• 링크된 벤치마크를 보면 Fil-C가 C보다 더 빠르게 보이는 경우가 있음
  아마 마이크로벤치마크의 변동성 때문일 거라 생각하지만, 일부 결과는 너무 빠르게 보여서 정확성 문제가 있는지 궁금해짐
• 작성자가 Fil-C에 상당히 감명받아서 전체 Debian 시스템을 Fil-C로 재빌드하려는 시도를 하고 있음
  이를 위해 GC shim 라이브러리와 빌드 스크립트를 만들어 공유하고 있음
• 서버에 swap이 12GB밖에 없어서 Fil-C 컴파일 중 메모리 부족으로 여러 번 재시작했음
  swap을 36GB로 늘리자 정상적으로 빌드되었고, 최대 19GB swap + 12GB RAM을 사용했음
  128코어, 512GB RAM 서버에서는 Fil-C 빌드에 8분, musl에 6분이 걸렸음
  Fil-C가 정적 분석을 많이 수행하는 듯함
  • 그건 LLVM+Clang 자체를 빌드하는 과정일 가능성이 높음
• 새로 공개된 64비트 버전의 cdb가 엑사바이트급 데이터베이스를 지원한다는 점이 흥미로움
  cdb.cr.yp.to에서 확인 가능하며, 새 cdb 서브도메인이 pqconnect를 사용한다고 언급됨
  • 실제로는 cdb.cr.yp.to에 NS 레코드가 없어서 DNSCurve가 작동하는 구조임
    pqconnect는 HTTP(S) 연결 단계에서 사용되고, 둘 다 DNS에 공개키를 인코딩하지만 역할이 다름
    pqconnect는 CurveCP처럼 CNAME에 공개키를 포함함
  • RFC1034에 따르면 cdb.cr.yp.to는 cr.yp.to와 yp.to의 하위 도메인(subdomain) 으로 볼 수 있음
    다만 pq1 부분은 공개키가 아니라 서버의 장기 공개키 해시임
  • pqconnect 사용은 예전부터 있었지만, cdb.cr.yp.to의 CNAME은 10월 21일경 새로 추가된 것으로 보임
    Fil-C 관련 노트는 3일 전에 제출되었음
    관련 스레드
  • 참고로 11일 전에도 관련 논의가 있었음
    이전 토론 링크
• 멋진 프로젝트라고 생각함
  목표는 C/C++ 프로그램 대부분이 Rust로 다시 작성할 필요 없이 안전하게 실행되도록 하는 것 같음
  Epic Games가 어떻게 관련되는지도 궁금함
  • Fil-C는 가비지 컬렉션 기반 언어라서 C보다 훨씬 느림
    새로운 코드를 작성하기보다는 WASM 샌드박싱처럼 기존 코드를 안전하게 감싸는 용도로 적합함
    다만 Fil-C는 크래시를 더 정확히 잡아냄
• Phil의 작업이 드디어 정당한 인정을 받는 것 같아 기쁨
  Rust의 unsafe 모드에도 참고할 만한 점이 있을 듯함
  특히 Fil-C로 컴파일된 의존성을 정적 링크하는 방식은 흥미로움
  • 하지만 Fil-C는 현재 FFI를 지원하지 않음
    포인터 추적을 위해 프로그램 전체를 Fil-C가 통제해야 하므로 FFI는 구조적으로 맞지 않음
• Fil-C 관련 주요 스레드들을 정리함
  예: Fil-C: A memory-safe C implementation,
  Safepoints and Fil-C,
  Fil’s Unbelievable Garbage Collector 등
  2024~2025년 사이의 메모리 안전성 논의가 이어지고 있음
• Fil-C가 무엇인지 모르는 사람들을 위해 요약함
  Fil-C는 C/C++과 호환되는 메모리 안전 구현체로, 대부분의 코드가 거의 수정 없이 컴파일됨
  모든 메모리 오류는 panic으로 감지되며, 동시 GC와 InvisiCaps로 안전성을 확보함
  공식 사이트에서 자세한 설명을 볼 수 있음
  • Fil-C를 사용하려면 런타임에 Garbage Collector를 수용해야 함
• build_all_fast_glibc.sh 스크립트가 31GB 메모리를 요구한다는 점이 놀라움
  이유를 알고 싶고, 직접 Fil-C를 시도해보고 싶음
  • 그건 LLVM 빌드와 링크 과정이 무겁기 때문임
• 유명한 암호학자가 bash와 curl을 사용하는 모습이 흥미로움
  • 사실 curl | bash는 괜찮은 경우도 많음
    관련 글