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.

On 11/26/17 16:14, 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.

Well. D has it's own idioms and patterns. So we fully expect some of the idioms that are easy in C++ to be not easy in D, and indeed that's kind of the point. If you look at the those idioms that are hard in D, it's probably because said idiom allows you to do some fantastically unsafe (and insecure) thing in C++. Yes, I am sure that it gives some performance boost, but D is not trying to be the pinnacle of language performance. D is trying to be a memory-safe language, quite intentionally at the expense of speed (see this DConf 2017 talk: https://www.youtube.com/watch?v=iDFhvCkCLb4&index=1&list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance.

We are not trying to be C++ and we are not trying to replace C++. It sounds like C++ works better for you. We are OK with that. We always recommend using what works best for you. That is after all why WE are here. :)

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
> - 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!

I hear this argument a lot, about this language or that.

It has become an argument void of any real value, in my view.

The reason is, programming needs have changed a lot, the problems being solved have changed alot, there is a great diversity in how people think about solving those problems, and a greater need to solve problems that are not solvable with current langauges.

So languages necessarily evolve according to the pressures put upon them by the environment in which they exist.

As for using features from other languages, this is a normal process of evolution -  convergent evolution. A language that is getting smaller, is NOT a language that is evolving (such a language is useful in a particular domain only).

The question is really not how 'huge' a language should or should not be. The question is how we can grasp that hugeness. The universe is huge, and extremely complex. But it can be understood (to an extent) according to some pretty basic principles. The human brain is equally 'huge' and 'complex'...but we are slowly coming to grips with (some of) it's basic princplez (deliberate spelling mistake for my friends ;-).

> - ‎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.

Sorry..what. You program in C++ and you're saying D is very verbose ;-)

I do think though, that function headers are becoming far too long .... but this maybe something that one just has to accept, if one wants to have those choices.

i.e. You can only really make them shorter, by not allowing the programmer to have those choices. And if D is about anything, it's about programmer choices.

> - ‎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.).
>

Some very smart people who design programming languages think ALL inheritance should be completely banned. I'd be very happy if that were the case. Personally, I find it very easy to be productive in D, without classes. It's annoying language/library bugs that slow down my productivity.

But think of D as a work in progress...like galaxies crashing into each other.. it doesn't happen very often..so enjoy it while you can.

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)

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:

> - 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!

IMO, I don't think it's too bad.  I'd rather have those features, than not have them.  One of the best features of D is it's modeling power.  Due to the rich feature set of D, you can model your code exactly how you think about it; you don't have to change the way you think about a problem to accommodate the limitations of your programming language.

Furthermore, compared to C++, the end results is MUCH better.  I've written a small memory-mapped IO library in both C++ and D.  It heavily leverages templates and compile-time features of both languages.  The C++ version turned into a monstrosity that even I, the author, couldn't understand.  The D version was quite beautiful and elegant, much less verbose, and even had a few features I couldn't figure out how to do in C++.

> - ‎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.

I agree, but I don't think it's as bad as C++ (see my comment above).  But, unfortunately, D has chosen the wrong defaults, IMO:

(1) We should be opting out of @safe, not opting into it
(2) D should be final-by-default (See https://wiki.dlang.org/Language_design_discussions#final-by-default for how that got shot down)
(3) Perhaps D should be nothrow by default, but I'm not sure exactly how that would work
(4) As a systems programming language first and an applications programming language second, I argue that the GC should be something we opt into, not opt out of.  With `scope` and DIP 1000 features, we may eventually get there.
(5) I think variables should be `immutable` by default like they are in Rust, but others disagree.

You get the idea.  I think part of this is due to historical accidents.  D is, unfortunately, carrying a lot of technical debt.

> - ‎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.

Many seem to think of D as a better C++, but like you, I see more of an influence from Java too.  I like the convenience of *some* of those Java-like features.  So, I consider the influence of Java somewhat of a strength in D.

> - ‎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.

I agree.  See the documentation for `scope` and DIP1000.  I think the situation may get better if we can continue momentum on those features.

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

There's also been some recent work this month on RAII with -betterC which may be of interest to you. But I still see -betterC as a copout, avoiding the difficult work of decoupling the compiler from the runtime.

> - ‎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).

I think the thread local storage is a great feature of D.  It's one of the defaults that D actually got right.  I don't care for the double-underscore convention of __gshared that seems to be borrowed from C, but we're lucky to have it.  It comes in handy sometimes.

It's hard to know what difficulty users encounter when reading the documentation.  If you think it can be improved, please submit a pull request to https://github.com/dlang/dlang.org

> - ‎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 run into those design dilemmas any time I start learning a new programming language, even with highly productive languages like C#.  It takes time for me to work through a few ideas and finally arrive at the right idioms that work.  But once they get worked out, it's cooking with gas.

> 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.

Thanks for sharing your thoughts.  It's always interesting to hear what people think.

Mike

On 27/11/2017 12:14 AM, IM wrote:

