Why do C++ programmers are not interested in D?

Paulo Pinto pjmlp at progtools.org
Wed Nov 20 07:43:12 UTC 2019


On Tuesday, 19 November 2019 at 17:58:14 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 19 November 2019 at 17:23:46 UTC, bachmeier wrote:
>> There's a bit of a sample selection issue. Anyone open to GC 
>> moved to Java long ago. These days anyone still using C++ 
>> either has a good reason to fear the GC (certain real-time 
>> applications) or an irrational fear of the GC.
>
> It is not a question of fearing GC, but global collection is a 
> rather blunt tool (compared to a scan-limited single-threaded 
> collector, data-structure-local-collector or good ol' 
> refcounting). Also, GC use twice as much memory or more, than 
> carefully planned memory management.
>
>> The D of today would have had great success at recruiting C++ 
>> programmers 20 years ago, but by about 2005 or so, Java had 
>> already sucked up all the potential converts.
>
> I doubt Java had much effect on C++ programmers that gave D a 
> shot, some C++ to D converts was absorbed back to C++ from D by 
> C++11/C++14,  and Go and Rust absorbed some others...
>
> Anyway, these days the picture is much more complex. Like how 
> Kotlin is also aiming for the native compilation game with a 
> LLVM backend... so with Kotlin being the default language on 
> Android and Swift trying to become a thing on servers... well, 
> that could skew things quite a bit for C++ programmers looking 
> for managed languages.

And .NET absorbed a couple more with its adoption by the games 
industry in tooling and some major engines.

Plus the Midori and Singularity learning that ended up in 
mainstream .NET, to the point that one can use .NET Native, .NET 
Core 3 and the upcoming .NET 5 for low level stuff that a couple 
of years ago C++ would be the only option in Windows.

And with Unity rewriting parts of their engine with their C# 
subset (Data-Oriented Tech Stack (DOTS)), having C# among game 
engines scripting capabilities is starting to be a must have on 
the feature list, even if it is constrained in some form.

Regarding UIs, in what concerns OS SDKs, C++ has already lost the 
crown it had on 90's systems, nowadays it is used for the 
composition engine/visual layer and respective drivers, with 
everything else done in some managed language, with the exception 
of Microsoft, due to UWP being basically COM 2.0 and they need to 
move those MFC/ATL devs to a stack they would accept.

Even Qt now has QML, with traditional C++ widgets being an option 
only on desktops. Qt 6 is supposed to open QML deployment 
scenarios back to pure C++ coding, lets see how it turns out.

Right now, D doesn't look like a viable solution to any of those 
scenarios as C++ replacement, hence the lack of interest.




More information about the Digitalmars-d mailing list