On 19.12.20 22:04, Jeeferson wrote:
> On Saturday, 19 December 2020 at 20:36:07 UTC, Jeeferson wrote:
>> On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
>>> On 19.12.20 18:15, claptrap wrote:
>>>>
>>>> 2. People could just add it to LLVM if they want i think. Might even be easier to write a whole new backend from scratch, i dont know. IE. Not having DMD doesnt preclude the benefit that Walter claims DMD gives us.
>>>>
>>>
>>> Building LLVM from scratch takes multiple hours. Building DMD from scratch (including backend) takes _seconds_.
>>
>> Anyone that says LLVM takes multiple hours obviously hasn't built it, or are using a 20 year old computer to build it.
>>
>> Once you build LLVM you don't build it again. Unless you are modifying LLVM itself, which LDC only has one or two commits that make changes, for Android for local thread storage. So if you are developing a compiler it would still only take seconds.
> 
> To add onto that, you can also down it prebuilt, it also available on most Linux distros because it is so widely used and adopted. So you won't be building it yourself most of the time anyways.
> 

Dependencies are simple in theory. In practice things sometimes go wrong. Then you have to figure out why instead of just doing what you wanted to be doing. The worst case is when a dependency is causing build trouble in some component you don't need but the build is tangled up in a way that does not easily allow you to get only the component that you actually need. E.g., I once had to build a specific commit of llvm to compile a latex file. Of course that commit did not actually compile with the latest g++, etc. I don't really see why anyone should have to touch anything related to llvm to add some new feature to the parser.

On Saturday, 19 December 2020 at 17:40:28 UTC, Timon Gehr wrote:
> On 19.12.20 18:15, claptrap wrote:
>> 
>> 2. People could just add it to LLVM if they want i think. Might even be easier to write a whole new backend from scratch, i dont know. IE. Not having DMD doesnt preclude the benefit that Walter claims DMD gives us.
>> 
>
> Building LLVM from scratch takes multiple hours. Building DMD from scratch (including backend) takes _seconds_.
>
> Why is it so hard to believe that this is a benefit that an actual compiler developer might care for? It's exactly the prevalence of this kind of common sense pragmatics that makes D so convenient to use despite all flaws. You lose that if you start adding dependencies on projects that lack it.

Tbh i never even thought about how long it takes to actually build the compilers. When people talked about compile speed, i thought they just meant how long DMD takes to compile something, not how long it takes to compile DMD. I can agree 100% that would be a hugely important issue, actually if something took 2 hours to build i wouldn't even bother.

On Sunday, 20 December 2020 at 10:19:22 UTC, claptrap wrote:
> something, not how long it takes to compile DMD. I can agree 100% that would be a hugely important issue, actually if something took 2 hours to build i wouldn't even bother.

It doesn't…

On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:
> On Saturday, 19 December 2020 at 19:38:10 UTC, Ola Fosheim Grøstad wrote:
>>
>> You realise that creating a high quality backend that is 100% bug free takes a lot of effort and that you have to maintain it in perpetuity? It isn't sufficient that someone "just does it", it also has to be correct, efficient and updated.
>>
>
> This post made me think.
>
> https://forum.dlang.org/post/umfqzznlrongfrvictus@forum.dlang.org
>
> Read point number 3.
>
>
> Basically, there are problems with DMD, sometimes crashes and has codegen bugs. Codegen bugs is definitely not something you want in a big project because they are time consuming.
>
> Thank you for posting real commercial experience with D. If I was a hard headed boss of the D project I would probably demand that the DMD backend would be scrapped and efforts should focus on stability with the support of GCC and LLVM backends.

Ilya has been working on a certain very important subset of work on behalf of Symmetry.  That mostly had to be @nogc because it needs to be usable as an Excel plugin as well as from our DSL.  And we decided to do something that conventionally speaking you should never do - porting a critical library written in a hurry in C++ and still evolving to an emerging programming language (D).  C++ mangling and ABI interoperability isn't perfect now but is a lot better than the situation when we started. We did finish it, by the way, and achieved our technical and commercial goals.

I think we only build that codebase using LDC now but more generally we use LDC for release builds and dmd for development and it is not perfect, but it is overall fine. We build with dmd nightly as well to stay ahead of breakages coming down the line.

