C++은 정말 재미있다

• C++은 C++11 이후 언어와 생태계가 크게 바뀌며, 직접 만들고 실험하는 과정에서 프로그래밍의 재미를 되살리는 언어가 됨
• 한때 C++은 템플릿 메타프로그래밍 과잉과 표준·패턴 중심 문화 때문에 많은 개발자에게 피로한 언어로 기억됨
• auto, nullptr, range-for, 람다, <chrono>, 스마트 포인터, <thread> 같은 변화가 C++의 코딩 스타일을 크게 바꿈
• 최신 C++은 파일시스템, 패키지 관리, GUI/TUI, 그래픽, 수학, AI, OS API 접근까지 선택지가 넓어 원하는 것을 직접 만들기 쉬움
• 컴파일러 오류, 빌드 도구, 표준 준수, 역사적 복잡성, RAII 같은 단점은 남아 있지만 창작 가능성이 그 불편함을 넘어섬

---

C++이 다시 재미있어진 이유

• 작은 로그라이크 게임을 만들며 지도 생성에 Dijkstra 알고리듬을 활용해 방을 연결하는 터널을 구현했고, 그 과정에서 C++이 실험을 크게 방해하지 않았음
• FTXUI 사용자 인터페이스를 SFML 렌더 윈도우에 직접 그리는 실험도 가능했고, 이 과정에서 C++의 Unicode 처리를 배움
• 이런 작업들은 쉽지는 않았지만 실제로 가능했으며, “이 아이디어가 정말 동작했다”는 감각이 C++의 재미를 만듦
• 프로그래밍을 시작한 이유는 억만장자에게 더 많은 돈을 벌어주거나, 렌더링 엔진과 싸우거나, 오픈소스 프로젝트 상층부를 만족시키기 위해서가 아니라 아이디어를 구현하는 즐거움이었음

템플릿 메타프로그래밍 시기의 피로감

• 1990년대 말부터 2000년대 초까지 C++은 템플릿 메타프로그래밍을 모든 것에 적용하려는 분위기가 강했고, 이 시기가 C++을 재미없게 만든 전환점으로 다뤄짐
• 템플릿으로 두 숫자를 더하는 방식이 직접 더하는 것보다 빠르다는 식의 논의가 있었지만, 실제 어셈블리 출력은 같았다는 사례가 나옴
• C++ 표준위원회가 프로그래머에게 좋은 사용성을 제공하는 데 소극적이었다는 인식도 부정적 경험을 키움
• 당시 C++은 <> 꺾쇠괄호와 복잡한 문법은 많지만 얻는 것은 적은 언어로 기억됨
• Java도 처음에는 가비지 컬렉터와 개발자 친화성 때문에 매력적으로 보였지만, 이후 보일러플레이트와 디자인 패턴 과잉으로 비슷한 피로감을 낳음

C++11이 바꾼 언어의 감각

• C++11에 추가된 기능은 C++의 인상을 크게 바꾼 변화로 평가됨
• 주요 기능은 다음과 같음
  • auto: 같은 타입 이름을 반복해서 적는 부담을 줄이는 자동 타입 추론 키워드
  • nullptr: C의 NULL 문제를 보완하는 널 포인터 표현
  • range-for: auto와 함께 컨테이너 순회를 더 간단하게 만드는 반복문
  • lambda expressions: API 설계와 사용성을 크게 바꿀 수 있는 람다
  • <chrono>: 100ms 같은 표현이 가능한 타입 안전 시간 라이브러리
  • <regex>: 표준 라이브러리에 포함된 정규식 기능
  • unique_ptr, shared_ptr: 소유권과 참조 카운팅을 다루는 스마트 포인터
  • <thread>: 멀티스레딩을 기본 언어 생태계에 포함한 기능
• C++11은 기존 방식을 버리지 않으면서도 언어의 철학과 스타일을 바꿨고, 이 점에서 JavaScript의 ES6와 비슷하게 받아들여짐

현대 C++ 생태계의 선택지

• 최신 C++은 다른 언어에서 기대하는 기능을 상당수 갖추고 있음
• 예시로 제시된 도구와 라이브러리는 다음과 같음
  • 파일시스템 순회: filesystem
  • 패키지 관리: Conan, Meson WrapDB, vcpkg
  • 행렬 라이브러리: Eigen
  • AI: TensorFlow C++ API
  • 그래픽: SFML
  • GUI: Qt, wxWidgets, ImGui
  • TUI: FTXUI
