
My Vision of D’s Future - ingve
https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
======
ktm5j
As someone who has only somewhat recently started using D, I would love to see
this language succeed. It's been such a pleasure to use.. scope guards, string
mixin, inline json & std.json. It's been so useful for the code I write at
work. Much love for D

The one thing I would add to this list is _documentation_! There is a lot of
good documentation available, but not for everything you would expect. For
example, I had a hard time figuring out the behavior of sub-packages within a
dub package. Some more explicit documentation on this subject would have been
appreciated.

~~~
7thaccount
Yes on documentation. They have a beginner's book and everything else is
pretty advanced or reference material. Some additional intermediate content
would be good like how the Julia project does it.

~~~
pjmlp
There are a couple of good D books on Packt.

[https://www.packtpub.com/application-
development/d-cookbook](https://www.packtpub.com/application-
development/d-cookbook)

[https://www.packtpub.com/web-development/d-web-
development](https://www.packtpub.com/web-development/d-web-development)

[https://www.packtpub.com/application-
development/learning-d](https://www.packtpub.com/application-
development/learning-d)

Plus buying them is a way to support some community members.

------
kernyan
>I think we need a ridiculously fast interpreter so that we can skip machine
code generation and linking. To me, this should be the default way of running
unittest blocks for faster feedback, with programmers only compiling their
code for runtime performance and/or to ship binaries to final users. This
would also enable a REPL.

I am most excited about this, where a language supports two modes 1)
interpreter for development, and 2) compilation for performance. Never thought
about this, but reading this, it makes perfect sense on large projects

~~~
atombender
I'm a fan of Go's "go run". For example, you can do:

    
    
      go run main.go
    

or:

    
    
      go run ./cmd/server
    

When invoked this way, Go compiles your code behind the scenes, but you don't
have to create a binary.

This means Go lends itself pretty well to ad-hoc scripting or writing small
script-like tools.

Unfortunately, Go doesn't support shebang lines, but with gorun [1] you can:

    
    
        #!/usr/bin/env gorun
    
        package main
    
        func main() {
          println("Hello world!")
        }
    

