▲

내가 모든 것을 멈추고 C를 다시 쓰기 시작한 이유

 (kmx.io)
2P by GN⁺ 27일전 | ★ favorite | 댓글 1개
  • 프랑스의 컴퓨터 학교에서 5년간 공부하고 20년간 프리랜서 개발자로 활동함
  • 주로 Ruby on Rails로 클라이언트 프로젝트 작업 수행
  • Common Lisp을 배우기 시작하면서 ASN.1 파서를 생성하는 서버 관리 프로토콜 작성
    • Common Lisp에서 C 코드를 생성하여 SNMP 서버 개발
  • 그 이후 Common Lisp 기반으로 여러 프로젝트 작성:
    • cl-unix-cybernetics – GitHub에서 가장 많은 별을 받은 프로젝트
    • cl-streams 및 cffi-posix 개발
    • cl-facts – 트리플 스토어로, Common Lisp 그래프 데이터베이스 역할 수행
      • 빠르고, 원자적 트랜잭션, 중첩 가능한 트랜잭션 지원
      • unwind-protect과 호환됨
      • 단 3개의 매크로만 배우면 사용 가능
      • European Lisp Symposium (ELS)에서 발표
  • Common Lisp 개발에 집중하면서 클라이언트를 잃었지만, Lisp의 가능성에 큰 확신을 가짐

가상 머신(VM)과 컨테이너의 한계

  • 전문가들이 VM 및 컨테이너의 문제점 지적:
    • VM은 불필요한 CPU와 대역폭 낭비
    • Linux의 cgroups 기반 컨테이너는 원격 명령 실행(RCE) 및 권한 상승 취약점 존재
    • 매년 새로운 보안 취약점 발견
  • OpenBSD를 선호하면서 Terraform, Ansible 같은 DevOps 도구의 문제 피함

Common Lisp의 한계와 성능 문제

  • Clojure 등에서 GC(가비지 컬렉터)로 인해 성능 문제 발생:
    • 수천 개의 유닛을 처리하는 전략 게임 개발 시 실패 사례 발생
    • JVM의 GC는 성능 및 비용 문제를 수반함

C로의 전환 결정

  • Common Lisp의 성능 및 이식성 한계 인식:
    • Linux, OpenBSD, GTK+, GNOME 모두 C로 작성됨
    • 결국 성능과 이식성 문제를 해결하기 위해 C로 전환

새로운 언어 KC3 개발

  • libc3 유틸리티 라이브러리 개발 → C3 언어 → KC3로 명칭 변경
  • KC3의 특징:
    • 인터프리터 (ic3) 및 컴파일러 (c3c) 존재
    • UTF-8 버퍼에서 데이터 구조 생성 및 역변환
    • 방어적 프로그래밍 → 초기부터 버그 최소화
    • 보안 문제 없음
    • enum 태그된 union 기반의 데이터 타입 시스템

KC3 기반 성과

  • cl-facts를 C89로 포팅:
    • Covid-19 기간 동안 개발 완료
    • 트리플 추가, 삭제, 재귀 쿼리 시스템, 트랜잭션, 로깅, 지속성 등 구현
  • 알고리즘 타입을 위한 파서 및 생성기 작성:
    • 구조체, 연결 리스트, 맵, 해시 테이블, 복소수, 튜플, 코드 블록 등 포함
    • José Valim (Elixir 창시자)에게 큰 영감 받음
  • ikc3 – KC3 평가 결과 출력하는 REPL
  • kc3_httpd – MVC 프레임워크 기반 웹 서버 개발
    • 현재 블로그 페이지도 kc3_httpd로 제공
  • 문서화 웹사이트 작성 → KC3의 Markdown to HTML 변환기 사용

결론

  • Common Lisp에서 얻은 경험을 기반으로 C로 전환
  • KC3는 성능, 보안, 이식성에서 뛰어난 성과를 거둠
  • 앞으로 KC3와 관련된 추가 매크로 및 예제 제공 예정
