Thoughts about D
Guillaume Piolat
first.last at gmail.com
Mon Nov 27 01:16:52 UTC 2017
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)
More information about the Digitalmars-d
mailing list