
D Future - arunc
http://forum.dlang.org/thread/gtydhqbobwljnnvvlmjc@forum.dlang.org
======
ognyankulev

      Rust: Promotes itself to be better C but its simply a more complex language design.
    

huh? Rust tries to solve the real problem of shooting yourself in the foot in
C without compromising on being as close as possible to bare metal.

    
    
      D is C++ but improved/simplified. Its not to hard to get into, its more easy for anybody from a C background.
    

The main virtue of C++ is its vast legacy base that needs to be maintained.
Replacing C++ with D can't possibly be for the reason of being
"improved/simplified".

    
    
      Take it from a guy that spend a large part of his life in PHP.
    

This explains a lot of the statements in the publication.

~~~
simfoo
> Rust: Promotes itself to be better C but its simply a more complex language
> design.

>> huh? Rust tries to solve the real problem of shooting yourself in the foot
in C without compromising on being as close as possible to bare metal.

By having a more complex language design. You can't deny that lifetimes and
the borrow checker make Rust a much more complex language than C

~~~
baq
It's not like a simpler language makes use after free (a basic lifetime
example) go away.

~~~
thedeemon
A simpler language with a GC makes it go away.

------
qznc
The title is very misleading. This is a rant by programmer about the current
state of D.

There is very little about the future of D and it is certainly nothing
official like the Vision document [0] twice a year.

