Is C++ Doomed?
I am very confused.<p>Some of these ramblings are just plain wrong, like<p>&gt; But exceptions come at a performance cost.<p>No they don&#x27;t. An exception that isn&#x27;t thrown costs nothing.<p>Also<p>&gt; Let’s say I want to know if a constructor failed. I have two options, one is to pass
in an in-out parameter, the other is to the throw an exception.<p>Using a factory function instead is a third option that avoids this. Besides, this is a false dichotomy to begin with - it&#x27;s perfectly acceptable to simply record the validity as part of the object&#x27;s state and provide access to that (especially if the state established in the ctor isn&#x27;t an invariant). So there&#x27;s more than just two options.<p>Then there&#x27;s more confusing arguments like the custom FILE wrapper. So instead of just using std::unique_ptr&lt;std::FILE, decltype(&amp;close_file)&gt;, i.e. the idiomatic solution for the past decade that the author claims to be after, they blame their C++03-style on the language? I don&#x27;t understand.<p>Fortunately they don&#x27;t provide any concrete examples of &quot;features bleeding into each other&quot;, since I suspect that would only further illustrate their lack of 
understanding and knowledge gaps...<p>They end with<p>&gt; I’m not in the business of writing the perfect program that satisfies an arbitrary standard. I’m in the business of making stuff with tools. [...]<p>Well great, then don&#x27;t use C++ if you&#x27;re not productive with it. Yes C++ is a complex language. A big portion of its complexity can be avoided by simply not using features one doesn&#x27;t need (or understand) or by limiting oneself to a reasonable subset of said features.<p>The author seems to look for something like Go instead. C++ wasn&#x27;t exactly &quot;designed&quot; and is the result of a steady evolution that kept some legacy baggage and bad earlier decisions around.