On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:
> licensing issues

I can't see any... Walter would be licensed to distribute all three.

On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe wrote:
> On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:
>> licensing issues
>
> I can't see any... Walter would be licensed to distribute all three.

GDC is under GPL

On Thursday, 25 February 2016 at 03:47:33 UTC, rsw0x wrote:
> On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe wrote:
>> On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote:
>>> licensing issues
>>
>> I can't see any... Walter would be licensed to distribute all three.
>
> GDC is under GPL

Oh, my bad I reread the post. I thought he meant combine them as in single frontend/three backends in a single executable.
Nevermind.

On Thursday, 25 February 2016 at 03:05:21 UTC, Walter Bright wrote:
> On 2/18/2016 9:52 AM, Kai Nacke wrote:
>> I really like the compiler diversity.
>
> Me too. Having 3 major implementations is a great source of strength for D.

This needs to go further, currently there is no up to date, high performance, cross architecture compiler.

The way I see it is to integrate one of the compilers, best candidate is LDC, in  the release cycle.

I know that LDC is really close to get to 2.70 level, if mainline will only be for regressions and bug fixes for a while, there is a good chance LDC could catch up and be part of the daily merge-auto-tester loop. This will lower the pressure to constantly merge from LDC and allow to focus on other parts of the LDC compiler.

Can this be attainable?

On Wed, 2016-02-24 at 18:48 -0800, Walter Bright via Digitalmars-d wrote:
> […]
> 
> For comparison, C++ compiles like a pig, I've read that Rust compiles
> like a
> pig, and Go makes a lot of hay for compiling fast.

I wonder if anyone has noticed, or appreciated that, all the trendy, hipster cloud based CI servers support Go, sometimes C++ and C (sort of), but not Rust, or D.

Public CI and deployment support are increasingly an issue for FOSS projects, not just for goodness, but also for marketing.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 25 February 2016 at 02:58:08 UTC, Walter Bright wrote:
> On 2/18/2016 11:54 AM, David Nadlinger wrote:
>> But imagine that Walter
>> would have invested all the time he spent e.g. on implementing DWARF EH into
>> optimizing the LDC frontend/glue layer/backend pass structure instead. Who
>> knows, we might have an LDC-based compiler today that is faster than the DMD we
>> currently have.
>
> A big chunk of that was getting D to catch C++ exceptions. And before I did this work, neither GDC nor LDC did, either. It's not a simple matter of just turning it on given Dwarf EH.
>
> The point being, a lot of things are not going to happen for D unless I do them. Many of these require changing the front end, back end, and the runtime library in concert. It's a lot easier to make these work when the person working on it understands how all three work.
>
> Once they're done, they provide a good guide on how to get it to work with a monumental code base like the gdc and ldc backends are.

That's a good argument for keeping your backend.  I also like that it will be in D one day, meaning a completely bootstrapped D compiler. :)

It would help if you weren't doing other stuff that others could also do, as you've complained about.  You should keep a list of tasks online, ones you consider important but that others could reasonably do.  That would give them an avenue to take stuff off your plate, freeing you up to work on what you do best.

On Thursday, 18 February 2016 at 11:12:57 UTC, Jonathan M Davis wrote:
> On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote:
>> even if DMD is the official reference compiler, the download page http://dlang.org/download.html already mentions "strong optimization" as pro of GDC/LDC vs. "very fast compilation speeds" as pro of DMD.
>>
>> If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed....
>
> Yeah. dmd's compilation speed has been a huge win for us and tends to make a very good first impression. And as far as development goes, fast compilation speed matters a lot more than fast binaries. So, assuming that they're compatible enough (which ideally they are but aren't always), I would argue that the best approach would be to use dmd to develop your code and then use gdc or ldc to build the production binary. We benefit by having all of these compilers, and I seriously question that changing which one is the "official" one is going to help any. It just shifts which set of complaints we get.
>
> - Jonathan M Davis

Yep. Fast compilation during development must not be sacrificed for fast binaries. What are you really building to have fast binaries during development?

However, I strongly agree with cleaning up the language instead of adding more features.

On Thursday, 25 February 2016 at 09:04:17 UTC, Russel Winder wrote:
> I wonder if anyone has noticed, or appreciated that, all the trendy, hipster cloud based CI servers support Go, sometimes C++ and C (sort of), but not Rust, or D.

Travis CI, which is probably the one "trendy, hipster" service most would think of, has been supporting D for quite some while now due to Martin Nowak's great work. (He put Iain's name and mine on it too, but we didn't really contribute at all.)

Of course, there is always room for improving the integration with this and similar services. When I'm saying that dividing the attention between three compilers is a strategic mistake, it's not because I doubt that having multiple compilers is not a nice thing to have. It certainly is. But I'm convinced that expending the same amount of effort on the wider ecosystem would get us much farther.

 — David

On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright wrote:
> On 2/17/2016 4:35 PM, Chris Wright wrote:
>> And since DMD is
>> something like twice as fast as LDC, there's at least some argument in
>> favor of keeping it around.
>
> When I meet someone new who says they settled on D in their company for development, I casually ask why they selected D?
>
>   "Because it compiles so fast."
>
> It's not a minor issue.

+1 Well spoken

On Thursday, 25 February 2016 at 02:58:08 UTC, Walter Bright wrote:
> A big chunk of that was getting D to catch C++ exceptions. And before I did this work, neither GDC nor LDC did, either. It's not a simple matter of just turning it on given Dwarf EH.

That's beside the point, the C++ interop needed to be worked out either way and is not specific to the DMD backend. In that stupid example I gave, I was referring to the DWARF EH implementation itself, which will have taken you a non-negligible amount of time due to all the barely documented details, unless you are even more of a super-human compiler implementation expert than I already know you are. ;)

Don't get me wrong, I couldn't care less about the details of how long it took whom to implement C++ EH interop (or the fact that it did exist before in LDC/Calypso, and in the form of prototypes for vanilla GDC/LDC, etc.).

I'm only playing devil's advocate because many people here make it seem as if there was no cost to supporting multiple compilers, while there most definitely is. This ranges from the blatant duplication of work over PR issues to the fact that big language/compiler features are all but impossible to implement for anybody but you, since you are the only one who knows how to implement them on DMD (and in the current situation, not having them available in DMD would be a deal-breaker).

Sure, the fact that you know all the nitty-gritty details of one backend might make implementing certain changes easier for you, as you pointed out. But the fact that this one backend is obscure compared to the usual suspects, poorly documented and license-encumbered pretty much ensures that you will remain the only person to tackle such projects in the future.

 — David