On Sat, 20 Apr 2019 at 23:05, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Saturday, 20 April 2019 at 06:34:17 UTC, JN wrote:
> > If the LDC was the only compiler, I don't think people would complain as much (based on popular 'compiler framework', crossplatform, great codegen).
>
> I'm pretty sure Iain would =P
>

If only because I've never gotten LDC to work. :-P

(Nor do I have reason to believe it's been given much testing beyond x86/64, despite a good breadth of OS support).

-- 
Iain

On Sunday, 21 April 2019 at 07:10:38 UTC, Iain Buclaw wrote:
> On Sat, 20 Apr 2019 at 23:05, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On Saturday, 20 April 2019 at 06:34:17 UTC, JN wrote:
>> > If the LDC was the only compiler, I don't think people would complain as much (based on popular 'compiler framework', crossplatform, great codegen).
>>
>> I'm pretty sure Iain would =P
>>
>
> If only because I've never gotten LDC to work. :-P

It should work out of the box, if it doesn't please file a bug report.

> (Nor do I have reason to believe it's been given much testing beyond x86/64, despite a good breadth of OS support).

I used it for my honours thesis on RasPi3b+ with Raspian so it definitely works on ARM. OpenCL and CUDA also work. Never tried on MIPS, PPC or AArch64.

On Sun, 21 Apr 2019 at 09:40, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 21 April 2019 at 07:10:38 UTC, Iain Buclaw wrote:
> > On Sat, 20 Apr 2019 at 23:05, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Saturday, 20 April 2019 at 06:34:17 UTC, JN wrote:
> >> > If the LDC was the only compiler, I don't think people would complain as much (based on popular 'compiler framework', crossplatform, great codegen).
> >>
> >> I'm pretty sure Iain would =P
> >>
> >
> > If only because I've never gotten LDC to work. :-P
>
> It should work out of the box, if it doesn't please file a bug report.
>
> > (Nor do I have reason to believe it's been given much testing beyond x86/64, despite a good breadth of OS support).
>
> I used it for my honours thesis on RasPi3b+ with Raspian so it definitely works on ARM. OpenCL and CUDA also work. Never tried on MIPS, PPC or AArch64.

Right, by the way it's currently the opposite for GDC.  There's around 26 or more different CPU architectures tested, but only all on Linux.

As no one else will, I'm in the middle of building on FreeBSD, NetBSD, OpenBSD, Solaris, and DragonflyBSD in parallel and will enable phobos support for those targets shortly.

Darwin, Cygwin and MinGW will likely only be partial in gdc-9, unless there's a solution for GC scanning of emulated TLS data found in time. :-)

In that list, FreeBSD, NetBSD, and OpenBSD will need some serious work
in D runtime, for the same reasons as what we discovered on
Solaris/SPARC.  There's lots of i.e: `version (FreeBSD)` in the
extern(C) bindings, but what is really meant is `version (FreeBSD) {
version (X86) ... }`.

However if core.stdc and core.sys were generated from system headers, then there would be no problems whatsoever.

-- 
Iain

On Sunday, 21 April 2019 at 07:35:34 UTC, Nicholas Wilson wrote:
> On Sunday, 21 April 2019 at 07:10:38 UTC, Iain Buclaw wrote:
>> On Sat, 20 Apr 2019 at 23:05, Nicholas Wilson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Saturday, 20 April 2019 at 06:34:17 UTC, JN wrote:
>>> > If the LDC was the only compiler, I don't think people would complain as much (based on popular 'compiler framework', crossplatform, great codegen).
>>>
>>> I'm pretty sure Iain would =P
>>>
>>
>> If only because I've never gotten LDC to work. :-P
>
> It should work out of the box, if it doesn't please file a bug report.
>
>> (Nor do I have reason to believe it's been given much testing beyond x86/64, despite a good breadth of OS support).
>
> I used it for my honours thesis on RasPi3b+ with Raspian so it definitely works on ARM. OpenCL and CUDA also work. Never tried on MIPS, PPC or AArch64.

I also have it running on my Helios4 NAS, which is Armbian on an Marvell ARMADA® 388 ARM CPU. I built the compiler from scratch to test bootstrapping.
Worked without problems. I still didn't manage to get DWT to work but that is more a problem of the Helios4 that does not have a graphical user interface by default, which is logical as the unit does not have a graphical output.

On Saturday, 20 April 2019 at 14:36:36 UTC, Laeeth Isharc wrote:
> Experienced C++ programmers don't seem to be deterred by the
> prospect of having to learn D.  In fact they seem to see it as
> a hard-to-manufacture positive signal about the culture.
>
> I received an email from one person peripherally involved in the
> community.  I asked his compensation expectations and he said X,
> but I can negotiate if you're really using D.  He didn't even want
> to write D at work mostly but he saw it as a positive signal.
>
> I think the cost of learning D is small in relation to the cost of
> having to learn the context and codebase, certainly for a younger
> company.  For a large firm where everything is in place and it's
> mostly maintenance possibly it would be different.
>
> There aren't so many firms I am aware of with a similar approach
> in finance; being open to unconventional approaches like using an
> emerging language is a reflection of that, but really whether
> someone is a good fit in other respects but just is put off by
> some technical choices - I have not encountered that so far and
> find it quite difficult to imagine.

Hi, I was referring to the fact that there is very little / no demand for D programmers generally so it doesn't help attract programmers who might be better off learning Go, Rust, Swift, Kotlin etc.

My own experience was that I chose C++ over D three years ago in a project where D would have been nice to use, and I have already stated the reasons in a previous post [https://forum.dlang.org/post/crwhrrbdpaydnqfmdzfp@forum.dlang.org].

On Sunday, 21 April 2019 at 16:44:03 UTC, Dibyendu Majumdar wrote:
> On Saturday, 20 April 2019 at 14:36:36 UTC, Laeeth Isharc wrote:
>> Experienced C++ programmers don't seem to be deterred by the
>> prospect of having to learn D.  In fact they seem to see it as
>> a hard-to-manufacture positive signal about the culture.
>>
>> I received an email from one person peripherally involved in the
>> community.  I asked his compensation expectations and he said X,
>> but I can negotiate if you're really using D.  He didn't even want
>> to write D at work mostly but he saw it as a positive signal.
>>
>> I think the cost of learning D is small in relation to the cost of
>> having to learn the context and codebase, certainly for a younger
>> company.  For a large firm where everything is in place and it's
>> mostly maintenance possibly it would be different.
>>
>> There aren't so many firms I am aware of with a similar approach
>> in finance; being open to unconventional approaches like using an
>> emerging language is a reflection of that, but really whether
>> someone is a good fit in other respects but just is put off by
>> some technical choices - I have not encountered that so far and
>> find it quite difficult to imagine.
>
> Hi, I was referring to the fact that there is very little / no demand for D programmers generally so it doesn't help attract programmers who might be better off learning Go, Rust, Swift, Kotlin etc.
>
> My own experience was that I chose C++ over D three years ago in a project where D would have been nice to use, and I have already stated the reasons in a previous post [https://forum.dlang.org/post/crwhrrbdpaydnqfmdzfp@forum.dlang.org].

You are right, the demand for D developers is low but almost all companies demand high quality, maintainable software, written in a reasonable time.

D allows me to write exactly these kind of software in the first iteration. It is incredibly how fast I can create sophisticated software in D comparing to the well known popular languages.

Using these other languages it really feels like working against the language, while D supports me to express exactly the ideas in my mind.

Yes, there is definitely some starting investment, I know it. But that is nothing in comparison to using every day a language which slows you down.

I use Intellij with the D plugin. Code completion is done by DLS. Works great.

Kind regards
Andre

On 4/21/2019 1:47 AM, Iain Buclaw wrote:
> As no one else will, I'm in the middle of building on FreeBSD, NetBSD,
> OpenBSD, Solaris, and DragonflyBSD in parallel and will enable phobos
> support for those targets shortly.

This is great news, thank you!

On Friday, 19 April 2019 at 17:58:24 UTC, Andrei Alexandrescu wrote:
> On 4/19/19 1:39 PM, bachmeier wrote:
>> A good example of this, as I mentioned there is the latest thread on fixing Dub's problems. There are two people who want to have the final say on everything, but they are completely silent about a critical piece of official infrastructure because it's not interesting to them. There is plenty of manpower willing to do the work, but at this point there are useless conversations on the mailing list because nobody has authority to make decisions, so nothing will come of those conversations.
>
> I've had a number of answers to your framing lack of work on dub as a leadership problem. Deleted them all after chatting with a friend for a couple of hours. Let me just point it that at a certain level you are definitely right - that dub has problem _is_ a leadership problem. The trick is figuring out what the level is.
>
> Sönke Ludwig is the point of contact for Dub according to https://wiki.dlang.org/People. He, Martin, and Seb have had as much decision power as they wanted to with that project. Walter and I have accepted to integrate dub with the distribution after much insistence under an implied social contract that has since decayed.
>
> This seems like a very important project to you, so I would be glad to grant you, bachmeier, full decision power with dub and update the points of contact appropriately. This is not cheeky - I am serious. Please advise.

If you'd like, I will be happy to help out by summarizing Dub complaints that have been posted on the mailing list and collecting additional complaints and proposed solutions. I can follow the DIP model we have in place. Once things are organized (as opposed to random comments by random people on the mailing list) those who are able and willing to do the work can make the decisions. I have no formal CS background and no commercial development experience, and haven't used Dub much after giving up in frustration, so I would not be the right person to make these decisions.

On Monday, 22 April 2019 at 13:11:44 UTC, bachmeier wrote:
> If you'd like, I will be happy to help out by summarizing Dub complaints that have been posted on the mailing list and collecting additional complaints and proposed solutions. I can follow the DIP model we have in place. Once things are organized (as opposed to random comments by random people on the mailing list) those who are able and willing to do the work can make the decisions. I have no formal CS background and no commercial development experience, and haven't used Dub much after giving up in frustration, so I would not be the right person to make these decisions.

don't forget all the things about D.

On Monday, 22 April 2019 at 13:11:44 UTC, bachmeier wrote:
> On Friday, 19 April 2019 at 17:58:24 UTC, Andrei Alexandrescu wrote:
>> [...]
>
> If you'd like, I will be happy to help out by summarizing Dub complaints that have been posted on the mailing list and collecting additional complaints and proposed solutions. I can follow the DIP model we have in place. Once things are organized (as opposed to random comments by random people on the mailing list) those who are able and willing to do the work can make the decisions. I have no formal CS background and no commercial development experience, and haven't used Dub much after giving up in frustration, so I would not be the right person to make these decisions.

Submitting a DIP with the proposed changes would be very welcomed. I'm happy to assist you with it. Just ping me on the DIP PR.