C++ and D
This page reconstructs the old “C++ vs D” note. It is about new application and systems-adjacent code you control.
Literate programming still applies: C++ codebases especially accumulate “how” without “why.”
The problem with C++ as a default
C++ is several languages in a trench coat: C with classes, template metaprogramming, a moving standard, and a culture of undefined behavior with a standards-committee changelog.
For application code — GUI hosts, tools, services that are not a browser — that budget is usually the wrong purchase:
-
Complexity is the product. Move semantics, overload resolution, header hygiene, ABI, and three ways to initialize a thing are not a learning ramp. They are a career.
-
Safety is optional. Smart pointers and guidelines help. The language still lets you alias, dangle, and race by default.
-
Build and package story is fragmented. There is no Cargo. There are a dozen CMake dialects.
A loud version of the same thesis: this C++ rant on YouTube. Use it as color, not as a citation.
What D is for here
D is the suggestion for application programming and for scripting-shaped tools that still talk to the OS:
-
Syntax that stays readable (the “Python-shaped” pitch) without shipping a massive interpreter.
-
Modules, slices, and a standard library aimed at getting work done.
-
GC when you want to think about the problem;
@nogc/-betterCwhen you need to think about the heap. See D and Rust for the honest cost of that split. -
C interop when you must call into an existing world.
That is the cull: **D instead of C** for owned application code, not “never call a C library.”
What this is not
-
Not a claim that game engines, Unreal, or Qt shops should rewrite next quarter.
-
Not a claim that D’s GUI ecosystem matches those incumbents. Pair D (or Rust) in the host with a webview UI when that is the product; see UI-heavy web applications.
-
Not a claim that Rust is the wrong application language. Rust is the no-GC / ecosystem pole. D is the default when you want the high-level surface.