Weaselcat:

> FWIW I'm not picking on Rust, I used it for a rather long time(while in beta, obviously) before I switched to D full time for my academic work and I don't regret my decision. I thought Rust would get more improvements than it did. I feel like they made so many poor decisions as the development went on, cut so many good features etc just to cater to the non-ML crowd that the language ended up being a frankenstein mess.
>

Hi.

Without wishing to dwell on the negatives of alternatives, might I ask what made you decide to settle on D?  Do you have collaborators who write code and, if so, how did the discussions with them go about this?  For your use case, what have been the main gains you have seen and how long did it take before these started to come through?

I am interested because I may have the chance to persuade some people to explore using D, and I would like to know honestly what some experiences are of people who have made that change.  (My personal experience may not be so easy to generalize from).


Thanks.


Laeeth.

> Self-criticism is necessary for improvement.

Yes, and what matters is after the storm has passed what you have done with that energy.  People with high standards and no immediate ability to change things often complain a lot ;)  To this newcomer, at least, the progress is impressive.

On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
> Without wishing to dwell on the negatives of alternatives, might I ask what made you decide to settle on D?  Do you have collaborators who write code and, if so, how did the discussions with them go about this?  For your use case, what have been the main gains you have seen and how long did it take before these started to come through?

I'm not weaselcat, but I'm an academic and I also tried out Rust before using D. I came to the conclusion that there was no way I could ever expect any collaborator to use Rust. The syntax was crazy. The requirement to study memory management issues (something completely irrelevant) before even reading the code was a non-starter. It's just a complicated language that is not suited for the average programmer.

D is different. As long as I avoid templates, it's easy to read the code I've written, without any experience with the language. I tried C++ (Dirk Eddelbuettel devoted a section of his Rcpp book to an example I contributed), Rust, and Go. The other realistic alternative was Go, but I chose D as a matter of personal preference.

On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
> Weaselcat:
>
>> FWIW I'm not picking on Rust, I used it for a rather long time(while in beta, obviously) before I switched to D full time for my academic work and I don't regret my decision. I thought Rust would get more improvements than it did. I feel like they made so many poor decisions as the development went on, cut so many good features etc just to cater to the non-ML crowd that the language ended up being a frankenstein mess.
>>
>
> Hi.
>
> Without wishing to dwell on the negatives of alternatives, might I ask what made you decide to settle on D?

Before I was mainly using C++ for my work(and dabbled in Rust, but never ended up switching to it)
D's C-like syntax inspires familiarity to the point where I truly believe that D is easier to port C code to than C++ because you can write D in a "cleaned up" C for the most part, and slowly turn it into D whereas C++ is essentially a completely different style. Not too many languages can really claim this, and IMO it's a huge boon.

D provides native performance directly on comparison with C/C++ while being much easier to jump in and bash out a few quick ideas(Phobos helps a lot with this.)

Phobos offers far more than the C++ standard library as well. It's nice not to have to go hunting for libraries, C++11 helped with this a little I guess but it just feels like "it's there," whereas Andrei/Walter seem to actively be working towards "you should always be using Phobos or it should be fixed."

Also, D's metaprogramming system is actually usable. I use CTFE to do a ton of precomputations at compiletime, I even recently learned that the compiler can unroll foreach loops in switches(! that's cool - D has a lot of neat tricks that nobody really seems to discuss,) I feel like I'm always learning new tricks in D, and not in the C++ way.

The ability to use C libraries with barely any fuss(!), I ported a C's library's headers to D in about 10 minutes using htod and a bit of manual touchup. This is a `killer feature` in my opinion.

Ranges/functional programming in general, C++ really has nothing on this. I think C++17 might be getting ranges but when I reviewed the paper they seemed far uglier and an afterthought(like most of C++), I've written large parts of my programs in purely functional style and LDC optimizes it to the equivalent imperative code.

D's operator overloading is extremely well designed IMO,(it just goes with the rest of the 'make D work the way you want it to' feeling of the rest of the language)

I feel like I could write a book on why I use D, so I'm going to stop now : )

