Hacker News 의견들

• 나는 주로 C 스타일로 코드를 작성하지만, 필요할 때만 C++ 기능을 사용함
  그래서 얼핏 보면 Rust 코드처럼 보이기도 함
  게임을 C로 쓴다는 사람들은 C++ 기능을 싫어하면서 결국 가상 인터페이스를 직접 구현하거나 거대한 switch문을 만들어서 비슷한 일을 함
  언어에 있는 기능을 안 쓰면 그만인데, 그 존재 자체를 불평하는 건 의미 없다고 생각함
  C++은 템플릿을 남용하지 않으면 컴파일이 느려지지 않음

  • 혼자 개발할 때는 그럴 수 있지만, 팀 단위로 장기간 유지되는 프로젝트에서는 상황이 다름
    시간이 지나며 팀원이 바뀌고 리더가 바뀌면, 사용되는 기능의 집합이 점점 커짐
    한 번 늘어난 기능을 줄이기는 매우 어려움
    또, 원치 않는 기능을 사용하는 라이브러리를 써야 할 수도 있음
    예를 들어, 나는 암묵적인 호출(소멸자, 연산자 오버로딩 등)을 싫어하지만, 라이브러리가 그걸 쓰면 결국 따라가야 함
  • 적어도 switch문은 읽을 수 있음
    C++의 가장 나쁜 점 중 하나는 자동으로 생성되는 숨은 코드가 너무 많다는 것임
  • C++의 동적 디스패치는 모든 타입에 vtable을 붙이는 방식임
    코드 대부분이 구체 타입(Goose, Duck 등)을 다루더라도, 모든 객체가 vtable 포인터를 들고 다님
    반면 Rust는 필요한 곳에서만 vtable을 사용해서 메모리를 절약함
    C 프로그래머는 필요한 기능만 직접 구현하므로, 언어가 강제하는 구조에 덜 묶임
  • C++은 템플릿을 남용하지 않아도 느림
    <vector> 하나만 포함해도 수만 줄의 코드가 포함됨
    그래서 표준 라이브러리를 안 쓰면 “왜 다시 바퀴를 발명하냐”는 논쟁이 생김
    이런 논쟁이 반복되면 그냥 C로 돌아가는 게 훨씬 편함
    나도 2017년쯤 C로 전환했고, 지금도 C++ 라이브러리를 쓸 때마다 피로함
    예외적으로 Dear ImGui는 괜찮지만, 그마저도 C 바인딩을 선호함
  • 실제로 C++ 파일을 작성했는데 C++ 기능을 하나도 안 쓴 적이 있음
    확장자를 .c로 바꾸자 컴파일 시간이 절반으로 줄었음

• 나는 C의 거칠고 단순한 성격을 좋아함, 다만 전처리기는 싫어함
  그래서 Zig는 정말 신의 선물 같음 — C보다 단순하면서도 더 정확한 언어 설계를 가짐
  예를 들어 Zig는 단일 포인터와 배열 포인터를 구분함
  C 라이브러리를 가져와 더 사용하기 쉽게 만들 수 있고, 게임 개발에서 매우 유용함
  대부분의 C++ 라이브러리도 C 헤더를 함께 제공함
  zig-gamedev에는 이런 Zig화된 C 라이브러리가 많음
  전처리기 대신 Zig의 comptime 기능이 훨씬 낫고, 단지 “컴파일 시점에 실행되는 Zig 코드”일 뿐임

  • 하지만 실제로는 C++ 라이브러리 중 C 헤더를 내보내는 경우가 너무 적음

• 나도 글쓴이의 생각에 공감함
  언어를 좋아하게 되는 가장 큰 이유는 단순함임
  그래서 C, Go, Odin, Zig 같은 언어를 선호함
  하지만 필요한 복잡성을 우아하게 다루는 언어도 중요함
  메모리 안전성과 동시성, 함수형 패턴이 필요한 네트워크 코드에서는 Rust가 자연스러움
  반면, 인디 게임처럼 단순하고 빠른 코드에는 C나 Odin이 잘 맞음
  Odin은 Go의 단순함과 C의 성능을 결합한 느낌이라 추천함
  Raylib로 게임 만들기도 쉬움

  • 흥미롭게도 나는 Zig를 Go와 C의 중간 지점으로 설명하곤 함
    Odin이 Zig보다 그 자리에 더 잘 맞는다고 생각하는지 궁금함
  • 참고로 언어 이름은 Go이고, golang은 단지 도메인 이름임

