The Future of D Runtime

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Jun 10 09:36:14 UTC 2024


On Sunday, 9 June 2024 at 03:10:26 UTC, Adam Wilson wrote:
> On Friday, 7 June 2024 at 01:23:03 UTC, Walter Bright wrote:
>> Is relying on the C runtime library really a problem? It's 
>> probably the most debugged library in history, and it's small 
>> and lightweight.
>
> For example, let's say you want to do some asynchronous I/O. 
> Forget the CRT, it just doesn't do that. So off you go to the 
> system API's anyways.

And on Posix libc is the systems API.

> Or kludges like Photon. (Don't get me wrong, Photon is a very 
> cool piece of work, but the nature of it's implementation means 
> that it suffers from the inherent limitations and drawbacks of 
> fibers, and does so in a highly obfuscated way.)

I find critique of stackful coroutines really weak to be honest. 
Implementing n:m or 1:n threads is kernel doesn’t scale, but  
combining async io with user-space fibers works beautifully. The 
only problem I see is stack sizes, and even there we can just 
reserve a lot more on x64 it’s not a problem at all.

Java after all these years is putting lots of effort to support 
virtual threads,  that would be introduced along side with normal 
threads.
Go is highly popular and doing just fine without even having 
normal threads.

> The point is more that if we want to do useful things in the 
> modern world that exists beyond the CRT, then we have to work 
> around it, and if we have to work around it anyways, why are we 
> using it at all?

On Windows I have no idea why we need to bind to libc at all. 
Synchronize with C’s io?

On Posix mostly syscall interface. That and malloc/free, 
memcpy/memset (simply because it’s optimized to death). All of 
the rest is legacy garbage no one is going to touch anyway.

> If you go with the System API's the world is your oyster. Yes, 
> there is more work upfront, but the number of capabilities we 
> would be able to enable is immense.

Being a system language D it allows anyone to use system APIs, 
meaning it’s easy to step on the toes of DRT if it uses lots of 
them.



More information about the Digitalmars-d mailing list