> Do you have collaborators who write code and, if so, how did the discussions with them go about this?  For your use case, what have been the main gains you have seen and how long did it take before these started to come through?

No, but my advisor was very open to the idea of me using D. He was familiar with it, but never used it himself(this seems to be fairly common.)
I went from prototyping in python and porting into C++ as necessary to just doing everything in D, and I think this has saved me a lot of time.

D(md) compiles pretty fast, I think it used to have a bigger advantage here over C++ before Clang became popular but it's still pretty darn fast and makes for python-esque edit-run-debug editing style. I went from compiling my projects on the university servers to my home desktop(and it compiles faster.)

>
> I am interested because I may have the chance to persuade some people to explore using D, and I would like to know honestly what some experiences are of people who have made that change.  (My personal experience may not be so easy to generalize from).
>
>
> Thanks.
>
>
> Laeeth.


I think D's best quality is probably how approachable it is for C/C++ programmers compared to i.e, Rust which has a (weird) ML influence. I wouldn't be surprised if you could get a C or C++ programmer up to speed in D in an afternoon, at least enough to be efficient in it.

D is of course not all roses, shared still feels half implemented and left to rot(D's memory model in general.) TDPL is aging, and there's not too much other literature on D - but Ali's book is very good. The compiler situation feels odd, LDC and GDC have very few contributors despite being better than dmd at optimizing and providing a lot of extra perks - i.e, LDC lets you use all of the LLVM sanitizers like the thread, memory, etc. ones, and LDC provides in-depth optimization analysis thanks to LLVM.

But comparatively, this list is not so bad.

I'm not sure if my specific experience was what you're looking for, but maybe this helped.

On 24 May 2015 23:45, "weaselcat via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 24 May 2015 at 20:36:47 UTC, Laeeth Isharc wrote:
>>
>> Weaselcat:
>>
>>> FWIW I'm not picking on Rust, I used it for a rather long time(while in
beta, obviously) before I switched to D full time for my academic work and I don't regret my decision. I thought Rust would get more improvements than it did. I feel like they made so many poor decisions as the development went on, cut so many good features etc just to cater to the non-ML crowd that the language ended up being a frankenstein mess.
>>>
>>
>> Hi.
>>
>> Without wishing to dwell on the negatives of alternatives, might I ask
what made you decide to settle on D?
>
>
> Before I was mainly using C++ for my work(and dabbled in Rust, but never
ended up switching to it)
> D's C-like syntax inspires familiarity to the point where I truly believe
that D is easier to port C code to than C++ because you can write D in a "cleaned up" C for the most part, and slowly turn it into D whereas C++ is essentially a completely different style. Not too many languages can really claim this, and IMO it's a huge boon.
>
> D provides native performance directly on comparison with C/C++ while
being much easier to jump in and bash out a few quick ideas(Phobos helps a
lot with this.)
>
> Phobos offers far more than the C++ standard library as well. It's nice
not to have to go hunting for libraries, C++11 helped with this a little I guess but it just feels like "it's there," whereas Andrei/Walter seem to actively be working towards "you should always be using Phobos or it should be fixed."
>
> Also, D's metaprogramming system is actually usable. I use CTFE to do a
ton of precomputations at compiletime, I even recently learned that the compiler can unroll foreach loops in switches(! that's cool - D has a lot of neat tricks that nobody really seems to discuss,) I feel like I'm always learning new tricks in D, and not in the C++ way.
>
> The ability to use C libraries with barely any fuss(!), I ported a C's
library's headers to D in about 10 minutes using htod and a bit of manual touchup. This is a `killer feature` in my opinion.
>
> Ranges/functional programming in general, C++ really has nothing on this.
I think C++17 might be getting ranges but when I reviewed the paper they seemed far uglier and an afterthought(like most of C++), I've written large parts of my programs in purely functional style and LDC optimizes it to the equivalent imperative code.
>
> D's operator overloading is extremely well designed IMO,(it just goes
with the rest of the 'make D work the way you want it to' feeling of the rest of the language)
>
> I feel like I could write a book on why I use D, so I'm going to stop now
: )
>
>
>> Do you have collaborators who write code and, if so, how did the
discussions with them go about this?  For your use case, what have been the main gains you have seen and how long did it take before these started to come through?
>
>
> No, but my advisor was very open to the idea of me using D. He was
familiar with it, but never used it himself(this seems to be fairly common.)
> I went from prototyping in python and porting into C++ as necessary to
just doing everything in D, and I think this has saved me a lot of time.
>
> D(md) compiles pretty fast, I think it used to have a bigger advantage
here over C++ before Clang became popular but it's still pretty darn fast and makes for python-esque edit-run-debug editing style. I went from compiling my projects on the university servers to my home desktop(and it compiles faster.)
>
>
>>
>> I am interested because I may have the chance to persuade some people to
explore using D, and I would like to know honestly what some experiences are of people who have made that change.  (My personal experience may not be so easy to generalize from).
>>
>>
>> Thanks.
>>
>>
>> Laeeth.
>
>
>
> I think D's best quality is probably how approachable it is for C/C++
programmers compared to i.e, Rust which has a (weird) ML influence. I wouldn't be surprised if you could get a C or C++ programmer up to speed in D in an afternoon, at least enough to be efficient in it.
>
> D is of course not all roses, shared still feels half implemented and
left to rot(D's memory model in general.) TDPL is aging, and there's not too much other literature on D - but Ali's book is very good. The compiler situation feels odd, LDC and GDC have very few contributors despite being better than dmd at optimizing and providing a lot of extra perks

I find the situation being like at university looking for grants or funding, and constantly being told. 'Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success.  But no, we won't help you.'

On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote:

> I find the situation being like at university looking for
> grants or funding, and constantly being told. 'Oh yes, it is
> important what you are doing, and you must keep doing it as it is
> pivotal for future success.  But no, we won't help you.'

that's 'cause GCC is untameable beast for average Joe like me, for example. ;-)