• 원문에서 Go의 게임 라이브러리 지원이 부족하다고 했는데, 그건 2015년쯤 글로 보임
  지금은 상황이 달라졌을 수도 있음

  • Wayback Machine에 2016년 1월의 스냅샷이 있음
    당시 만든 게임들의 스크린샷도 볼 수 있음
    예를 들어 Knossu는 독특한 3D 스타일을 가짐

• 2026년에 C로 게임을 만드는 건 약간 미친 짓일 수도 있지만, 나도 그렇게 함
  예를 들어 Chrysalis를 C로 개발했음 (GLFW3, FMOD 사용)

  • 나는 2년째 Jedi Academy 코드베이스를 다루고 있음 (C & C++)
    idTech3 기반인데, 전투 시스템이 너무 정밀해서 작은 변경도 전체 밸런스를 깨뜨림
    심지어 i++ 하나 추가해도 타이밍이 달라짐
    그래서 22년 된 컴파일러를 그대로 사용 중임
    현대화된 포크들도 있지만, 원래의 감각을 잃었음
    idTech3는 정말 C의 정수(精髓) 를 보여주는 엔진임

• 수천 개의 게임이 C로 작성되었고, OpenGL, Vulkan, DX 같은 그래픽 API도 전부 C 기반임
  그래서 전혀 이상하지 않음
  대부분의 게임 엔진도 C/C++로 작성됨

  • Khronos API는 C, DirectX는 C++ 기반 COM/WinRT, Metal은 Objective-C와 C++ 혼합임
    콘솔은 세대마다 다름
  • SDL3도 C로 작성되었고, Box2D의 최신 버전도 C로 다시 작성됨
  • DirectX는 C++이고, 대부분의 게임 엔진도 C++임
    리눅스 프로그래밍과 달리, 게임 개발은 30년 넘게 C++ 중심이었음

• 나는 근본적으로 C를 사랑하는 사람임
  수십 년 동안 잘 써왔지만, 팀 단위로 C 코드를 관리하면 고통이 커짐
  또, 현대 언어에 비해 개발 속도가 느림
  그래도 단순함의 매력은 여전함

  • 왜 C 코드베이스가 팀 작업에서 더 아픈지 궁금함
    내 경험상 C++보다 C가 덜 고통스러웠음
  • “적게 말하고 더 의미 있게” — 즉, 간결함이 핵심임
  • 리눅스 커널에는 2025년에만 2,134명의 개발자가 참여했음
    그 사실이 C의 협업 한계를 약화시킴

• “아무도 C로 게임 안 만든다”는 말은 과장임
  지금은 주류는 아니지만 여전히 많은 사람이 C로 게임을 만듦

  • “아무도”나 “모두” 같은 표현은 보통 절대적인 의미가 아님
    당신은 예외일 뿐이고, 그 말은 여전히 통계적으로 맞음

• 나는 C가 좋음
  메모리 관리를 완전히 통제할 수 있고, 예측 가능한 동작을 얻을 수 있음
  MISRA 규칙처럼 사전 할당을 요구하는 환경에서는 특히 유용함
  하드웨어 수준의 예외나 오류를 직접 다루기에도 좋음
  단위 테스트 작성도 쉬움

• C는 진입 장벽이 낮지만, 메모리 관리 지식은 필수임
  Java 개발자인 내가 .h와 .so만 주어진 상황에서 빠르게 커넥터를 만들어야 했을 때, C++보다 C를 선택했음
  C가 날카로운 칼이라면, C++은 회전하는 칼기둥 같음 — 방심하면 다침
  다만 문자열 처리는 C에서 너무 고통스러워서 C++의 문자열 시스템을 빌려오고 싶음

  • C++의 좋은 점은 원하지 않는 기능은 안 써도 된다는 것임