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

On Tuesday, 11 June 2024 at 08:53:21 UTC, Adam Wilson wrote:

I proposed a radical solution that changes all this (but the community's opinion was polarized on it):

https://github.com/dlang/dmd/pull/15887

On Wednesday, 12 June 2024 at 08:46:47 UTC, Denis Feklushkin wrote:

You introduce a makefile on top of a cryptic script to achieve it, it is over engineered

On Wednesday, 12 June 2024 at 09:31:13 UTC, ryuukk_ wrote:

Please, spend 5 minutes to understand how this script works. It just contains two cycles. On D in will be ~5 lines, I think

I also don't like Bash, but this is the only way to make code portable for all our supported platforms

This is the exact problem of druntime, it does bunch of stuff it shouldn't be doing

If the language sucks to achieve what you want to achieve, i'd personally work my way in improving the compiler, i tried once https://github.com/dlang/dmd/pull/15479

On Wednesday, 12 June 2024 at 11:39:00 UTC, ryuukk_ wrote:

The script does exactly what is needed. And only at the druntime build stage, so majority of users will never encounter it

It's not about D language, it's about only design (organsation) of the druntime source code

On Tuesday, 11 June 2024 at 09:25:15 UTC, Adam Wilson wrote:

I’ve measured the overheads of having millions of fibers with 16mb of stack even with overcommit it’s way too much. We have to go stackless much as I do not like it.

—
Dmitry Olshansky
CEO @ Glow labs
https://olshansky.me

On Thursday, 6 June 2024 at 18:00:56 UTC, Sebastiaan Koppe wrote:

Same here, and that it should be pay-as-you-go and as small as possible. Anything else should be regular D code.

On Wednesday, 12 June 2024 at 08:10:53 UTC, ryuukk_ wrote:

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.

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?

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