• 생태계 품질은 항목마다 차이가 있지만, JavaScript와 Python에서 경험한 것보다 전반적으로 높게 평가됨
• 특히 FTXUI와 STL은 좋은 설계와 사용성을 보여주는 예로 꼽힘

“재미”를 만드는 넓은 구현 가능성

• C++이 재미있는 이유는 단순히 현대적 기능이 추가됐기 때문만이 아니라, 거의 무엇이든 만들 수 있는 구현 가능성에 있음
• 데스크톱 앱은 fenster, SFML, Qt를 쓰거나 직접 OS API를 다루는 방식으로 만들 수 있음
• 사운드는 SFML 같은 빠른 선택지부터 Wwise 같은 상용 도구까지 폭이 넓음
• 3D 그래픽은 OpenGL, Vulkan, Direct3D, Ogre3D 등 다양한 선택지가 있음
• 수학 영역에는 BLAS, Eigen, GMTL 같은 라이브러리가 있음
• 필요한 라이브러리가 없더라도 C 또는 C++ ABI와 운영체제 API에 직접 접근해 만들 수 있고, 이 직접 제작 과정 자체가 재미의 일부가 됨

유행에서 비켜난 언어의 창작 자유

• C++은 언어와 생태계의 품질이 높지만 현재 유행하는 언어는 아니어서, 언어를 망치는 부류의 관심을 덜 받는다는 평가가 나옴
• C++ 커뮤니티는 무엇을 만들든 크게 간섭하지 않는 분위기로 그려짐
  • 행렬 라이브러리, GUI 라이브러리, 게임 엔진, 이상한 게임 같은 프로젝트를 자유롭게 시도할 수 있음
• 창의적인 작업에는 아이디어를 먼저 밖으로 꺼내는 단계와, 이후 냉정하게 비판하고 품질을 높이는 단계가 모두 필요함
• 다른 언어에서는 조직, 리더십, 커뮤니티 압력이 창작 중간 단계의 실험을 방해한다고 평가됨
• C++의 넓은 가능성과 상대적으로 낮은 수치심 부여 문화가 창의적 경험을 만들 수 있음

cppreference.com의 강점

• cppreference.com은 사용해본 프로그래밍 언어 문서 중 최고 수준으로 평가됨
• 장점은 다음과 같음
  • 모든 키워드와 라이브러리가 참조 문서로 정리되어 있음
  • 대부분의 항목에 실제로 동작하는 예제가 있음
  • 각 기능이 도입된 C++ 표준 버전을 표시함
  • 표준 문서와 관련 참고자료로 연결됨
  • DuckDuckGo 기반 검색창이 있어 철자가 틀리거나 정확한 용어를 몰라도 찾기 쉬움
  • Copy elision처럼 중요한 개념도 예제와 함께 설명함
• 부족한 점은 다양한 플랫폼에서 컴파일러를 설치하는 방법이 없다는 것임
• C++ 컴파일러와 플랫폼 수가 많지 않기 때문에 시작 가이드를 추가할 여지도 있음

여전히 남아 있는 C++의 문제

• C++이 완벽한 언어라는 뜻은 아니며, 다른 언어처럼 불편한 점이 많음
• Windows에서 Microsoft가 아닌 설치 경로로 컴파일러와 개발 도구를 구성하는 일은 어렵고, 이를 위해 PowerShell 설치 스크립트를 직접 만들었음
• 현재 느끼는 주요 불편은 다음과 같음
  • 컴파일러 오류 메시지의 95% 이상이 업계 최악 수준으로 평가됨
  • 빌드 도구는 사용하기 어렵고, Meson도 설치된 패키지 지시를 무시하고 깨진 시스템 라이브러리를 쓰는 문제를 겪음
  • 컴파일러 제조사가 표준을 따르도록 만드는 유인이 부족함
  • C++은 역사 때문에 매우 복잡하며, 오래된 힙 할당·raw pointer 스타일, 템플릿 메타프로그래밍 스타일, C++11 이후 스택 중심 스타일, struct 중심의 더 새로운 스타일이 공존함
  • RAII는 현실적인 설정 상황에서 방해가 되는 경우가 많고, 다른 언어식 초기화 생성자와 현재 RAII 사이의 중간 지점이 필요하다고 봄
• 이런 단점에도 C++의 불편함은 재미를 망칠 정도는 아니며, C++은 과거의 꺾쇠괄호와 포인터 중심 언어라는 인상과 달라졌음
• FTXUI GUI 레이아웃 코드는 C++이라는 사실을 모르면 다른 언어처럼 보일 정도로 현대적인 문법을 보여주는 사례임

