The Future of D Runtime

[Adam Wilson]

On Thursday, 6 June 2024 at 23:50:06 UTC, max haughton wrote:

> Secondly, I think this reasoning leads towards a trap: Placing 
> an arbitrary division between phobos and druntime, or more 
> charitably placing that division in the wrong place, can lead 
> to a lot of needless debate or lost productivity.

This is actually the heart of what I am trying to resolve. Right 
now people are treating DRT as some sort of particular annoying 
compiler extension. I wrote more about this elsewhere so I won't 
duplicate.

> Unless the compiler (i.e. containing druntime) and phobos were 
> in a repo together you can end up in the same situation we had 
> before with the compiler and runtime being separate leading to 
> have numbers of double-PRs and so on, only squared.
>
> While we still have a runtime I don't think phobos should have 
> all of the nuts and bolts in it but in contrast to "maintenance 
> would be a nightmare" I posit that this be preferable to many 
> alternatives: be glad you can do the maintenance in the first 
> place. When you split things up across projects (or worse 
> repos) you lose the ability to do atomic commits, test (easily, 
> buildkite isn't easy) at the same time for example.
>

Is this a critique of my idea or the way things are today? 
Because I talked with Mike at DConf last year about merging 
Phobos into the DMD repo and he told me then that the plan has 
always been to turn D into a mono-repo project, precisely for the 
reasons you have laid out above. My assumption is that the reason 
this has not been done yet is because of the difficultly of 
getting the CI infra stood-up correctly in the DMD repo and not 
some ideological reason.

In any case, I put this on the agenda for the Monthly meeting 
next week.

>
> Aside from that I do like really the idea of ditching the C API 
> where easy e.g. purely as a gimmick I've always liked the idea 
> of hello world inlining down to a system call where applicable.
>
> There are things where the C runtime does cover up a lot of 
> hardware-specific details that we really don't need to care 
> about but other things where it's a pile of crap and worth 
> ditching.

You and me both.