On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
Hi,
I'm a full-time C++ software engineer in Silicon Valley. I've
been learning D and using it in a couple of personal side
projects for a few months now.
First of all, I must start by saying that I like D, and wish to
use it everyday. I'm even considering to donate to the D
foundation. However, some of D features and design decisions
frustrates me a lot, and sometimes urges me to look for an
alternative. I'm here not to criticize, but to channel my
frustrations to whom it may concern. I want D to become better
and more widely used. I'm sure many others might share with me
some of the following points:
- D is unnecessarily a huge language. I remember in DConf 2014,
Scott Meyers gave a talk about the last thing D needs, which is
a guy like him writing a lot of books covering the many
subtleties of the language. However, it seems that the D
community went ahead and created exactly this language!
- D is very verbose. It requires a lot of typing. Look at how
long 'immutable' is. Very often that I find myself tagging my
methods with something like 'final override nothrow @safe @nogc
...' etc.
- It's quite clear that D was influenced a lot by Java at some
point, which led to borrowing (copying?) a lot of Java features
that may not appeal to everyone.
- The amount of trickeries required to avoid the GC and do
manual memory management are not pleasant and counter
productive. I feel they defeat any productivity gains the
language was supposed to offer.
- The thread local storage, shared, and __gshared business is
annoying and doesn't seem to be well documented, even though it
is unnatural to think about (at least coming from other
languages).
- D claims to be a language for productivity, but it slows
down anyone thinking about efficiency, performance, and careful
design decisions. (choosing structs vs classes, structs don't
support hierarchy, use alias this, structs don't allow default
constructors {inconsistent - very annoying}, avoiding the GC,
look up that type to see if it's a struct or a class to decide
how you may use it ... etc. etc.).
I could add more, but I'm tired of typing. I hope that one day
I will overcome my frustrations as well as D becomes a better
language that enables me to do what I want easily without
standing in my way.
Hi and welcome here,
I've been using D for 10 years (fulltime since 3), and my
frustrations almost mirrors yours. Probably the C++background?
I don't think D complexity negates productivity in the long run,
but you get to avoid a lot of the language in daily operations.
For me: pure, shared, synchronized and TLS-by-default are _not_
pulling their weight (off the top of my head).
Being a language "that can do what C++ can do" comes with large
requirements both in capabilities and standard library. A
language also seems more complex when we are more interested in
it and eager to learn details (C++ may teach you to give up early
on that point).
If you think about it, D has only l-values and r-values which is
much simpler than where we were before. Actually I think a "Scott
Meyers of D" would have difficulty coming up with four books of
guidelines.
The good news is that you _can_ learn D in excrutiating detail,
it's not something out of reach during a lifespan. The bad news
is that the language accumulated complexity at one point and it
can only be a long neural process (though initial familiarity
helps a lot). I don't think anyone would have described D1 as
verbose!
(Now defending no-default-constructor-for-structs: it's because
S.init is supposed to be a valid struct - which implies your
destructors should be reentrant. Buy the book for 50+ other tips)
