I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support. Since dmd 1 I'm dreaming to ditch C++ for D on game development but this day never comes as it seems that there's always priorities(mostly justified) that postpone this. So I had to move to rust, which I'm my opinion is a subpar language comparing with D, but at least is moving on this direction.

Am Thu, 14 May 2015 15:00:32 +0000
schrieb "Victor" <victor.v.carvalho@gmail.com>:

> I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support.

"proper arm support" depends on your definition of "arm support". GDC supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more an OS than processor architecture thing though.

On 14 May 2015 at 17:40, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 14 May 2015 15:00:32 +0000
> schrieb "Victor" <victor.v.carvalho@gmail.com>:
>
>> I think that besides all problems D have, the only one that mattered most and never was fixed was proper ARM support.
>
> "proper arm support" depends on your definition of "arm support". GDC supports ARM/GLibc/Linux just as well as X86/GlibC/Linux. Only ARM/Android, ARM/iOS and ARM/BareMetal are not supported. That's more an OS than processor architecture thing though.


We still have one disrepency in runtime though (LTR vs. RTL): https://github.com/D-Programming-Language/dmd/pull/4035

I say that, however, there are infact two discrepencies (this exists on GDC x86 vs DMD x86): https://github.com/D-Programming-Language/dmd/pull/3670

I'll be happy the day DMD stops using it's own (non-conforming to spec) ABI.

Iain.

On 08/05/2015 15:03, Chris wrote:
>
> The funny thing is that people keep complaining about the lack of tools
> for D, and when a tool is built into the language they say "That tool
> shouldn't be part of the language". Yet, if it were omitted, people
> would say "Why doesn't D have this tool built in?". Human nature, I guess.

That's because some developers are, well, idiots (that's human nature). Or to put it less bluntly, some developers have idiot ideas about what should be done in the language.

This is important for us to recognize, because it should be an important skill of the D leaders/designers to recognize which of these ideas are good, and which are not. We shouldn't follow every user's suggestion, even if there is a vocal minority behind it. It's not a case of "the customer is always right" here.


In this particular case, about tooling, my general feeling is that tooling that benefits the whole community if more developers all use the same tool, should be included in the basic D distribution. So stuff like formatting tool, testing framework, build system (DUB for example), etc. . It helps one developer if other developers use the same standard here, with regards to these tools, because then they are compatible and can be reused.

For other kinds of tools, say IDEs for example, it really doesn't affect me at all what IDEs other developers use, it makes no impact in the generated code. So it doesn't have to be included in the D distribution. (doesn't mean it can't though, it's not a strict rule)

Java for example, does not ship any IDE with the standard Java distribution, even though Oracle does work on an IDE of their own - (Netbeans).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Wednesday, 3 June 2015 at 10:40:14 UTC, Bruno Medeiros wrote:
> On 08/05/2015 15:03, Chris wrote:
>>
>> The funny thing is that people keep complaining about the lack of tools
>> for D, and when a tool is built into the language they say "That tool
>> shouldn't be part of the language". Yet, if it were omitted, people
>> would say "Why doesn't D have this tool built in?". Human nature, I guess.
>
> That's because some developers are, well, idiots (that's human nature). Or to put it less bluntly, some developers have idiot ideas about what should be done in the language.
>
> This is important for us to recognize, because it should be an important skill of the D leaders/designers to recognize which of these ideas are good, and which are not. We shouldn't follow every user's suggestion, even if there is a vocal minority behind it. It's not a case of "the customer is always right" here.
>
>
> In this particular case, about tooling, my general feeling is that tooling that benefits the whole community if more developers all use the same tool, should be included in the basic D distribution. So stuff like formatting tool, testing framework, build system (DUB for example), etc. . It helps one developer if other developers use the same standard here, with regards to these tools, because then they are compatible and can be reused.
>
> For other kinds of tools, say IDEs for example, it really doesn't affect me at all what IDEs other developers use, it makes no impact in the generated code. So it doesn't have to be included in the D distribution. (doesn't mean it can't though, it's not a strict rule)
>
> Java for example, does not ship any IDE with the standard Java distribution, even though Oracle does work on an IDE of their own - (Netbeans).

You can download the SDK together with Netbeans.

It is also the standard IDE on Solaris.

Just for the record: upgrading compilers never worked for me at least for C. Yesterday I found that whatever clang I had doesn't work so I upgraded to the latest version, which can't compile mingw headers. Bummer.