[GN⁺]

Hacker News 의견들

• C++ 혐오자에 가깝지만, 그건 신뢰성이 필요한 업무 코드와 완전히 믿기 어려운 동료들과 함께 C++을 다뤄야 하는 게 싫어서임
  개인 프로젝트에서는 지금까지 해본 코딩 환경 중 가장 만족스러운 축에 들었고, 실행을 아주 세밀하게 제어할 수 있다는 점은 정말 신남
  약 10년 전에 C++을 떠났고 돌아갈 생각은 없지만, 요즘 내 프로젝트에는 장기 신뢰성이 가장 중요해서 Rust + CI/CD가 딱 맞음
  그래도 프로그램이 내가 의도한 방식 그대로 실행되도록 설계하고 구현하며, 그게 내 전문성과 통찰 덕분이라는 짜릿함은 그립다
  같이 일하는 사람이 그런 동기로 움직이길 바라느냐면 절대 아니지만, 개인적으로는 잊지 못할 즐거움임
  빌드 시스템과 패키지 관리는 악몽이고, 전처리기는 가학적인 농담 같고, 문법은 끔찍하며, 런타임에는 발을 기관총으로 쏘지 않으려면 수년의 경험이 필요한 찌꺼기가 너무 많음
  하지만 어떤 의미에서는 이런 고통이 똑똑함과 피눈물로 감싼 실행 파일을 마침내 내보낼 때의 기쁨을 더 키워줌

  • C++에 대해 읽은 묘사 중 가장 공감되는 축임
    C/C++을 몇 년간 업무로 썼고 다시 돌아가고 싶지 않음
    남의 코드를 디버깅하고, 애매한 통합 문제를 겪고, 빌드 시스템 스파게티를 돌리느라 너무 많은 시간을 보냈다
  • 일도 개인 프로젝트만큼 재미있어야 함
    지난 10년 동안 기술 업계가 이 생각을 잃어버린 것 같고, 최고의 사람들을 좋은 음식과 푹신한 의자가 있는 성인 감옥에 넣는 대형 기술 회사들 탓으로 봄
    스타트업도 덜 재미있어졌고, VC 업계가 좁은 사고의 창을 부추기면서 같은 것을 만드는 복제 스타트업과 유행이 너무 많아졌음
    새 프로젝트마다 C++을 쓰는 이유는 직접 만들어야 할 때 만들 수 있다는 확신이 있어서임
    프레임워크는 특히 프로젝트 핵심을 다룰 때 원하는 방식대로 동작하지 않는 경우가 많아 계속 쓰기 싫다
    직접 만들 수 있으면 직접 만들고, 아니면 프레임워크를 쓰면 됨
    직접 만들 수 있다면 C++은 무엇이든 할 수 있고 중요한 방식에서는 방해하지 않는 훌륭한 도구임
    Rust 같은 언어는 내가 위험한 일을 한다고 불평할 수 있지만, C++에서는 내 머릿속 모델을 직접 표현할 수 있음
    가끔은 포인터로 생각하고, 포인터는 정말 좋은 도구임
    재미를 되찾자, 개인 생활뿐 아니라 일에서도