On Sunday, 24 May 2015 at 16:03:30 UTC, Andrei Alexandrescu wrote:
> On 5/24/15 1:20 AM, weaselcat wrote:
>> IMO I think the worst thing C++ has done is blatantly ignore features
>> that have been 'killer' in D(see: the reaction to the static_if proposal)
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei

Quote: "always going to establish a new scope."

This alone will make it much less powerful that D's static if.

On Sunday, 24 May 2015 at 19:06:28 UTC, weaselcat wrote:
> Furthermore, I strongly dislike that Rust has made it completely impossible to opt out of bounds checking without annotating your code with unsafe.

But this is exactly the situation in D, isn't it? As soon as you use `arr.ptr[i]`, you're no longer @safe. Or do you mean that there's no command-line switch equivalent to -noboundscheck?

On 25 May 2015 09:45, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote:
>
> > I find the situation being like at university looking for
> > grants or funding, and constantly being told. &#39;Oh yes, it is
> > important what you are doing, and you must keep doing it as it is
> > pivotal for future success.  But no, we won&#39;t help you.&#39;
>
> that's 'cause GCC is untameable beast for average Joe like me, for example. ;-)

Both have equal complexity, so that is no excuse.  DMD just operates at a lower level, on a smaller scale, and forces you to think about the effect on generated object code.

On Mon, 25 May 2015 16:59:48 +0200, Iain Buclaw via Digitalmars-d wrote:

> On 25 May 2015 09:45, "ketmar via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>>
>> On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote:
>>
>> > I find the situation being like at university looking for grants or funding, and constantly being told. &#39;Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success.  But no, we won&#39;t help you.&#39;
>>
>> that's 'cause GCC is untameable beast for average Joe like me, for example. ;-)
> 
> Both have equal complexity, so that is no excuse.  DMD just operates at a lower level, on a smaller scale, and forces you to think about the effect on generated object code.

i'm afraid that they doesn't have equal complexity. i can read DMD code (ok, even backend, it's hard, but doable), but i cannot read GCC backend code in the same amount of time. and there are alot more things i have to know to understand GDC. i made some trivial fixes in DMD backend, yet i don't even know where to start to understand at least *something* in GCC.