Dne 12.5.2016 v 23:08 Matthias Klumpp via Digitalmars-d-announce napsal(a):
First of all, that blogpost generated way more buzz than I expected -
looks like D is highly interesting to people, which is great news :-)
To elaborate a bit more on the version incompatibilities thing: E.g.
me as a new user reads about std.concurrency.Generator, wants to use
it, and it turns out that the standard library doesn't contain it yet
(in GDC). Same for std.experimental.logger.
Okay, means I can't use these.
This is something I do not like. It would be awesome if I could use new
version of phobos (dub package for eg.) in a dmd, ldc or gdc. Having
language which is so unstable so is almost impossible to use standard
library with older frontend is really anoying.
Then, I wanted to use std.getopt - turns out the semantics have
changed and new stuff has been added there too, which I can't use.
Meh, if the docs would have at least told me that.
I knew it :). I end up with same problem with std.getopt. It was a
reason for this post:
std.getopt has been backward compatible but it was not forward
compatible. So because there is only latest docs available you are
Then, I want to use D-YAML, which depends on std.stream. But
std.stream is completely deprecated, with no clear path for me to see
to replace it. That's really bad, and it also means I can't compile my
code with making the use of deprecated stuff fail the compilation.
I am not sure what exactly this deprecation message say, but you
definitely should not used std.stream at all in a first place ;-).
That was by far the most frustrating things I experienced in D. So
ideally the docs would be split for different Phobos versions, that
would already be a great help.
Yes this would help a lot.
Then, when deprecating stuff, showing a thing that replaces it or the
proper way to write code using it would also be really nice.
E.g. wile I welcome the deprecation of std.net.curl in principle
(having to link against an external library in the standard lib is
odd), announcing to drop it before any replacement which offers
feature-parity is written is bad (sidenote: IMHO the advanced net
stuff shouldn't be in the standard library, because it's harder to
update in case of security updates and bad crypto).
It would actually be really awesome if Phobos wasn't tied to a
compiler, and all D compilers which are standard-compliant could
compile it. Then, one could assume that people have the most recent
Phobos. But it looks like it will take a longer time to get there, if
I hope it would not take so much time. This is really important if D
want to succeed.
Another thing that I didn't mention in the blogpost, but which might
be interesting is that D - unlike Rust and Go - doesn't have a way
that lets developers do a shallow-dive into the language by giving
For example, Go has the really awesome Go Tour which lets you
explore and learn the basic concepts of the language by example.
For me, going through the tour was enough to actually start writing Go
code, and while it certainly isn't complete, it is a nice way to show
off the language and give people a taste of how it looks like. Rust
has something similar with its tutorial. For D, I haven't found an
"in a nutshell" tutorial, and needed to read a bit more documentation
and employ my existing C/C++ knowledge in some cases.
Having something like the Go tour for D would IMHO be an wesome way to
attract people to try D.
There is already http://tour.dlang.io, but I do not have yet time to try
it so I can't speak about maturity and so on. Other problem is with
complexity of D. I believe even I can write book about D, which make
people able to write almost anything in D. But they will not be able to
read all D code. Go is OTOH really easy language so you need book with
around 200 pages to explain everything. But with D I am not sure that
even 1000 of pages would be enough :(.