• 이 글은 다소 혼란스러워 보임
  많은 지점을 말하지만, 그게 왜 C++이 더 재미있거나 덜 재미있다는 결론으로 이어지는지 뽑아내기 어렵다
  현대 C++을 극도로 높은 품질이라고 하면서 동시에 광범위한 레거시 문제와 끔찍한 도구를 말하는 것도 헷갈림
  unique_ptr는 훌륭하다고 하면서 RAII는 정말 싫다고 하고, 메타프로그래밍은 예전에는 어디에나 있었지만 이제는 아니라는 식의 주장도 이상함
  concepts를 보면 그렇지 않고, C++이 최고의 그래픽 라이브러리를 갖췄다는 말이나 Python 설치가 C++보다 어렵다는 말도 논지와 별 관련 없는 저자의 집착처럼 보인다
  결국 저자는 개인적 요인의 복합적인 조합 때문에 C++을 재미있어하는 것 같고, 그 자체는 괜찮음
  성능과 기술적인 성격 때문에 C++로 가장 재미있게 프로그래밍한 적도 있지만, 실전 소프트웨어 개발에서는 우리가 아는 수많은 이유로 C++이 별로임
  C++은 수십 년의 레거시와 정치에 상처 입은 깊이 모순적인 언어이고, C++의 현실을 무시하는 게 C++ 논의에서 가장 큰 실수임
  요즘 C++에 대한 내 태도는 피로감에 가깝고, 지난 여러 해 동안 C++이 던져온 장애물을 더는 뛰어넘고 싶지 않음
  이미 너무 오래 죽은 말을 계속 때릴 필요는 없고, C++은 그냥 C++인 채로 둬도 된다

  • 그 문장이 글의 요지를 잘 요약한다고 봄
    내가 보기엔 글이 혼란스럽다기보다, 저자가 즐거워하고 있고 그 기쁨을 최대한 나누려는 쪽에 가까움
    제대로 된 논설문이라기보다는 적극적으로 설득하려는 글이 아니라, “굳이 설득하지 않아도 공감된다면 너도 재미있을지 모른다”에 가까움
    상업적 업무에서 현실에 얻어맞아 피곤해진 입장이라면 말이 안 된다고 느끼는 것도 충분히 이해됨
    나도 요즘 하필 JavaScript를 쓰며 엄청 즐거워하고 있는데, 비슷한 글을 쓰면 지난 10년간 상업적 JavaScript에 지친 사람에게는 똑같이 나쁘게 읽힐 것 같음
    그래도 저자가 즐거워하고, 그 즐거움을 공유하기로 한 건 반갑다

• C++ 프로젝트에 서드파티 의존성을 Linux/Windows/macOS에서 동작하도록 정적 링크하는 데 3일을 썼음
  그 패키지는 conan/vcpkg에 없고, 이상한 Makefile/cmake 조합이 있는 GitHub 저장소뿐이었음
  cmake/cpp 전문가와는 거리가 멀지만, 대부분의 현대 언어에서는 pip install, cargo add, npm install, go get 같은 방식으로 문제가 되지 않음
  C++ 의미론의 세부를 책으로 처음부터 끝까지 읽어도, 실제 프로젝트에서 작업하는 건 여전히 고통스러움

  • JavaScript의 의존성과 빌드 도구 체인도 가장 지저분한 Makefile만큼 난해함
    결국 JavaScript판 autotools 같은 것에 도달했다는 게 놀라움
  • 특히 무엇이 어려웠는지 궁금함
    남의 코드를 정적 빌드하거나 다른 플랫폼에서 빌드되게 바꾸는 건 가끔 까다롭지만, 링크 자체는 보통 include 디렉터리, 라이브러리 경로, 라이브러리 지정 정도임
  • 뒤집어 보면, 이 서드파티를 다른 “현대적” 언어에서 쓰고 싶다면 무엇이 더 나아질까 싶음
    누군가 vcpkg/conan 패키징을 해두지 않았다면 pip/cargo/npm에도 없을 가능성이 높음
    C++에서 힘들었다면 다른 언어에서는 훨씬 더 힘들 수 있음
    다만 역사적인 C++의 일부, 특히 빌드 이야기가 아주 나쁜 상태라는 점은 여기서도 드러남
    vcpkg에만 들어 있다면 설치 난이도는 다른 생태계와 정확히 비슷해짐