I love the existence of gdc and the incredible range of targets it supports.  I am also in awe at what Iain has been able to accomplish.  We don't use gdc currently only because for pragmatic reasons we need to have a more current front end - although gdc is much more up to date these days.

I wonder what amount of funding would be needed for a first version of an ARM back end for DMD.

More generally I don't think D is growing too slowly.  If anything if you zoom out the time horizon, I think many of the causes of frustration amongst some users in fact reflects the fact that it can take time for organisation to catch up with growth. It takes time, energy and committed and talented people to build organisation and these things take the time they take, particularly with an open source endeavour.

On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:
> I wonder what amount of funding would be needed for a first version of an ARM back end for DMD.

I don't know, but my main worry is that it would be end up 80% dependent on Walter and delay more important stuff. Which is a cost that cannot be measured in terms of payment.

It really depends on 1. experience/knowledge/skills 2. backend familiarity 3. confidence level (release quality or test build quality?).

Rough guesstimate 1-2 months for something useable (for adapting an existing well designed backend), but that is like < 10% of the total work. Clearly not competitive quality, but enough to develop the compiler?

Maybe if someone funded an advisor so that it could be turned into a MSc master project to build a new non-optimizing backend from scratch? Sounds like a fun project and could bring new talent into the pool.


> More generally I don't think D is growing too slowly.

Yes, it is more difficult to manage if it grows fast (more demands, more fires to extinguish). The challenge is really to diversify the load and make sure that new features aren't started on before the existing feature set is solidified. If 1-2 key developers are overloaded (even if it is just mentoring) then that would be bad.

Cheers! ;-)

Some of the criticisms of DMD were fair, and I've been doing some work on them. The buglist for problems with SIMD is now down to 3 items:

https://issues.dlang.org/buglist.cgi?bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=dmd&keywords=simd&keywords_type=allwords&list_id=234194&query_format=advanced

On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:
> On Saturday, 19 December 2020 at 19:51:37 UTC, IGotD- wrote:
>> [...]
>
> Ilya has been working on a certain very important subset of work on behalf of Symmetry.  That mostly had to be @nogc because it needs to be usable as an Excel plugin as well as from our DSL.  And we decided to do something that conventionally speaking you should never do - porting a critical library written in a hurry in C++ and still evolving to an emerging programming language (D).  C++ mangling and ABI interoperability isn't perfect now but is a lot better than the situation when we started. We did finish it, by the way, and achieved our technical and commercial goals.
>
> [...]

Excel plugins don't have any issues with GC, as per my experience writing them via the .NET and COM APIs.

Why was this a must have, if you can share?

On Sunday, 20 December 2020 at 04:22:29 UTC, Timon Gehr wrote:
> On 19.12.20 22:04, Jeeferson wrote:
>> [...]
>
> Dependencies are simple in theory. In practice things sometimes go wrong. Then you have to figure out why instead of just doing what you wanted to be doing. The worst case is when a dependency is causing build trouble in some component you don't need but the build is tangled up in a way that does not easily allow you to get only the component that you actually need. E.g., I once had to build a specific commit of llvm to compile a latex file. Of course that commit did not actually compile with the latest g++, etc. I don't really see why anyone should have to touch anything related to llvm to add some new feature to the parser.

DMD rocks. Stop complaining and make PRs if you want to change something.

On Wednesday, 30 December 2020 at 12:14:28 UTC, Imperatorn wrote:
> DMD rocks. Stop complaining and make PRs if you want to change something.

Note to everyone ^, didn't mean to reply like that 😒

On Tuesday, 29 December 2020 at 21:25:37 UTC, Laeeth Isharc wrote:
>
> I wonder what amount of funding would be needed for a first version of an ARM back end for DMD.
>

I guess you'd first need to define what is ARM for DMD?  Is it ARM or Apple?  Treating both as a distinction would be really important, as the former has more multilib and ABI combinations than there are moons in the solar system.

> More generally I don't think D is growing too slowly.  If anything if you zoom out the time horizon, I think many of the causes of frustration amongst some users in fact reflects the fact that it can take time for organisation to catch up with growth. It takes time, energy and committed and talented people to build organisation and these things take the time they take, particularly with an open source endeavour.

I think it would be a fair observation to say that as of recent D has probably been both at the same time - moving fast at a glacial pace.  There are some big things on the horizon for sure that have been brewing for some time now, though not necessarily have been at the fore on people's radar.