Why D is not popular enough?

ag0aep6g via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 18 16:41:53 PDT 2016


On 08/19/2016 12:50 AM, John Smith wrote:
> Well there are some things I feel could be improved, a lot of the things
> are really just minor but what is a deal breaker for me mostly is the
> compilers. The GCC and Clang implementations are really far behind in
> terms of the version, so they are missing a lot of features. A lot of
> the features that I'd want to use D for.

LDC has been catching up quite nicely. LDC 1.0.0 (current release) is at 
front-end 2.070, and 1.1.0 (beta) is at 2.071 which matches the current 
DMD release.

https://github.com/ldc-developers/ldc/releases

> In the download section it also
> says "good optimization" but it honestly isn't. I rewrote a small
> portion for one of my projects to test out D but looking at the assembly
> a lot of it was questionable. I'd say DMD probably produced the best
> assembly but then there's the problem that it doesn't support MMX
> instructions.

I'm not very knowledgeable on optimized machine code, but as far I know, 
LDC/GDC usually produce significantly faster binaries than DMD. So when 
DMD comes out ahead, that's not typical. Might be an outlier.

[...]
> Anyways for some more minor things. I really don't like __gshared, why
> couldn't it just be named "gshared" instead. Don't like how that naming
> convention is used in C/C++ either but I feel here in D it is completely
> out of place. Nothing else uses a preceding "__" and from the
> documentation it looks like it's made to stand out cause it shouldn't be
> used.

That's exactly it. `__gshared` has a weird name because `shared` should 
generally be used instead. `__gshared` throws thread-safety out the 
window, while `shared` is supposed to at least make sure that the 
shared-ness is visible to the programmer.

> But it is used a lot, and it wouldn't be possible to do certain
> things without it. I forget but the dynamic library loader for D,
> derelict, is one such case.

Those certain things should be relatively rare low-level tasks. When 
`__gshared` is used more than `shared`, then `shared` may (currently) be 
failing its goals. Of course, a low-level project like Derelict may just 
have more use for `__gshared`.

> There's no "const T&" equivalent in D. Basically constant variables need
> to be copied and non-constant variables can be passed with the use of
> "ref". So you need to write two different functions that in essence do
> the same thing.

You can pass const variables per ref: void foo(ref const int bar) {}

What you can't do is pass rvalues in such a parameter. That's what the 
other function/overload is needed for. That doesn't mean that everything 
is just fine as it is.

[...]
> Garbage collector is in a few libraries as well. I think the only
> problem I had with that is that the std.range library has severely
> reduced functionality when using static arrays.

You may be aware of this, but you can slice a T[n] to get a T[] which is 
a range.

[...]
> Well you could say the same for the same for int. Why isn't "int + int =
> long"? Right now it is following the rule "int + int = int". Maybe cause
> the values aren't as small but I could argue the same thing. If we add
> 2147483647 with 2147483647, the value stored is -2. Under the same sort
> of thought, you probably wouldn't find that acceptable either correct?
> At some point you are going to run out of types that have larger
> storage. What is "cent + cent" going to have as a larger type? At some
> point you just have to accept that you are working with a finite set of
> numbers. For D the compromise happens with the type int. C/C++ just
> accepts that and maintains consistency rather than flip floping at an
> arbitrary type.

I don't think that C "just accepts that". It still promotes a sum of 
smaller types to int.

Observe:

----
#include<stdio.h>

int main()
{
     unsigned char a = 255;

     printf("%d\n", (a + a) / 2); /* 255 */
     printf("%d\n", (unsigned char)(a + a) / 2); /* 127 */

     return 0;
}
----

If `a + a` were an unsigned char, we'd expect the two outputs to be the 
same.

The difference between D and C is that C has implicit narrowing. I.e., 
it lets you assign an int to a char just like that, throwing away the 
high bits. D requires a cast for it.

So, why is int the go-to type? I can't answer with authority, but for D 
I think it's just because that's what C does.


More information about the Digitalmars-d mailing list