[1] [https://github.com/erning/gorun](https://github.com/erning/gorun)

~~~
btbytes
D's default package manager already allows you to write code like this which
1. runs the code like a script 2. downloads dependencies if they are required.

    
    
        #!/usr/bin/env dub
        /+ dub.sdl:
            name "allthepythons"
            dependency "d-glob" version="~>0.3.0"
        +/
    
        import std.stdio : stdout;
        import glob : glob;
        
        void main () {
            foreach (entry ; glob("/usr/local/bin/python*")) {
                stdout.writefln("%s", entry);
            }
        }

~~~
1980phipsi
Dub's documentation should use some love...

------
grawprog
I have to say, I like what I read there. I'm glad they're working more on c++
interoperability. I've ported some c++ code to D before, it wasn't not too
bad, it wasn't a lot of code, but it would be great to be able to work
directly with c++ libraries in D similarly to C libraries.

It always makes me sad D hasn't picked up more. Usually comments I see about D
seem pretty ambivalent to dismissive. It's a great language and to me has
always felt like the way C++ should have been.

It does seem to be growing in popularity. Even in the years I've been using
it, the number of libraries and community resources has expanded exponentially
and every day new code is being added to

[https://code.dlang.org/](https://code.dlang.org/)

Not to mention dub is probably the most simple straightforward build system
I've worked with.

~~~
tempsolution
The main reason that D hasn't been picked up by anyone is mostly because it is
an evolution of C++, not a revolution. Discarding an entire ecosystem for an
evolution is not going to happen. Rust took a very different approach and just
threw everything away. D looks and feels too much like C++, I would rather
have hoped that effort would have been spent on making C++ better.

~~~
p0nce
I have programmed in both for years (commercially) and don't understand the
comments about D being like C++. This is a night and day difference to me.

~~~
he_the_great
It is less about how it feels and more about how it looks.

And appearance really only changes when you hit templates. And with D you
can't tell (as an outsider) so it just looks like the non templated C++.

------
atilaneves
I didn't submit the link but I did write the blog post. AMA!

~~~
qznc
What happened to Andrei?

~~~
qznc
> Thanks, Mike. And thanks to all for the concern - I also got a few private
> emails asking me for the juicy details. Of which there are none - my family
> needs me and some volunteering activities had to give way.

> As Jonathan mentioned I'm still working with my students and working on the
> Foundation administration, legal, taxes, and finances.

> I've been involved with D since 2005. That's an eternity in this business. I
> think bringing Atila to the fore is a great positive because it brings a
> fresh perspective and approach.

from
[https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com](https://forum.dlang.org/post/qj18h2$8o1$1@digitalmars.com)

------
mhd
What about -betterC? I always thought this was a nice "pivot" for D. It would
be great to have more support for this direction. You can't avoid malloc
there, but maybe some instrumenting for leak detection or some libc
replacements that exploit or are exploited by the language.

Other than that, I'm okay with anything that was already in Eiffel or
Modula-3…

~~~
skocznymroczny
BetterC was created at first to make it easier to port D compiler from C to D.
Then people realized that it might be interesting to have D without GC and
without runtime, because it makes it trivial to port to other platforms such
as embedded, mobile or WASM.

The problem is, betterC is kind of in that awkward spot. It's not comparable
to the "real" D, and if you can live with betterC, you might as well just use
C and enjoy the wide C ecosystem.

~~~
grok2
But as a language doesn't betterC provides lots more useful features than C
(the module system, meta-programming (imagine C with generics), scope() and
many other useful things) that make it really a better language than C while
still keeping C interop. I agree that it is in an awkward spot though -- and
would have benefited from being it's own separate programming language. It
would have been a killer feature if it could also compile standard C at the
same time!

~~~
grok2
It would have been a killer feature if in betterC mode it could compile
standard C programs and be a drop-in replacement for GCC/Clang :-).

~~~
1980phipsi
You might find Atila's project dpp interesting:
[https://github.com/atilaneves/dpp](https://github.com/atilaneves/dpp)

------
gravypod
> Traditionally this is done by specifying data structures and RPC calls in an
> Interface Definition Language (IDL) then translating that to the supported
> languages, with a wire protocol to go along with it.

> With D, none of that is necessary. One can write the production code in D
> and have libraries automagically make that code callable from other
> languages.

If you're using an RPC IDL you explicitly do not want to share that code, you
want to share that API.

~~~
atilaneves
You could share D .di files, which are akin to C/C++ headers, but
automatically generated by the compiler.

~~~
anderspitman
Does this work over arbitrary concurrency barriers (ie a network), or is it
for libraries only?

~~~
gravypod
This. You definitely aren't attempting to build a service in one heap/address
space if you're using an RPC IDL.

~~~
atilaneves
You'd be surprised...

------
pornel
C++ interop sounds like a great unique selling point. Rust/Go/Swift can't
match it.

~~~
k__
Why can't Rust match that?

~~~
marcosdumay
Most languages settle down with C interop and don't bother with the added
complexity from C++. Rust is one of those, some of the concepts aren't even on
the language right now, what would lead to very non-idiomatic imports.

~~~
cpeterso
The Rust bindgen tool automatically generates Rust FFI bindings to C and C++
libraries. Mozilla uses bindgen a _lot_ to interoperate between Firefox's C++
and Rust code. IIUC, Rust and C++ code can't seamlessly call each other
unchanged, but bindgen adds FFI glue that makes it much easier.

[https://github.com/rust-lang/rust-bindgen](https://github.com/rust-lang/rust-
bindgen)

~~~
marcosdumay
The C++ on the documentation is there for the few places where there's nothing
on the interface not supported by Rust. Notice it says it generates biding for
"C (and some C++) libraries".

A C interface on C++ code is how most people do interoperability with C++
libraries. It is pretty much C, so you can just use the FFI. But it's not
really a C++ compatible FFI.

------
dmix
> We’re mostly there—using the actor model eliminates a lot of problems that
> would otherwise naturally occur.

So D comes with an actor system baked in at the language level? I like that
sort of thing after using Erlang and using some half baked libraries in other
languages.

I’m curious how good it is...

~~~
ttkciar
D comes with a lot of "casual parallelism" baked in at the language level, and
in its standard libraries. Actors are just one feature among many.

You -can- explicitly manage threads and processes like in other languages, but
much of the time there is a more lightweight, expressive construct available.

For instance, you can turn this loop: foreach(ref i; arr) i = i * i;

Into a parallelized loop by simply: foreach(ref i; parallel(arr)) i = i * i;

Example was shamelessly lifted from:
[https://tour.dlang.org/tour/en/multithreading/std-
parallelis...](https://tour.dlang.org/tour/en/multithreading/std-parallelism)

~~~
macintux
Much like immutability, I don’t generally find it compelling when a language
offers such a critical feature as just one among many. I prefer my languages
to be opinionated.

I’m curious how the actor model works on a large system with lots of 3rd party
libraries (or even different development teams) when you can’t guarantee that
everyone is using it.

------
thiago_fm
Can somebody enlighten me, why use D when there is Rust/Go?

I think on almost all cases, and also having a bigger community, it is a win
for Rust/Go.

~~~
jordigh
I find D easier to use than Rust or Go because of familiarity. It is very
obviously C and C++ inspired but without all the sharp edges.

I also love D's metaprogramming. It feels almost like lisp. Go's lack of
generics doesn't allow this and Rust's macros don't feel as comfortable for
me.

Yes, D is smaller but it's also big enough for me. I don't feel like I'm
missing out on much when I'm using D. If I need a library to do something that
isn't already in the fairly generous stdlib, I can find it on DUB.

[http://code.dlang.org/](http://code.dlang.org/)

~~~
snagglegaggle
Good post. I haven't used D much, but the only way I really see it as
"deficient" is its inability to easily create static binaries, like Go. But in
a lot of ways that is never a hard requirement (it is nice, though).

~~~
BubRoss
Why can't D create static binaries? I've never heard that before.

~~~
snagglegaggle
Sorry -- it can, but in much the same way GCC does. You need to manage all
your deps. With go it just happens, a huge time saver.

~~~
floatboth
I'm pretty sure Dub will happily manage your D deps and compile them
statically.

But I appreciate how that's not necessary and I can use only system-installed
libs with Meson and pkg-config :P

------
kitd
D needs to up its game with the Techempower benchmarks IMHO. Vibe.d has been
completely left behind by the usual Rust/Go/Java suspects. I'm very confident
that it is capable, but that isn't particularly obvious atm.

~~~
coldtea
I don't think anybody really cares about the Techempower benchmarks. Else we'd
all be using Vert.x or so.

The most popular frameworks having the 90% of deployments, are at the middle
to bottom of the Techempower benchmarks.

~~~
StreamBright
We actually do care about those benchmarks. At a certain scale it matters how
many servers you need to run a website with millions of visitors. 90% of
deployments do not have this problem, yet saying nobody cares is a bit silly.

~~~
mhh__
At that scale do you use a stock framework though?

An advantage of D in that situation is how easy it is to change the internals
of an API without those changes propagating to the surface, both by design
(e.g. UFCS, no brackets) and how that design is used (e.g. Templates)

~~~
StreamBright
Yes you do. You do not want to write everything yourself.

------
jeffrallen
This is excellent news for D, Atila is a great choice for this role.

------
rcpt
I can never believe how fast their forums load

~~~
pjmlp
It is written in D.

------
dwrodri
I would love to see D succeed as the king of interop. That would be a great
niche to fill.

------
alexashka
The one comment on the article on the page I think is spot on - I think every
programmer language designer underestimates the importance of good IDE
support.

~~~
WalterBright
> I think every programmer language designer underestimates the importance of
> good IDE support.

Oh, we're well aware of it. It's just that the language design part consumes
all our time.

~~~
giancarlostoro
Thankfully we've now got LangServer thanks to Microsoft which helps
tremendously! It means any IDE / editor can be useful once at least a single
LangServer project is made per language. Code once, use anywhere!

A good IDE used to be my hangup for D but VS Code has a very solid plugin.

------
giancarlostoro
I love D and one space I want to see more of is DMD on SBC's and moreso than
that D running on WebAssembly, Go and Rust do it. I consider Rust and Go the
main competitors to D, not sure if others would agree, but that's just my
view. Other than that it's a great language.

~~~
The_rationalist
Let's be real, in the real world D, go or rust are not competitors to
anything. Just take a look at
[http://www.modulecounts.com](http://www.modulecounts.com) to see the gap
between language ecosystems.

~~~
giancarlostoro
I'm not sure I agree with "real world" being the number of publicly available
packages. Better metric is companies using those languages:

[https://dlang.org/orgs-using-d.html](https://dlang.org/orgs-using-d.html)

[https://www.rust-lang.org/production/users](https://www.rust-
lang.org/production/users)

and we know plenty are using Go in prod, including Slack, Google (heavily for
YouTube's database layer), and many others.

~~~
Ygg2
Why did you link to start of production page?

[https://www.rust-lang.org/production/users](https://www.rust-
lang.org/production/users)

has all production users (it admittedly has a lot of Bitcoin Startups). But
lacks some important users like Microsoft (for ripgrep in Visual Studio Code)
and Facebook for its usage of Rust for Mercurial (admittedly this isn't
production ready).

~~~
giancarlostoro
I hadn't been to their users page in a while. I'll update my post.

------
arunc
It would also be good to know a high level timeline of all these visions.
Otherwise these visions will just be visions forever. For instance,
[https://wiki.dlang.org/Vision/2018H1](https://wiki.dlang.org/Vision/2018H1)
directs to
[https://github.com/dlang/projects/milestones](https://github.com/dlang/projects/milestones)
but both there seems no updates since April/May 2019.

Edit: added previous "vision" links

------
Profan
I wish standardizing documentation tooling (everyone uses a different tool
today and ddoc by default has _no_ styling, no navigation, no nothing, so
usually nobody writes docs for their code unless it's a big project like
vibe.d) and IDE support was on this list (vscode centric tools exist and
mostly work, but it's still fairly hit and miss) .. D's tooling has languished
for a long time even if it is a great language otherwise.

~~~
EvenThisAcronym
Visual D with Visual Studio is the gold standard, with full debugging,
autocomplete, and static analysis support.

Code-D with VS Code is also great, and it has fairly recently gotten funding
from the D Language Foundation for further development.

There's also DCD, D-Scanner and dfmt which can be used with a lot of different
editors.

~~~
1980phipsi
Do either Visual D or Code-D work with Linux or WSL? It would be really nice
to have the GUI for debugging linux code. Some libraries are just much easier
to get set up in linux.

~~~
aldacron
Visual D is a plugin for Visual Studio, so no. Code-D is a plugin for VS Code,
so it works anywhere VS Code does.

------
axilmar
I don't like D mainly because of the whole dichotomy between structs and
classes (and also because of many other smaller things).

But I don't think D hasn't succeeded in replacing C++ for this reason; the
reason D hasn't succeeded yet is because it's relatively unknown in the
enterprise developers circle. Most people haven't heard of D.

------
flowerlad
A major missing feature is checked exceptions. See long discussion thread
here:
[https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dl...](https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dlang.org)

~~~
Discombulator
This is glossing over the fact that checked exceptions are a very
controversial feature and that most language designers (is there any language
besides Java that supports them?) do not implement them on purpose.

~~~
flowerlad
Why is it controversial? The controversy came from C# vs Java and if you have
programmed in both you’d know that exceptions are broken in C#. Broken because
you have to catch the base Exception class if you want to avoid crashing and
that’s disrecommended by all C# linting tools.

------
fithisux
I would like to have a java to D, because a lot of scientific libraries are
done in Java. If the interop is easy and can automagically create Java
compatible libraries from D, it is a big win. Hopefully it is in the roadmap.
C++ interop not that much for me.

------
Sarahz92
There is a lot of good documentation available

------
jacobush
As long as we search for stuff on the internet with text terms (i.e. _Google_
) you've _got_ to enhance the name of the language. If only something boring
as DLang, please please do this.

I feel bouts of sympathy every time I think of D, and I'm not even a hard core
fan or anything.

No need to change the logo or anything. Just sneak in something actually
searchable ( _dlang_ , or _whatever_ ) in footers and headers of documentation
etc. Then just stick to it and Google will do the rest for you.

~~~
rickette
It's beyond me why most languages fall into this trap: C, C++, C#, D, Go, etc.
All hard to search for. Granted some of these predate the internet, but most
do not. Almost looks like some kind of secret agreement between language
designers.

~~~
tsegratis
I'm going to name my language after ' ', ascii 32

~~~
quickthrower2
What about lower case c

