solidstate1991 kirjoitti 6.9.2024 klo 12.37:
> A lot of people are arguing (especially on Discord) that `@nogc` should be discarded entirely in favor of betterC.
> 
> [snip]

Putting my thoughts without having looked at other replies first. No idea whether I'll go along with or against with what most have written.

Of these two, my gut reaction it's betterC that should (mostly) go. It is far better for the language to be pay-as-you-go. If not using non-shared static variables and not starting threads, the langauge shouldn't (attempt to) link in threading from the runtime. If not using exceptions, exception throwing/catching shouldn't be linked in. And so on.

For the most part, simply not using the D-specific functionality would be equal to betterC in this scheme. There are some exceptions to this rule. For example, assertions normally throw an error on failure instead of just aborting, and a header-only vanilla D library probably needs to provide module constructors and destructors even if they do nothing to avoid ABI changes if such logic is added in the future.

But even those can be solved with individual compiler switches. I think betterC should ideally be only be a shortcut for some set of compiler switches that that could all be enabled individually just as well, as opposed to a monolithic set of compiler and language changes.

As for `@nogc`, I do agree it's benefit-to-weight ratio feels questionable. If we didn't have it, I would be sceptical about adding it to the language. But since it has already been in the language for a long time, it needs stronger justification for removal than rejecting it anew would need, even with editions. Plus, people do occasionally find it useful. Therefore I'm a bit sceptical about but not strongly against removing it.

On Monday, 9 September 2024 at 16:00:47 UTC, Dukc wrote:
> solidstate1991 kirjoitti 6.9.2024 klo 12.37:
>> A lot of people are arguing (especially on Discord) that `@nogc` should be discarded entirely in favor of betterC.
>> 
>> [snip]
>
> Putting my thoughts without having looked at other replies first. No idea whether I'll go along with or against with what most have written.
>
> Of these two, my gut reaction it's betterC that should (mostly) go. It is far better for the language to be pay-as-you-go. If not using non-shared static variables and not starting threads, the langauge shouldn't (attempt to) link in threading from the runtime. If not using exceptions, exception throwing/catching shouldn't be linked in. And so on.
>
> For the most part, simply not using the D-specific functionality would be equal to betterC in this scheme. There are some exceptions to this rule. For example, assertions normally throw an error on failure instead of just aborting, and a header-only vanilla D library probably needs to provide module constructors and destructors even if they do nothing to avoid ABI changes if such logic is added in the future.
>
> But even those can be solved with individual compiler switches. I think betterC should ideally be only be a shortcut for some set of compiler switches that that could all be enabled individually just as well, as opposed to a monolithic set of compiler and language changes.
>
> As for `@nogc`, I do agree it's benefit-to-weight ratio feels questionable. If we didn't have it, I would be sceptical about adding it to the language. But since it has already been in the language for a long time, it needs stronger justification for removal than rejecting it anew would need, even with editions. Plus, people do occasionally find it useful. Therefore I'm a bit sceptical about but not strongly against removing it.

as far as I know theres only 3 ways to care about betterc; and none of which get meaningful support; restructuring it to be "pay as you go" will probably not find, much less implement, these theatrical alt better compiler switches.

gc is a "stop the world" gc, but it can be managed in a real-time environment:

1. Collections are only run when a call to allocate memory from the gc is made. The gc does not randomly run, and will not run if the code is not calling the gc.

2. Collections can be disabled and enabled.

3. Real time programs have startup and shutdown, where GC can be used, because the real time part is not running then.

4. Pre-allocate memory for the real time part, so it will not need to allocate memory.

5. malloc/free can consume arbitrarily large amounts of time.

6. put the real time code in a thread that is not paused by the GC collection cycle (this also means that thread cannot call the GC, and cannot be the "owner" of the GC allocations it uses).

7. Minimize the time spent in real-time code by collecting the asynchronous events and posting them to a queue that the non-real-time code can execute.