August 29, 2015
On Saturday, 29 August 2015 at 13:06:58 UTC, David Nadlinger wrote:
> On Saturday, 29 August 2015 at 12:59:59 UTC, Adam D. Ruppe wrote:
>> I'm happy with the codegen the way it is, it is good enough for me, but let's not make mountains out of hills.
>
> But the fact is that many people are not. Even the core language team, who doesn't want their compiler to get 30% slower on the next release.

LOL. I've actually run into a fun problem with the program that I use to update dmd on my box. It needs root permissions to install dmd, so it does sudo up front to get the password and then reruns it before every command to reset the sudo timer. Before dmd switched to the D front-end, that worked, and I didn't have to type in my password again. So, I could just kick off the update program and leave. However, after the switch to D, the Phobos build and tests take longer than 5 minutes (or whatever the exact sudo timeout is), and I keep having to rerun my program to update dmd, because I run it and forget about it, and sudo eventually times out waiting for me to type in the password and terminates the update program. If my computer were faster, this wouldn't be a problem, but it worked prior to the move to D, and it doesn't now. So, from that standpoint, the 30% loss of speed in dmd is already costing me.

However, the biggest problem with dmd's slow codegen is probably ultimately PR. It's the reference compiler, so it's what folks are going to grab first and what folks are most likely to compare with their C++ code. That's comparing apples to oranges, but they'll do it. And a slow dmd will cost us on some level in that regard. The folks who know what they're doing and care about performance enough will use ldc or gdc, but it's not what the newcomers are likely to grab.

- Jonathan M Davis
August 29, 2015
On 08/30/2015 01:10 AM, Jonathan M Davis wrote:
> On Saturday, 29 August 2015 at 13:06:58 UTC, David Nadlinger wrote:
>> On Saturday, 29 August 2015 at 12:59:59 UTC, Adam D. Ruppe wrote:
>>> I'm happy with the codegen the way it is, it is good enough for me,
>>> but let's not make mountains out of hills.
>>
>> But the fact is that many people are not. Even the core language team,
>> who doesn't want their compiler to get 30% slower on the next release.
>
> LOL. I've actually run into a fun problem with the program that I use to
> update dmd on my box. It needs root permissions to install dmd, so it
> does sudo up front to get the password and then reruns it before every
> command to reset the sudo timer. Before dmd switched to the D front-end,
> that worked, and I didn't have to type in my password again. So, I could
> just kick off the update program and leave. However, after the switch to
> D, the Phobos build and tests take longer than 5 minutes (or whatever
> the exact sudo timeout is), and I keep having to rerun my program to
> update dmd, because I run it and forget about it, and sudo eventually
> times out waiting for me to type in the password and terminates the
> update program. If my computer were faster, this wouldn't be a problem,
> but it worked prior to the move to D, and it doesn't now. So, from that
> standpoint, the 30% loss of speed in dmd is already costing me.


I think there's a way to increase the default timeout. :-)
August 29, 2015
On Saturday, 29 August 2015 at 20:36:33 UTC, Laeeth Isharc wrote:
> Toy languages aren't used by the sorts of people that have built their businesses around D.  I don't think you do yourself any favours by adopting the tone you do.  It's disrespectful and unconstructive.

I've only been following this forum for a few months. I see lots of comments about the same things over and over, at various levels of constructiveness. At this point, I just sort of tune them all out. I imagine it's more frustrating for the core development team...

Maybe it would be helpful to put a sticky acknowledging some of these sort of perennial topics/criticisms and that everyone working on the language already knows about them? You could at least point people in the direction of the sticky this way. Pretty much every other forum I go to has some kind of forum rules sticky anyway.
August 30, 2015
On Saturday, 29 August 2015 at 23:16:19 UTC, Timon Gehr wrote:
> On 08/30/2015 01:10 AM, Jonathan M Davis wrote:
>> LOL. I've actually run into a fun problem with the program that I use to
>> update dmd on my box. It needs root permissions to install dmd, so it
>> does sudo up front to get the password and then reruns it before every
>> command to reset the sudo timer. Before dmd switched to the D front-end,
>> that worked, and I didn't have to type in my password again. So, I could
>> just kick off the update program and leave. However, after the switch to
>> D, the Phobos build and tests take longer than 5 minutes (or whatever
>> the exact sudo timeout is), and I keep having to rerun my program to
>> update dmd, because I run it and forget about it, and sudo eventually
>> times out waiting for me to type in the password and terminates the
>> update program. If my computer were faster, this wouldn't be a problem,
>> but it worked prior to the move to D, and it doesn't now. So, from that
>> standpoint, the 30% loss of speed in dmd is already costing me.
>
>
> I think there's a way to increase the default timeout. :-)

