The Future of D Runtime

[max haughton]

On Wednesday, 5 June 2024 at 23:58:14 UTC, Adam Wilson wrote:
> For example, doing colored terminal output is so difficult 
> nobody does it, or, we are limited to the C file interface, 
> etc. To gain access to more advanced capabilities, we need to 
> use the system API’s, but these are diverse, and putting them 
> in Phobos would significantly expand the code required and make 
> maintenance a nightmare.

Firstly people do colour, sometimes not very well but it's 
clearly not "so difficult nobody does it". There should be a 
higher level way of doing it shipping with the language but 
that's more of a question of high-level tradeoffs than anything 
to do with druntime.

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.

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.



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.