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