LOL. Likely so, but I'd prefer not to have to muck with my system settings just to be able to deal with the dmd build. What would probably be better would be to fix it so that the update program can continue from where it was left off if it needs to...

Regardless, this situation caught me by surprise, and it was a result of dmd's loss in performance with the switch to D.

- Jonathan M Davis
August 30, 2015
On Saturday, 29 August 2015 at 20:36:33 UTC, Laeeth Isharc wrote:
> doesn't seem to be able to do anything right.  D doesn't strike me as a language, project or community lacking in direction, particularly given recent developments.  I suspect resources of all sorts will come in time.

When people work on FOUR compilers then you cannot complain about lack of resources. You then need to see if you can do something to unite efforts.

> Toy languages aren't used by the sorts of people that have built their businesses around D.  I don't think you do yourself any favours by adopting the tone you do.  It's disrespectful and unconstructive.

I am not calling D a toy language, other people do and you have to come to terms with that. D has rough edges and is in an incomplete state, this has to be acknowledged rather than glossed over, it is dishonest and give developers too high expectations. That is disrespectful to potential adopters. And that is why these complaints resurface with a high pitched delivery.

> In any case, I don't wish to divert attention from what's important, so I won't say anything more on this topic.

Having a propietary in the core product is a liability in terms of creating a foundation. That actually is important. It actually would be better to reimplement a new D backend from scratch.



August 30, 2015
On Saturday, 29 August 2015 at 23:10:29 UTC, Jonathan M Davis wrote:
> It's the reference compiler, so it's what folks are going to grab first and what folks are most likely to compare with their C++ code.

Maybe we should rebrand it to be the "development preview compiler" and make gdc the "stable production compiler". or something.
August 30, 2015
On Sunday, 30 August 2015 at 01:48:06 UTC, Ola Fosheim Grostad wrote:
> When people work on FOUR compilers then you cannot complain about lack of resources. You then need to see if you can do something to unite efforts.

They aren't really four compilers. It is more like 2.1. sdc is a separate project, but dmd, ldc, and gdc share like 90% of the effort, so it is more realistic to call them 1.1 compilers rather than 3...

August 30, 2015
On Sunday, 30 August 2015 at 02:16:13 UTC, Adam D. Ruppe wrote:
> They aren't really four compilers. It is more like 2.1. sdc is a separate project, but dmd, ldc, and gdc share like 90% of the effort, so it is more realistic to call them 1.1 compilers rather than 3...

Then why are they trailing the main compiler if they represent an insignificant effort? Even at 10% it would be a lot for a 10+ year old project. I also think it is higher than that accumulated over time too (sans Phobos).

Having a non-free undocumented backend discourage people who think backend work is fun from contributing to the main compiler. Doing some open source backend work on a more lightweight well documented backend could be fun, I would think.

If you as a leader feel you lack resources you essentially have to give up some of your own for the greater good. If you end up having to do all the work yourself, then you need to rethink your strategy. Because that strategy is not sustainable.



August 30, 2015
On Sunday, 30 August 2015 at 02:13:59 UTC, Adam D. Ruppe wrote:
> On Saturday, 29 August 2015 at 23:10:29 UTC, Jonathan M Davis wrote:
>> It's the reference compiler, so it's what folks are going to grab first and what folks are most likely to compare with their C++ code.
>
> Maybe we should rebrand it to be the "development preview compiler" and make gdc the "stable production compiler". or something.

Then people write code that works on dmd just to realize GDC is 2-3 versions behind and doesn't compile their code(no offense meant to the GDC team)
August 30, 2015
On Sunday, 30 August 2015 at 02:44:51 UTC, rsw0x wrote:
>> Maybe we should rebrand it to be the "development preview compiler" and make gdc the "stable production compiler". or something.
>
> Then people write code that works on dmd just to realize GDC is 2-3 versions behind and doesn't compile their code(no offense meant to the GDC team)

That would be expected if dmd is the preview release and gdc is the stable release.

It'd be like using 2.1-alpha and expecting all the new stuff to still work when you switch to 2.0.