The Future of D Runtime

[Adam Wilson]

On Wednesday, 12 June 2024 at 08:10:53 UTC, ryuukk_ wrote:
> i had to write a custom runtime, it was easy thanks to adam's 
> POC repo, but i shouldn't have to want to do that, i did 
> because i was unable to port druntime, it's too much work, 
> since it does things it shouldn't be doing... why should i also 
> port libc???
>
> druntime was not built to be platform/architecture independent, 
> that's the only problem it has, well maybe is also too big..
>
>
> i don't like that GC is part of "core", it should me: "memory", 
> memory has "GC and allocator api", please emphasis that GC is 
> not the only way to deal with memory, it's one way of doing it 
> alongside allocators for when performance matter, D has an 
> advantage C#/GO/Java doesn't have, and they envy us, they had 
> to come up with stupid apis to write no GC code (stackalloc for 
> C# for example)

At the moment I don't see any way for the GC to not be in the 
mini-runtime since the compiler hooks it and it's required for 
compiler features. We have such an API as you propose and all it 
got us was a massive slow-down in the GC to accommodate the 
three-level v-table. We are a Runtime based language, there is 
always going to be a minimum that you are going to have to port.

> the runtime shouldn't do too much, only the strict minimum, so 
> it remains compatible with most platforms/architectures as much 
> as possible

This is just not possible in practice. Runtimes are support code 
for the application, not the compiler, the compiler hooks the 
runtime to do things, but the purpose is to make compiler 
features for the application possible. Thus as the capabilities 
of Phobos grow, so too will the support code required to make 
those features function.

For example, Event Loops are already on the board as a "must 
have", and they are going into the runtime. Another one is that 
`std.math` absolutely needs to be moved into the runtime as the 
compiler hooks some of those methods (this one is going to happen 
for Phobos 3). There are more, but the point is that the Runtime 
gets bigger, not smaller from here.  So the question becomes, how 
do we manage the growth?

> every big module should be split per platform, i like how it 
> was done with `sections.d` (`sections_android.d` 
> `sections_win64.d` etc)  i follow the same strategy for my own 
> code
>
>
> ideally the runtime should be a source file, not a system 
> library, no need to version it, no need to ship it, D compiles 
> code _VERY_ fast, it'll force everyone to not bloat it in the 
> years to come ;)

I'm reasonably sure that making DRT into a source library is not 
feasible. Some things need to be compiled and linked in.