On Wednesday, 24 February 2016 at 22:43:07 UTC, Xavier Bigand wrote:
>
> I know Visuald support ldc, but for dub I didn't find anything on how it find which compiler to use.

I agree the docs could be better. If you type dub build --help, it shows that --compiler is an option. So you would just pass --compiler=ldc2.

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.

On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright wrote:
> 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."

I actually agree this is a big issue and one of the killer features to me.

But, I also need to point out that there's a selection bias going on here: of course D's users today like D's strengths today. If they didn't, they wouldn't be using it.

I've also heard from big users who want the performance more than compile time and hit difficulty in build scaling..

On 02/18/2016 02:06 PM, rsw0x wrote:
> On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote:
>> I really like the compiler diversity. What I miss (hint!) is a program to verify the compiler/backend correctness. Just generate a random D program, compile with all 3 compilers and compare the output. IMHO we could find a lot of backend bugs this way. This would help all D compilers.
>>
>> Regards,
>> Kai
> 
> reminds me of csmith
>  https://embed.cs.utah.edu/csmith/
> 
> I believe Brian Schott had worked on something like this for D... Did that ever go anywhere?

Brian's project is at https://github.com/Hackerpilot/generated .

I can't speak to the state of the project, but it hasn't been touched in about a year.

-- 
Paul O'Neil
Github / IRC: todayman

On Thursday, 25 February 2016 at 02:08:32 UTC, Paul O'Neil wrote:
> On 02/18/2016 02:06 PM, rsw0x wrote:
>> I believe Brian Schott had worked on something like this for D... Did that ever go anywhere?
>
> Brian's project is at https://github.com/Hackerpilot/generated .
>
> I can't speak to the state of the project, but it hasn't been touched in about a year.

I built that to fuzz test parsers, not code generation or anything else. I can pretty much guarantee that its output should not compile.

On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:
> I've also heard from big users who want the performance more than compile time
> and hit difficulty in build scaling..

I know that performance trumps all for many users. But we can have both - dmd and ldc/gdc.

My point is that compile speed is a valuable and distinguishing feature of D. It's one that I have to constantly maintain, or it bit rots away. It's one that people regularly dismiss as unimportant. Sometimes it seems I'm the only one working on the compiler who cares about it.

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.

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.

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.

On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright wrote:
> On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:
>> I've also heard from big users who want the performance more than compile time
>> and hit difficulty in build scaling..
>
> I know that performance trumps all for many users. But we can have both - dmd and ldc/gdc.
>
> My point is that compile speed is a valuable and distinguishing feature of D. It's one that I have to constantly maintain, or it bit rots away. It's one that people regularly dismiss as unimportant. Sometimes it seems I'm the only one working on the compiler who cares about it.
>
> 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.

Maybe in the future, when ldc/gdc catches up versions with dmd, we can combine them into a bundle for downloads? Then new people can just download the compiler bundle and run dmd or ldc/gdc as they like.

On Thursday, 25 February 2016 at 03:07:20 UTC, Puming wrote:
> On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright wrote:
>> [...]
>
> Maybe in the future, when ldc/gdc catches up versions with dmd, we can combine them into a bundle for downloads? Then new people can just download the compiler bundle and run dmd or ldc/gdc as they like.

licensing issues