It is the year 2020: why should I use / learn D?

[Joakim]

On Thursday, 15 November 2018 at 13:29:47 UTC, Andrei 
Alexandrescu wrote:
> On 11/14/18 4:07 PM, lagfra wrote:
>> https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/
>> 
>> 
>> By 2020 C++ is planning to introduce:
>> 
>> * Ranges
>> * Contracts
>> * Concepts (`__traits`)
>> * Proper constexpr
>> * Modules
>> * Reflections
>> * Green threads
>> 
>> Right now it already has:
>> 
>> * `auto` variables
>> * Ranged for (`foreach`)
>> * Lambda expressions and closures
>> * `nothrow` attributes
>> * Proper containers
>> * Proper RAII
>> 
>> In no way this is the usual trollpost (I am a participant of 
>> SAoC). What bugs me is the shortening distance regarding what 
>> D has to offer with respect to C++. While D for sure has a way 
>> better syntax (thinking of template declarations, `immutable`, 
>> UDAs) and a GC, what are the advantages of using D vs C++ if 
>> my goal is to build a complex system / product?
>> 
>> TL;DR: what will D offer with respect to C++ when almost all 
>> key features of D are present in C++20(+)?
>
> Thanks for asking. Saw several good answers, to which I feel 
> compelled to add the following.
>
> I just delivered the opening keynote for Meeting C++ 
> (https://meetingcpp.com/2018/Schedule.html). The video will 
> come about in a few days. There's a bit of a twitter storm 
> going about.

Heh, slides like that will do it:

https://mobile.twitter.com/JamesMcNellis/status/1063000460280377344

> I think C++ is not properly equipped for the next big thing, 
> which is Design by Introspection.

That was a great talk, finally clicked for me on the overview 
slides and checkedint example in that keynote.

> C++ has a history of poorly copying features from D while 
> missing their core point, which makes the import much more 
> difficult to use. The example I give in the talk is that C++ 
> initially rejected everything and anything about static if, to 
> then implement it under a different name ("whatever it is, make 
> sure it's not static if!") and entirely missing the point by 
> having if constexpr insert a new scope (whereby NOT introducing 
> the scope is the entire point of the feature in the first 
> place).
>
> So going through the motions is far from achieving real parity. 
> At the same time C++ is spending a lot of real estate on 
> language features of minor impact (concepts) or mere 
> distractions (metaclasses), both of which aim squarely not at 
> solving difficult issues in problem space, but to patch for 
> difficulties created by the language itself.

Let them keep digging deeper into their hole. If you're right 
about how D is better, someone will build the next great software 
with D and prove you right.

Speaking of which, Weka might already be it: I'm editing together 
an interview with Liran for the D blog, should be up soon.