[0]
[https://wiki.dlang.org/Vision/2016H2](https://wiki.dlang.org/Vision/2016H2)

~~~
skl0
An official document that's just a wiki page that can fit almost entirely on a
single page. That is nothing more than a very brief outline of what to
accomplish with no real documentation of a plan to achieve listed goals.

No surprise this list is so long:

    
    
        Other topics from H1 underwent only little development and will be copied as ongoing topics for H2: safety, memory management, tooling, improve language stability and specification, C++ and Objective C integration, library additions, smartphone support.

------
robochat
I found the post slightly contradictory but overall strongly evoked the
frustration that the author felt. My reading is that most of the problems come
from a lack of manpower or perhaps a lack of delegation but I'm only reading
this as an outsider. I think that D is a language that I would like to use but
I don't because few seem to have heard of it. This is the catch22 problem that
D finds itself in. Popularity contests are fickle and not just restricted to
the high school playground unfortunately. Look at swift, i read about problems
with breaking changes and compiler crashes and it just doesn't seem to matter
because Apple.

Anyway, my question is, what are the weak points of D? I should state at the
outset that I have no problem with there being a GC as I'm a python programmer
not a C programmer but one who wants to learn a compiled language. I'm more
interested in any other issues that might warn me away from D.

~~~
qznc
The weak points of D?

If you want the high-level view by the project leaders what needs to be done,
look at the vision document:
[https://wiki.dlang.org/Vision/2016H2](https://wiki.dlang.org/Vision/2016H2)

D certainly needs more libraries, but which language doesn't? The currently
available stuff is: [https://code.dlang.org/](https://code.dlang.org/)

Further stuff depends on what you would use D for. You describe yourself as a
"Python programmer". Web development? In this area D is still weak. There is
only one solid framework [http://vibed.org/](http://vibed.org/) which does not
officially support any SQL database (it has Mongo and Redis though).
Personally, I think vibe.d is fine for micro services, but it is still a long
way until it could compete with Django. I built a prediction market web app
with vibe.d. It has hand-written SQL queries (should probably have used
[https://code.dlang.org/packages/hibernated](https://code.dlang.org/packages/hibernated)).
I had to write Github authentication from scratch. There are few conventions,
which is irritating if you are used to follow Django tutorials. You feel lost.

That is my experience with D. Personally, I have no issues with the standard
library like the ranter, but I assume I'm in the minority with that.

~~~
robochat
Thanks for the link to the vision document. Even the fact that such a document
exists does show that steps are already being taken to give D more direction.

I'm not really a web developer, more of a data analyst with some web services.
So the lack of SQL libraries is a disappointment.

~~~
qznc
As a data analyst, you probably use Numpy? There is ndslice in D.
[https://dlang.org/phobos/std_experimental_ndslice.html](https://dlang.org/phobos/std_experimental_ndslice.html)

This comes from the Mir package: [http://mir.dlang.io](http://mir.dlang.io)

And there is some scientific code stuff here:
[https://dlangscience.github.io/](https://dlangscience.github.io/)

~~~
robochat
The Mir package looks pretty interesting but it's quite new isnt it? Thanks
for the links.

~~~
qznc
Yes, it is new.

(Ilya, the Mir guy, is a huge fan, who champions the "betterC" D style. This
discussion triggered the rant here.)

~~~
robochat
This guy Ilya, seems to want to throw everything away and start again. Is that
really what D needs?

------
kaoD
> Rust: [...] A over active amount of fans, that do not understand its
> complex.

No. We understand it is complex. We also understand why: memory management is
complex in and of itself, but RC/GC everything (or ad-hoc memory management)
is the wrong approach for a systems language.

~~~
qznc
> RC/GC everything (or ad-hoc memory management) is the wrong approach for a
> systems language

D agrees with the "everything" part. D wants to give you options, so you can
use GC/RC/manual where appropriate.

Sadly, I have not found the time to wrestle with the Rust borrow checker
myself. I still have doubts if it is worth it. For example, assume you write a
graph data structure. To pass the lifetime analysis, you have to store the
nodes in some background store vector. If you want to free/reuse memory of
nodes, Rust essentially requires you to write a garbage collector for the
nodes yourself.

Afaik there are plans to add an optional GC to the standard library? So
ultimately, D and Rust converge to the same point from different angles. Both
want all the options. Rust started from safe manual and gains options. D
started with safe automatic and gains safety for manual.

~~~
kibwen

      > Afaik there are plans to add an optional GC to the 
      > standard library?
    

This is incorrect. There are some far-future plans to add GC hooks to the
language to allow it to interoperate with external GCs (mostly motivated for
Servo to use with Spidermonkey, Firefox's Javascript engine), but there will
never be a GC implementation shipped with the stdlib itself.

~~~
qznc
Ok, so only library-GC like [https://github.com/Manishearth/rust-
gc](https://github.com/Manishearth/rust-gc) ?

~~~
kibwen
Yes, Manish there is a Servo dev who spends some of his time thinking about
how Rust could support external GCs. I believe his goal there is to write a
library that's more-or-less analogous to the basic Boehm collector for C, as a
proof-of-concept.

------
sanxiyn
I disagree Rust is more complex. Sure, Rust is more different, but not more
complex.

~~~
ainar-g
Same goes for "Go saps all the fun out of the coding". As an ex-Ruby
programmer, with Go I've never had so much fun programming since tinkering
with C in college. Go just doesn't get in the way of implementing ideas, which
is the core of the fun.

~~~
pawadu
Same here, go feels "fun" for some reason.

Maybe its the well-thought standard library, maybe its the way the compiler
helps you. Maybe its because we can actually catch bugs at compile time
instead of those runtime errors and silent drops of javascript

------
holydude
I think we are experiencing a fatigue in general when it comes to IT and
technologies. Sure technology evolves but you can learn only so much at the
same time. People prioritize. If the technology is not appealing to me I won't
use it but at the same time if the technology is massively used and pushed by
corps and startup hype I have to at least take a look. D did not attract
enough people nor it has a backing of multi billion dollar corporation.

~~~
qznc
Reasons for D:

It is a way out of the C++ tar pit, because it does C++ interop better than
any other language. D needs to continue to outrun C++ evolving, though. See
[http://dconf.org/2016/talks/watson.html](http://dconf.org/2016/talks/watson.html)
or
[https://www.youtube.com/watch?v=IkwaV6k6BmM](https://www.youtube.com/watch?v=IkwaV6k6BmM)

It has powerful meta-programming. It is effectively the opposite of Go, which
does not even have generics. This certainly provides foot shooting as well, so
other languages (e.g. Rust) are more conservative with that. D examples:
[https://qznc.github.io/d-tut/meta.html](https://qznc.github.io/d-tut/meta.html)

Those are the two reasons, which D has ahead of _all_ other languages (ok, not
Lisp wrt meta-programming). If you compare it to another specific language,
there are more things to talk about.

------
fithisux
Dlang's future is bright. It is the one true C++. In a related article,
someone proposes C++ for physicists instead of Fortran. I propose to use Dlang
or evolve Fortran to be more D-like. But take a look at the vast research C++
code. It is there unmaintained and unmaintainable. Dlang would make a huge
difference here. The best are yet to come. C++ suffers from a serious
personality disorder. It is C / it is SML / it is Python and finally it is
perplexing and dangerous like JavaScript. If I had to use C++, I would stick
to C. If I could change C++, I could throw away OO and Exceptions and see how
to integrate templates and closures to C and make the language less forgiving.

~~~
jcoffland
One of the great things about C++ is that it weeds out the shitty developers.
Not that there isn't plenty of shitty C++ code out there. There's just not a
lot of C++ code out there that's both shitty and kind of works. If you don't
do C++ right it will fail spectacularly. Poorly written software in languages
like Java, Go, Python, etc. can hobble along miserably for decades because
when it's broke it probably still kind of works event if it's slow and
constantly spits stack traces. A C++ program has to be beautiful or it
probably wont last long.

~~~
fithisux
I am a shitty developer, but as a researcher, I have common sense and my BS
radar shows a very big signal at C++ direction. When I see problematic C++ I
do not start blaming the developers. Part of the problem is the developer and
the other part ~ 50% is the language. Since I am a shitty developer and a
coward, I would never do C++ buddy jumping again. Last time I pissed my
underwear. The others, who didn't back-off, destroyed a 200.000 EU research
program fixing bugs, refactoring and seeking the holy Grail of low-level
performance instead of doing meaningful research and improving algorithmic
complexity.

~~~
jcoffland
Thank you for admitting it and knowing your limitations. The world could be
saved a lot of time and money if more people followed your example.

However, as with any challenging skill in life, you have to be shitty at C++
before you can hope to be good at it. We need some brave souls to attempt to
become good programmers otherwise we won't have any. The biggest problem with
software today is all the shitty programmers out there who are employed as if
they were good at it. C++ helps weed those programmers out because it's very
difficult to be at all productive in that language of you're shitty.

------
Bino
As a language designer, I highly admire the design choices of D and happily
copy them.

~~~
WalterBright
Yes, a lot of D's choices are finding their way into other languages :-)

------
flavoie
I don't understand why it's such a big deal with the GC.

Ok if you want to build drivers or OSes related stuff.

For AAA games, I can understand, but they will not switch to a new language as
long as there is no engine like Unreal or Unity3D (GCed) that worth the
switch. And the rest are indie and a GC will not affect performance.

For web services, GUI application, the GC would be desirable because it will
enable the developper to work on the business model and not the computer model
and it will removed stupid memory management kind of bugs. Plus, 1200 fps vs
1120 fps is not faster since we can't see the difference.

Is it that the D's GC is really slow or really memory inefficient?

------
p0nce
Not sure why an overall rant post is given this visibility

------
verroq
>Go: Its is a "simple" language. But its forced restrictions at times are so
annoying its saps all the fun out of the coding. Its not really C. Its more
Basic on steroids. Unfortunately while Go has huge amount of traction and
packages ( 70k from my count ), the quality is also... It has a few real gems
those gems are a result of the mass amount of packages. It has its own market.
A scripting replacement market mostly.

lol no

~~~
johnnydoebk
>> lol no

That was my reaction as well. I'm surprised that this kind of "deep" analysis
is on the front page.

------
kevlar1818
It's hard to take a post like this seriously when it uses such awful grammar
and spelling.

~~~
skl0
Not that difficult, you just have to understand english isn't everyone's first
language. If you've ever taken the time to learn another language, you would
have realized it is very difficult to do. Especially later in life. If a child
as young as 11 was never exposed to language, they might never be capable of
understanding it.