• 주기적으로 C 대신 C++로 작업해보는데, 매번 비슷한 패턴임
  새로운 C++ 기법을 알게 되고, 뭔가 나아질 것 같아 코드를 쓰고, 컴파일러 오류를 맞은 뒤, 남은 하루를 왜 내가 원하는 걸 할 수 없는지 배우는 데 씀
  보통 C++14에 묶여 있고 일부 문제는 이후 버전에서 고쳐졌지만 그래도 그렇다
  C++을 정말 좋아하고 싶은데, 이론상 생산성을 높여줄 더 강력한 C를 제공하지만 결국 인지적 짐이 너무 많아서 보통 “클래스가 있는 C”를 쓰고 넘어가게 됨

  • 배움이 재미있는 시점이 있고, 원글 작성자는 아직 거기에 있는 것 같음
    2003년에 실시간 C++을 많이 썼고 싫어했지만, 작년에는 코드 대부분을 C++로 쓰면서 드디어 좋아하게 됨
    람다와 auto 가 C++을 싫어하지 않게 된 전환점이었음
    템플릿도 조금 썼지만, 주로 같은 함수의 변형마다 분기를 잔뜩 쓰지 않기 위해서였음
    람다 덕분에 SICP 분위기의 Lisp 계열 선생들에게 처음 배운 방식대로 코드를 쓸 수 있게 됨
    unique_ptr를 쓰니 할당도 싫지 않았다
  • 막 어떤 기능을 배운 사람이 그걸 쓰고 싶어서 만든 나쁜 코드를 많이 봄
    그러지 말고, 먼저 코드를 어떻게 쓸지 생각한 다음 어떤 기능이 문제를 풀어주면 써야 함
    문제 → 해결책이지 반대가 아님
    예를 들어 C++ 템플릿은 대체로 끔찍하지만, 컴파일 시점 덕 타이핑이나 sizeof() 기반 패딩 자동 추가 같은 건 때때로 아주 유용함
  • 내 C++ 경험도 정확히 이랬음
    처음에는 C# 프로그래머로 임베디드 프로젝트 때문에 C를 배우고 있었는데, 흐름이 딱 같았음
    C++에는 애플리케이션과 정확히 맞아떨어지면 강력해 보이는 멋진 기능이 많음
    하지만 새 기능을 시도할 때마다 내가 하려는 일은 항상 그 상황에서 동작하지 않는 경계 사례였고, 몇 시간이나 며칠을 시도하다 포기하고 그냥 C로 씀
  • C++도 대부분의 기술처럼 제대로 배우는 노력을 들이면 더 잘 동작함
    물론 Python이나 Ruby처럼 이 경향을 벗어나는 언어도 있긴 함
  • ChatGPT나 Copilot이 그런 부분에 많이 도움 됨
    보통 오류 텍스트를 복사해서 해독하게 함

• C++은 정말 재미있고, 사람들이 갖는 불만은 맥락에 크게 좌우된다고 봄
  많은 C++ 개발자가 언어를 싫어하지만, 사실 그 혐오의 방향이 잘못된 경우가 있음
  실제로는 소프트웨어를 그리 잘 쓰지 못한 사람들이 만든 레거시 제품을 다루고 있는 경우가 많음
  나도 Rust에서 비슷한 일을 겪었는데, 회사의 기존 Rust 프로젝트에 투입됐고, 오래된 코드베이스 안에 서로 충돌하는 관례가 많았음
  잘 합성되지 않는 오류 처리 타입, 나쁜 클래스 추상화, 필요 없는 unsafe 블록 등이 있었고, 지금까지 한 프로젝트 중 가장 괴로웠음
  Rust를 탓하기 쉽지만 실은 그냥 나쁜 소프트웨어 개발이었음
  C++에 흠이 있는 건 맞지만, 사람들이 겪는 고통 상당수는 어떤 언어로 써도 엉망일 나쁜 코드를 다루기 때문임

  • C를 제외한 거의 모든 다른 언어에서는 v[x]=y를 쓸 때마다 임의의 메모리 손상을 초대하지는 않음
    C++의 std::optional은 v가 비어 있을 때 *v를 호출하면 정의되지 않은 동작이 됨
    optional의 핵심은 비어 있을 수 있는 값을 담는 것인데, optional이 비어 있을 때 가장 흔한 연산에 왜 정의되지 않은 동작을 넣는지 이해하기 어렵다
    C++을 많이 써본 입장에서 문제는 프로젝트의 모든 프로그래머가 100%의 시간 동안 100% 완벽해야 한다는 점임
    메모리 검사기와 STL 디버그 모드를 돌릴 수는 있지만, 릴리스에서도 그걸 돌리지 않는다면 테스트 스위트가 어리석거나 악의적인 사용자가 할 수 있는 모든 이상한 일을 건드려주길 기대해야 함
    소프트웨어가 이렇게 중요해진 시대에 Rust가 C++ 성능에 가까워 보이는데, 기본 기능 다수가 안전하게 쓰기 매우 어려운 언어를 쓸 가치가 있는지 의문임
    심지어 계속 더 나빠지고 있는데, 빈 std::function 호출은 assert를 던졌지만 새 std::copyable_function은 이걸 정의되지 않은 동작으로 만들었음
  • 이 말에는 공감하기 어렵다
    타입 시스템은 짜증 나고, 그렇다고 제대로 된 메모리 안전성을 얻는 것도 아님
    가장 성가신 파싱은 정말 성가시고, 포인터 붕괴 같은 C에서 물려받은 이상한 점도 그대로 있음
    그 위에 std::array 같은 새 해법을 얹으면서도 예전 방식을 없애지 못함
    실제 모듈 가져오기 시스템을 흉내 내려고 전처리기에 계속 의존하는 것도 문제이고, 그 때문에 클래스 코드 구성이나 pimpl 관용구 같은 우회가 따라옴
    본질적으로 흠이 너무 크고 많아서 더는 그 안의 아름다움을 찾기 어렵다
  • 맞는 말이지만, 더 복잡한 언어일수록 이해 불가능한 엉망을 만들기가 훨씬 쉬움
    반면 단순한 blub 언어 프로젝트는 코드베이스 상태와 무관하게 꽤 쉽게 해독되는 편임
  • 오래되긴 했지만 꽤 웃긴 C++ FQA를 참고할 만함: https://yosefk.com/c++fqa/