snip

> - ‎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.

There be solutions here!

struct Foo {
	final nothrow @safe @nogc {
		void a() {}
		void b() {}
	}
}

On 11/26/2017 4:14 PM, IM wrote:
> 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.

Great! Glad you're enjoying it and took the time to post your thoughts.


> - 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!

You'll find the same language in 2014 as today, it hasn't changed much. All languages (except C) in common use accrete features.

D does have some baggage that has been removed, like `typedef`, but on the whole whenever we try to remove something, someone always has built their store around it.

The good news, however, is just use the subset of D that works for you.


> - ‎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.

The idea is if you just want to write code, you can eschew using them (except 'override'), and just write code. They're all used for optimization or to provide enforceable self-documentation. Other languages would require those to be documented in the comments, which is not enforceable and even more wordy :-)

'override' is as opposed to 'virtual' which C++ requires and D doesn't.


> - ‎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.

That's true. Java looked like it was going to take over the world when D was young. These days I'd get rid of inner classes in favor of lambdas if I could, but you can just ignore inner classes.


> - ‎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.

That's true. But it's hard to beat GC for just writing code and getting it to run safely and without pointer bugs.


> - ‎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).

The idea with TLS is to deal with endemic threading bugs other languages have. The default in C/C++ is for globals to be shared, which is completely impractical to examine a large code base for. __gshared is meant to stand out and be greppable, making code much more auditable.


> - ‎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.).

D structs are value types, and classes are reference types. Everything flows from that. C++ structs and classes are the same thing, and can be used as both reference and value types at the same time, whether that works or not. I rarely find C++ classes with documentation saying if they are intended as a reference or value type, and the documentation won't prevent one from misusing it.

I'm not the only one to suggest that making the value/ref design decision is a pretty crucial one to make before designing the code. :-)


> 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.

Many people have difficulty with D when coming from, say, C++, because it does require a different way of thinking about code. This passes once one gains experience and comfort with D. After all, my early Fortran code looked just like BASIC, my C code looked like Fortran, my C++ code looked like "C with a few classes", and my D code looked a bit too much like C++ :-)

I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D. Even though it is a rote line-by-line translation, it simply looks better in D (much less of a snarl). Over time, as I refactor bits of it, it'll steadily look better. I find it significantly easier to write good looking code in D, and it is less verbose than C++.

For some trivial examples,

    C++: unsigned long long
    D: ulong

    C++: template<typename T> struct S { ... };
    D: struct S(T) { ... }

    C++: for (int i = 0; i < 10; ++i)
    D: foreach (i; 0..10)

    C++: decltype
    D: auto

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
> 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:

Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend.

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
> - 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!

btw. I found this interesting article from Rob Pike (golang).

https://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html

He discusses the reasons why C++ developers are *not* flocking to Go...which interestingly, is the very opposite with regards to D (well 'flocking' might be a slight over exaggeration ;-)

Neither (Go's) 'unnecessarily small philosophy', or (C++'s) 'unnecessarily huge philosophy' are good design philosophies. Go programmers will eventually look for 'more', and C++ programmers will continue to look for 'less'.

"When all the forces acting upon an object balance each other, the object will be at equilibrium."

On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
> - ‎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.

Have you observed a human to exist who has complained about a specific feature in D that is similar to a feature in Java? Relaying their complaints would be much more useful.

> - ‎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.

Since so much of C++'s coding style revolves around memory management, the idea that you might be able to avoid manual memory management and still not see a giant reduction in performance is transformative. It means writing code in an entirely different style. And because Java is the point of comparison for using a garbage collector, it's easy to think that a GC is impossibly inefficient. But that's because Java abuses its GC so heavily (and because Java came out in an era when having 64MB of RAM on a home computer was pretty swish).

Let's compare with how D uses the GC. Here's an example of code that I wrote in the most obvious way possible that is more efficient than the equivalent in C++, specifically because of the garbage collector:

https://github.com/dhasenan/subtex

The only nods to performance in that are when I have various Appenders reserve some space in advance.

On my 410KB reference document, this completes in 50ms. (That's 90ms faster than a Java "hello world" program.) I ported it to C# for comparison, and it took over one second. I ran a GC profiler and discovered that it allocated 4GB in string data.

The D version, by contrast, allocates a total of 12MB, runs three GC collections, and has a total pause time under 1ms. (If I add a call to `GC.collect()` just before the application exits, the total pause time exceeds 1ms but is still below 2ms.)

You might say that I could use C++ style manual memory management and get even better performance. And you'd be wrong.

The culprit for the C# version's poor performance was System.String.Substring, which allocates a copy of its input data. So "Hello world".Substring(5) creates a new char* pointing at a new memory allocation containing "Hello\0". C++'s std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version.

I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work, and it's currently just barely fast enough that I realize that I've actually run the command instead of my shell inexplicably swallowing it.


On the whole, it sounds like you don't like D because it's not C++. Which is fine, but D isn't going to become C++.