The Future of D Runtime

[ryuukk_]

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)


the main the runtime uses should be @nogc nothrow, to ensure that 
the base is already portable for all kind of purpose, including 
embedded


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



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 ;)