• 누군가 C++에서 즐거움을 느낀다니 좋지만, 개인적으로는 20년 넘게 겪은 뒤 이제 C++은 끝내야겠음
  그냥 엉망임
  정말 저수준 제어가 필요하면 흠이 있더라도 C를 다루고, 아니면 Rust, Python 등이 훨씬 나를 행복하게 해줌

  • 동의함
    그래도 C++은 계속 남을 것임
    그 언어로 쓰인 코드가 너무 많고, 확실히 익혀두면 좋은 기술이며 돈이 아주 되는 일자리도 있음
    내겐 언어가 너무 방해가 되고 지나치게 복잡하게 느껴짐
    “현대 C++”은 훌륭하고, 예전 버전은 배울 필요 없고, 새 버전마다 더 단순해진다는 담론은 알고 있음
    문제는 실제로 맡게 되는 코드베이스가 현대 C++이 아니라는 점임
    지금까지 나온 모든 기능을 다 쓰고 있고, 어렵고 함정이 가득함
    수년간 자기 프로젝트에서만 C++을 해온 사람은 어느 정도 전문성을 키워 복잡성에 면역이 될 수 있겠지만, 정말 좋은 언어는 아님
  • 시간이 지나며 C++을 더 견딜 만하게 만든 요소 중 하나는, 대부분을 자신이 생각한 방식대로 동작하고 동작이 충분히 정의된 구현으로 자연스럽게 대체하기 쉬워졌다는 점임
    핵심 자료형, 표준 라이브러리 등을 바꾸는 식임
    특히 C++20 이후에는 대체 기반이 꽤 네이티브하고 표현력 있게 느껴짐
    내가 보는 새 C++ 프로젝트 상당수는 이 방향을 강하게 택함
    애플리케이션을 위한 시스템 수준의 도메인 특화 언어를 쉽게 만들 수 있다는 건 C++의 강점임
  • C++/SDL2로 만들던 Ultima 파생 프로젝트에서는 C++ 기능을 몇 가지만 가져다 썼음
    아쉽게도 완성하지 못했지만, 기억나는 건 클래스, std::function, std::unordered_map, std::string, std::unique_ptr 정도임
    비슷한 스타일이 아니면 남의 코드를 읽는 건 상상하기 어렵다
    대규모 프로그램을 직업적으로 쓰지 않다 보니 Visitor 패턴 같은 프로그래밍 패턴을 넘는 게 가장 어려웠음
    C++이 C++11에서 멈췄으면 좋았겠음
    위원회는 지금 모든 것을 언어에 넣고 싶어 하는 것 같고, C++은 모든 틈새 프로그래밍 스타일을 지원하는 초거대 언어처럼 보임
  • C++은 완전히 엉망임
    하지만 재미있는 엉망이고, 나는 C++로 쓰는 걸 좋아함
    가끔은 그게 중요함
    Rust와의 관계는 훨씬 차갑다
    Rust를 존중하고, 특히 업무처럼 C++ 사용을 변호하기 어려운 맥락에서는 Rust가 맞다고 생각하면 쓰며, Rust가 하는 일이 중요하다고 봄
    하지만 지금까지 꽤 많은 Rust 프로젝트를 해봤는데도 쓰기는 지루하게 느껴짐
    핵심적인 면에서는 더 낫지만, 적어도 내겐 덜 즐겁다
  • Rust도 C와 같은 제어력과 저수준성을 제공하려는 언어 아닌가?
    unsafe 봉인을 풀면 정수를 포인터로 명시적으로 캐스팅할 수 있고, 예를 들어 메모리 매핑 입출력으로 하드웨어를 제어할 수도 있지 않나?

