Hacker News 의견

• SQLite는 코드 품질과 엄격한 테스트로 인해 재작성할 필요가 없는 프로젝트로 보임

  • 다른 C 코드가 먼저 재작성되면 좋겠다는 의견이 있음

• SQLite가 "오픈 기여"가 아니라는 논의는 기여를 받는다는 것이 항상 기여를 수용한다는 의미가 아님을 간과함

  • SQLite는 기여를 위한 절차가 있으며, 제안된 기능을 구현하는 방식임
  • Litestream과 LiteFS 같은 SQLite 생태계의 다른 프로젝트들도 비슷한 기여 정책을 가짐

• SQLite3에서 LibSQL로의 포크 초기 발표에 대해 부정적이었음

  • SQLite3의 테스트 스위트가 독점적이기 때문에 포크가 실패할 가능성이 높다고 생각했음
  • 그러나 메모리 안전 언어로의 재작성과 같은 큰 제품이 있다면 포크가 의미가 있다고 봄

• 최대 성능을 위해 WAL 모드를 선택해야 하며, POSIX 권고 잠금을 비활성화해야 함

  • "wal2" 모드가 프로젝트의 레이더에 있는지 궁금해하는 의견이 있음

• SQLite의 테스트 스위트가 독점적이라는 사실을 처음 알았다는 의견이 있음

  • Android가 비슷한 방식으로 구축되었지만, 이는 다른 문제임

• "async IO" 섹션의 논리를 받아들이지 않음

  • SQLite에 비동기 인터페이스를 추가하기 위해 재작성할 필요가 없다고 봄
  • SQLite의 동기 인터페이스 문제는 IO를 기다리는 동안 스레드가 유휴 상태로 남는 것임
  • SQLite는 저장소에 매우 가깝게 실행되도록 설계되어 IO 차단이 매우 짧거나 없을 수 있음

• 초기 단계에 있는 프로젝트라는 의견이 있음

  • Python과 Limbo를 사용한 코드 예시가 제공됨

• Fil-C로 컴파일하면 메모리 안전한 SQLite를 얻을 수 있음

  • 약간의 변경만 필요하며, 테스트 스위트를 거의 통과함

• SQLite는 약 156,000줄의 코드와 92,000줄의 테스트 코드로 구성되어 있음

• Rust 변형의 DO-178B 인증은 고려되지 않는 것으로 추정됨

• "Limbo"라는 이름은 AT&T의 Inferno 운영 체제를 위한 포스트-C/UNIX 언어에서도 사용됨