On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:

I don't think ppl are saying "want more gc" per se, just don't remove it. I think there's a difference.

On Sunday, 25 April 2021 at 19:57:53 UTC, Imperatorn wrote:

it needs to be removed and put as a library

so language features doesn't depend on the library

i don't want to stick with core.stdc and stick with a language that only get new features for the people who rely on the GC

On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:

I kinda agree, but I think it would be quite some work to make that happen.

On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:

That has nothing to do with this thread. In order to have GC support you need compiler support, obviously.

On Sunday, 25 April 2021 at 19:41:39 UTC, russhy wrote:

D is open source, you are free to take care of your special flavoured D.

On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:

There is already Volt language, and Odin and Zig languages which is very D inspired and "simple" compared to D, there is a lot to choose from.
But Take GC from D and you get C2 language (guess where it is now? oh I've heard they given up and started C3 language which is even better than C2, fantastic!), and there was even more "simple" C-- (C minus minus) language, but can you guess where it is now?
Or maybe he want to repeat Python 2 vs 3 story? That was almost killed entire language. D just can't afford switching direction amid its course. But what if this really necessary? Ok, why not, just put it under a new name. But don't touch the original.

That guy teaches us about how bad GC is and provides nonsensical examples of how brave developers avoid GC by all means because of just how evil it is, meanwhile Unity have been working just fine on mobile for 10+ years, and UE4 works just fine (CPU performance wise) on average 4 years old smartphone.

I also like how he hijacked the thread and expects answers from Walter and Andrey who never showed up in the thread. He demands from them make something because he wanted it.
That's definitely not going to work.

If he is so serious about reducing GC dependency he could probably start patching phobos with no-GC functionality to be on par, that would be at least useful, but in the long run it will just add clutter, technical debt and bloat(omg!).
To make phobos usable with @nogc it would need some serious rethinking, research and planning. It is not just "remove GC" and done, this will require adding monads and stuff, pattern matching, and more. The result will probably end up look like Rust too.

On Sunday, 25 April 2021 at 20:02:32 UTC, russhy wrote:

I can't even agree with that.
Simply creating arrays and exceptions make prototyping so much faster and more convenient with a GC, I will never miss that again.
And after profiling there are almost never more than a very few inner loops where removing the GC is a performance gain - so I turn it of in those few places and do the manual memory management (which at least is feasible if it is only about few objects) and have both: fast development time and fast execution time. Why would anyone ever want to change this?

In fact: it doesn't matter if the GC is slow and imperfect. 90% of the code is executed so rarely that bad GC just has no measurable effect. And in the remaining 10% you can turn it off.

On Monday, 26 April 2021 at 11:33:48 UTC, Dominikus Dittes Scherkl wrote:

Well, it does matter if you have to halt 8-32 threads when scanning all memory that may contain pointers. If that is the only option then automatic reference counting with optimization is a better choice, but I think a mix of task-local GC og global RC (with optimization) is a reasonable trade-off.

On Monday, 26 April 2021 at 06:35:25 UTC, Paulo Pinto wrote:

say this to the people who want to ruin D with more GC, they are free to make their own fork caleld DJava

On Monday, 26 April 2021 at 13:40:18 UTC, russhy wrote:

This is just pure GC phobia at this point of time.

-Alex