• 이 글은 범위가 넓은 긴 장광설이고, “C++”이라는 글자만으로도 사람들을 자극해서 많은 부분이 무시될 수 있음
  나도 가끔 그렇다
  불만은 “It's Not All Puppies and Butterflies” 부분으로 건너뛰면 됨
  저자는 C++11에 크게 감명받았고, 거의 20년 동안 일부러 C++을 무시한 뒤 나도 비슷하게 느꼈음
  가지고 놀 만한 패키지와 라이브러리를 소개해준 점은 좋지만, 여전히 다른 라이브러리를 내 프로젝트에 넣는 건 자주 고통스러움
  단일 파일 헤더가 떠오름
  FTXUI는 흥미로움
  그리고 정말로 cppreference.com은 대단함
  Python 문서도 꽤 좋지만, cppreference.com만큼 좋은 문서는 본 적이 없음

  • cppreference.com은 이름 그대로 참조 문서로서 매우 훌륭함
    Python 문서는 여기저기 흩어져 있고 여러 곳에서 불완전하며, 일관된 문체 편집 스타일도 부족함
    하지만 Diataxis 프레임워크 기준으로 참조 문서뿐 아니라 여러 종류의 문서를 꽤 잘 포괄함
    그 문서를 쓰는 사람들은 이 프레임워크를 명시적으로 고려하며 개선 방향을 찾음
    그래도 코드 개발과 거의 같은 방식으로 움직이는 자원봉사 기반 오픈소스 작업이긴 함
  • 학교와 대학에서 C++을 배운 뒤 곧바로 일에서는 Python/JavaScript로 옮겨갔는데, 이 글 덕분에 몰랐던 C++ 내용을 많이 채웠음
    한동안 “시스템에 더 가까이” 가고 싶었고, 옆에서 Rust를 배우는 것도 쉽지 않았음
    이 글을 보니 C++을 다시 익히면 가능할지도 모른다는 희망이 생김
    안녕 CMake… 아니, 아마 Meson이라고 해야 할지도

• 재능 있는 팀이 현대 C++ 을 잘 쓸 줄 알고 새 프로젝트를 시작한다면 C++이 훌륭하다는 데 동의함
  즐겁고 강력한 언어이며, 성능이 좋고 복잡하긴 해도 디버깅과 최적화가 비교적 직관적임
  약 5년 된 코드베이스에서 일할 기회가 있었는데, C++11 이후 기준으로 작성되어 있었고 글에서 말한 여러 이유로 매우 즐거웠음
  반면 20~30년 동안 진화한 오래된 코드베이스나, 실력 있는 사람들이 유지보수하지 않은 코드베이스라면 전혀 다른 경험이 될 것임

  • 개발자 생활은 PHP로 시작했고, 특수 데이터 타입용 플러그인이 들어간 맞춤 WordPress 테마를 만들며 일을 하면서 배웠음
    21살 때 회사가 학비를 내주겠다고 해서 컴퓨터공학 학위 과정으로 돌아갔고, 나중에 전산학으로 바꿨음
    “프로그래밍 입문” 수업 첫날 C++을 만진 순간 사랑에 빠졌음
    당시 쓰던 PHP 7에 비해 타입 시스템, 디버깅, 생태계가 훌륭했음
    매니저 허락을 받고 기존 인트라넷 앱 일부에 C++ 기반 API를 만들어 PHP가 웹소켓으로 호출하게 했고, 타입 시스템과 성능을 활용할 수 있었음
    그 시스템들은 지금도 회사 전반에서 매일 쓰이고 있고, 유지보수도 문제가 아니었음
    심지어 IBM Pase for i라는 꽤 특이한 환경에서 돌고 있는데도 그렇다
    지금은 Rust와 Axum을 써본 뒤라 그런 API를 만들 때는 Rust 생태계를 훨씬 선호하겠지만, C++도 인정받을 만함
    특히 TypeScript가 아닌 JavaScript나 PHP 같은 웹 언어에서 넘어온다면 정말 훌륭한 언어임
  • 20~30년 동안 진화했거나 실력 있는 사람들이 유지보수하지 않은 오래된 코드베이스라는 조건에서, 끔찍하지 않을 다른 언어가 떠오르지 않음
    사실 떠올릴 수 있는 여러 가능성, 예를 들어 C, Java, Fortran보다 C++을 선호할 것 같음
    예외는 C#일 수 있지만, 그 조건에 들어갈 만큼 오래됐는지는 모르겠음

