C's Biggest Mistake on Hacker News

[bpr]

On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder wrote:
> On Tuesday, 24 July 2018 at 13:23:32 UTC, 12345swordy wrote:
>> On Tuesday, 24 July 2018 at 09:54:37 UTC, Ecstatic Coder wrote:
>>> So, at the moment, I don't see how you can EASILY convince 
>>> people to use BetterC for C/C++ use cases, like programming 
>>> games, microcontrollers, etc.
>>
>> *Extremely powerful meta programming that blows c++ meta 
>> programming out of the water
>> *Clean readable syntax
>> *No header file nonsense
>> *Standard keyword for ASM if you really need the performance 
>> boost.
>> *Compiler enforce memory safety.
>>
>> -Alex
>
> I know.
>
> And D's builtin strings/arrays/slices/maps/etc and automatic 
> memory deallocation are part of what makes D a better 
> alternative to C++ too.

No. For many C++ users, tracing GC is absolutely not an option. 
And, if it were, D's GC is not a shining example of a good GC. 
It's not even precise, and I would bet that it never will be. If 
I'm able to tolerate a GC, there are languages with much better 
GCs than the D one, like Go and Java.

I work in a mostly C++ shop where exceptions are intolerable in 
C++ code, and in many places we use CRTP to eliminate dispatch 
overhead. DasBetterC would be usable here but it's too late given 
the existing investment in C++. Obviously there's no CRTP in 
DasBetterC without struct inheritance, but there are other 
designs to address this issue.

Besides having more betterC libraries, I'd like to see some kind 
of restricted approach to exception handling, like the ones being 
investigated in 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf. If you want a better C++, look at what people who have to use C++ use it for, and where the pain points are.