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

Laeeth Isharc Laeeth at laeeth.com
Wed Nov 14 19:39:42 UTC 2018


On Wednesday, 14 November 2018 at 18:47:22 UTC, Dukc wrote:
> On Wednesday, 14 November 2018 at 17:08:20 UTC, sepiasisy wrote:
>> What bugs me is the shortening distance regarding what D has 
>> to offer with respect to C++.
>
> I doubt the shortening distance. While C++ does advance and D 
> isn't moving as fast as it was at 2010 (I think), I still 
> believe C++ isn't the faster evolver of the two. When the next 
> C++ standard comes out, D has improved too. Examples of what 
> might be there by then:
>
> -stable and reasonably documented DIP1000 implementation
> -Dpp able to compile real-world c++ headers
> -ability to script web pages and call the Web API without 
> needing JavaScript glue code for that
> -generally more stable implementation
> - at nogc nothrow pure @safe containers that work with allocators 
> and const/immutable
>
> And if they're really going to add all that you listed and do 
> it well, I don't think it will happen by 2020. Even if the 
> standard catches that year, the implementations are unlikely to.

If somebody says they are a C++ expert, they are in for an 
interesting time in an interview in some places, like with the 
people I work with and it usually ends up with well not like a 
world expert- I just meant I know C++ reasonably well.

If they deprecate old features and you never need to know them 
then maybe D eventually has a harder challenge to appeal to some. 
  But backwards compatibility is a basic value of the C++ 
comminity as I understand it as an observer.  Benefits to that, 
but it doesn't come for free.

Would you recommend somebody that knows scripting and used to 
program in Z80 assembler as a kid learn C++ as a practitioner 
when their job involves programming but also involves other 
things that create more value?  Maybe but it would definitely be 
a choice one could reasonably question.  Demonstrably it's not 
hard for such a person to learn D and they can be reasonably 
productive in it.

Again, it's a big wide world and the margin of language 
comparison is not always what you might think.  I never thought a 
significant commercial choice would be whether to replace 
Extended Pascal with D or Ada, but life is full of surprises and 
turns out that is the case.

Languages are about more than narrowly technical questions too - 
you can argue that some things are mere consequences of compiler 
and standard library implementations, but it's unavoidably true 
that the ecosystem and community are about values too.  There are 
broader consequences of language choice that result from those 
differences,as Joyent discovered with node.js

It doesn't do much good, I think,to worry about threats from 
perceived mighty competitors.  Steal ideas -giving due scholarly 
credit (to do so is a sign of strength and confidence too( - from 
wherever one may find them.  But it makes more sense to worry 
about making D the best language it can be - for a broad 
interpretation of language.

It's easy being the underdog because to grow at a decent 
compounded rate you can just gain users from wherever you find 
them, and it really doesn't need to be a battle to the death.  
Life isn't a zero sum game and I doubt the number of people 
writing native code as part of their job has peaked.

DPP already helps I think.  As does dstep.  Don't forget also the 
work to get STL types into druntime.

Well you're right,D does have fewer libraries.  Only 1400 on 
code.dlang.  But you also have all of C.  And I guess being able 
to use most of C++ will be a gain again also because it helps 
with incremental transitions of larger code bases.  Might still 
be some problems where you can't represent C++ types in D, but 
ask Atila about that.
It's easier for D than for Rust in this respect.

Being able to access C# libraries in D would be nice.  That's a 
next project (we have been working on autowrap for C# the other 
way around).  Dmitry Olshhansky told me about Graal.  For interop 
on JVM that doesn't look too bad.  No promises but I think 
something useful shouldn't be too bad to get to.  Won't really 
know till we try.

If one can use in future D,C,C++, Python,C#,Java libraries from D 
in a pleasant enough way that would be okay, wouldn't it ?

Remaining questions are stability, quality and tooling.  First 
two are already a lot better and I guess will be pretty good in 
time?  I don't know on the tooling how much it might cost or how 
it would be accomplished.



More information about the Digitalmars-d mailing list