• C++에 내장 정규식이 생겼고 꽤 좋다는 말과 달리, std::regex는 좋다고 하기 어렵다
  성능이 나쁘고 유니코드 지원도 부족해서 일반적으로 피하는 편이 좋음

  • 우리 회사에서 쓰는 린터도 std::regex를 쓰지 말라고 강제함
  • 성능 저하를 일으키는 명세상의 문제가 있는지 궁금함

• C++을 배웠고 즐기기도 했지만 깊게 들어가지는 않았음
  항상 C가 더 좋았고, 원래 Dune 게임 엔진이나 Unix 유틸리티처럼 C를 더 잘 배우기 위해 읽을 수 있는 최상급 코드베이스도 많음
  최근 Rust를 조금 건드려보니 C++을 쓸 강한 이유가 잘 보이지 않음
  함수형 프로그래밍에서 영감을 받은 강력한 타입 시스템과 성능의 조합은 이기기 어려워 보이고, 거의 완벽한 언어 같음
  그래도 C++을 써야 하는 레거시 이유는 분명 있을 것임
  게임 엔진, 임베디드 프로그래밍, 다른 종류의 레거시 결합 같은 것일지도 모름

  • 업무에서 C++과 Rust를 오가며 쓰는데, 솔직히 현대 C++20/23에서는 Rust를 거의 베끼는 방식으로 많은 고통 지점이 고쳐지고 있음
    새 C++ 코드베이스라면 꽤 깔끔하게 만들 수는 있음
    하지만 이 시점에 새 소프트웨어를 왜 C++로 만들지는 이해가 잘 안 됨
    C++의 성가신 점은 많음
    라이브러리/패키지 관리가 표준화되어 있지 않고, 헤더는 코드 중복이며, 표준 라이브러리는 구현에 따라 달라지고 거의 읽기 어렵다
    표준에는 이상한 동작이 있고, 사람들이 정의되지 않은 동작에 기대면서도 모르고, 할당 전 사용 문제가 있으며, 소유권 문제와 잘못된 참조 카운트로 인한 메모리 누수가 미묘하게 생김
    모든 것을 기본값 대신 const로 만들어야 하고, noexcept를 보장하려면 호출하는 모든 것의 예외를 확인해야 하며, 표준 라이브러리 작업 중 오류는 읽기 어렵다
    객체지향이 강한 코드는 사실상 기술 부채임
    C++의 LSP는 Rust처럼 추상 구문 트리를 확인해 정의를 찾는 구조적 방식이 아니라서, 탐색과 코드베이스 파악이 느림
    Rust는 nostd를 1급으로 명시 지원하지만, C++에서는 표준 라이브러리를 끄려면 컴파일러별 플래그가 필요하고 제대로 했는지 확인하기 어렵다
    그래서 임베디드 때문에 C++을 쓴다는 이유는 내겐 설득력이 약함
    Rust에도 bevy 같은 게임 엔진이 있지만 아직 새롭고, 원하면 Godot 스크립팅에 Rust를 붙일 수도 있음
    저수준 오디오도 Rust에서 똑같이 쉽고, 단일 크레이트로 크로스플랫폼 처리가 가능함
    전반적으로는 레거시 코드와 변화에 대한 주저함이 핵심이라고 봄
  • 레거시는 C++로 작성된 앱뿐 아니라 여러 차원에서 엄청나게 큼
    사용자 수, 출판되고 이용 가능한 지식과 자료, 책, 강의, 블로그, 글, 영상, 소프트웨어 라이브러리, 그리고 또 하나의 거대한 언어인 C와의 높은 호환성까지 포함됨
    이 분야에 몇 년 이상 있었던 사람에게는 소프트웨어 업계의 일반 상식에 가깝다
    나는 C++을 많이 써본 적이 없어서 제대로 된 초보자라고도 하기 어렵지만, 예전에 언어 창시자인 Bjarne Stroustrup, Scott Meyers 등의 고전 C++ 책을 사서 읽고 어느 정도 이해한 적은 있음
    다만 C는 성공적인 상용 제품을 포함해 수년간 프로덕션에서 많이 써봤음
    https://www.stroustrup.com/applications.html
    https://www.stroustrup.com
    https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
    https://en.m.wikipedia.org/wiki/Scott_Meyers
  • 낮은 지연시간이 필요하지만 정확성은 그다지 신경 쓰지 않을 때 C++이 말이 됨
    그래서 게임 개발이 가장 오래 C++에 남을 것이라고 봄
    0.001% 사용자에게 세그멘테이션 오류로 게임이 죽는다고 해도, 그래서 뭐냐는 식임
  • 초단타 거래도 가능성 있음