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