▲
GN⁺ 27일전  [-]
Hacker News 의견

  • 나는 반대 입장임. 어릴 때 VB를 많이 사용한 후 대학에서 Java, C, C++를 배웠고, 주로 C를 사용했음. Xfce의 핵심 개발자가 되어 5년간 일했음

    • 이후 백엔드 개발로 전환하여 Java, Scala, Python을 사용했음. 이 언어들은 다른 문제를 가져오지만, 표준 라이브러리와 의존성 관리 시스템이 마음에 들었음
    • 12년 후 다시 Xfce로 돌아왔는데, C는 여전히 어려움. 메모리 누수, NULL 포인터 참조, 데이터 경합 등의 문제가 많음
    • Rust를 사용하면서 C보다 생산성이 높아졌음

  • 그 감정에 완전히 공감함. 몇 년 동안 순수 C로 무언가를 개발하고 싶다는 강한 충동을 느꼈음

    • 주 언어는 C++이지만, 오래된 C 라이브러리를 사용하는 것이 정말 즐거움. 인터페이스가 단순하고 기본적임
    • 순수 C로 메서드를 개발할 때 알고리즘에 100% 집중할 수 있어 좋음
    • C는 나에게 스스로 작업을 하도록 강요함. 마법과 복잡성을 숨기지 않음
    • 주변 사람들은 최신 C++ 기능을 사용하려 하지만, 나는 점점 C++ 기능을 제거하려고 함

  • 오래 전 C로 프로그래밍을 시작했고, 지금도 가끔 그 시절로 돌아가고 싶음

    • 그러나 실제로 C로 생산 등급의 애플리케이션을 작성하려고 하면 왜 그만두었는지 깨닫게 됨
    • 컴퓨터의 지원 없이 스스로 해야 할 일이 너무 많음
    • 오늘날 저수준 언어를 선택해야 한다면 Ada를 선택할 것 같음. C와 비슷하지만 컴파일러의 지원이 더 많음

  • 블로그 글을 읽고 나서 저자가 무엇을 전달하려는지 혼란스러웠음

    • 저자의 프로그램이 사용되지 않는 이유가 언어 때문인지 의문이 들었음
    • 메모리 소비와 관련된 문제가 있을 수 있음
    • 저자는 배운 교훈이나 사용자 통계에 대해 언급하지 않았음
    • 새로운 기능이 추가되지 않았고, 단지 연습으로 재작성한 것 같음

  • kc3 코드 예시가 주어졌음

  • C는 나의 첫 번째 언어였고, 간단한 콘솔 앱과 작은 게임을 만들었음

    • 그러나 다시 돌아가고 싶지 않음. 빌드 도구와 의존성 관리가 구식임
    • Zig는 나의 새로운 C임. C 컴파일러를 포함하고 있으며, C 헤더를 래퍼 없이 사용할 수 있음
    • Go는 간단한 언어가 필요할 때, Rust는 성능과 안전이 필요할 때 사용함

  • 가끔 C로 취미로 코딩을 함. 하지만 반복적인 작업이 너무 많아 지루함

    • C로 컴파일러를 작성하는 것은 태그된 유니온을 다루는 것과 같음
    • 반복적인 작업을 줄이기 위해 생성기를 작성할까 생각했지만 아직 하지 않았음
    • C로 프로젝트를 개발할 때 프로토타이핑을 위해 임베디드 언어를 사용하는 것을 고려했음

  • C는 실용적이기 때문에 성공적이었음

    • 안전하지 않지만 원하는 것을 할 수 있음

  • 아무것도 이해되지 않음

    • 킬러 앱이 무엇인지, CL과 관련된 문제, C가 유일한 옵션인지 의문임
    • KC3 코드 실행에 보안 문제가 없다고 확신하는지 의문임

  • 이 글은 해피 엔딩 없는 경고 이야기처럼 읽힘

답변달기