www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Discussion about deprecating nogc and workarounds

reply solidstate1991 <laszloszeremi outlook.com> writes:
A lot of people are arguing (especially on Discord) that ` nogc` 
should be discarded entirely in favor of betterC.

Here are my thought on the subject:

- When it comes for the standard runtime and library, for the 
most part, yes, but maybe keep around ` nogc` for the occasional 
student that wants to get into real-time stuff like audio 
development early on, as an option.
- Due to (a world stopping) garbage collection is interferring 
with real time applications, my solution for that are 
community-driven runtimes for each target application, many of 
which already exists.

My only concern with the latter is, that people could pull yet 
another case of D1/Tango, if some people are really stubborn 
about doing everything their own way, thus stuff have to 
implemented multiple times. While competition can be a good thing 
and lead to multiple choices of the end user, it can lead to 
self-sabotage. On the other hand, people can just fork each 
others code then refine them to the target runtime.

I'll look into some of those already existing runtimes, then 
think about how should I proceed, as I decided I would need 
something custom for game development. Came to D because I didn't 
want to bother with header files in C/C++, stayed because 
alternatives like Rust and Zig have their own issues, and I'll 
stay because I want to believe in the future of the language.
Sep 06
next sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.


My only beef with ` nogc` is that too many parts of Phobos aren’t 
` nogc`-compatible even if they can be in principle.
Sep 06
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.


If they want to use betterC, why not just let them use betterC? 
If you want to use D features not in betterC, then  nogc is 
helpful, no?
Sep 06
parent reply Sergey <kornburn yandex.ru> writes:
On Friday, 6 September 2024 at 13:05:15 UTC, jmh530 wrote:

 On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 
 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.


 If they want to use betterC, why not just let them use betterC? 
 If you want to use D features not in betterC, then  nogc is 
 helpful, no?


Actually the point was to kill both :)
Because it make harder for internal things in compiler
Sep 06
parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 6 September 2024 at 13:11:41 UTC, Sergey wrote:

  nogc


 Actually the point was to kill both :)
 Because it make harder for internal things in compiler


Until dlang has several explicit full time mantainers for 
supporting for every new arch, killing nogc would make the shit 
situation of broken and pretend support of embedded and wasm 
completely unthinkable.

D will not be getting the man power for that, so nogc needs to 
stay
Sep 06
prev sibling next sibling parent Johan <j j.nl> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.

 Here are my thought on the subject:

 - When it comes for the standard runtime and library, for the 
 most part, yes, but maybe keep around ` nogc` for the 
 occasional student that wants to get into real-time stuff like 
 audio development early on, as an option.


May I remind people that one of dlang's big sponsors is Weka, 
where ` nogc` is used extensively to achieve high performance 
where it matters, in combination with less performance-critical 
code that is allowed to use the GC.

D is used by serious companies, not just students.
https://www.reuters.com/technology/data-platform-firm-wekaio-notches-16-bln-valuation-after-lastest-funding-round-2024-05-15/

-Johan
Sep 06
prev sibling next sibling parent claptrap <clap trap.com> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.


For real time audio the actual audio processing will either be in 
an OS callback, or a host callback in the case of a plugin. In 
both cases the "audio thread" will be an external thread that D 
runtime does not know about. And the only actual code that needs 
to be  nogc, (and no malloc etc), is in that callback. Just the 
actual audio processing code, well maybe some others in a plugin 
situation, stuff like events, automation will typically be 
delivered in the real time thread.

So you don't need the whole app to be  nogc, just the real time 
parts, and they will typically be less that 10% of the codebase.

So the "lets just remove the GC completely", or "just use a 
custom runtime", might be a good solution in some cases, but its 
a sledgehammer to crack a nut solution for others.

And tbh I don't see what it fixes? The problem, or what people 
are complaining about is that trying to make everything  nogc 
compatible puts a burden on people who don't care about it.

You don't need a custom runtime to fix that problem. You just 
need to stop trying to make all the things  nogc compatible. If 
it adds no baggage / burden to GC users then sure fine, but just 
accept D is a GC language, some of its core language features 
rely on GC, some of the stdlib will use GC.

I don't see massive amounts of posts from people complaining that 
this or that in the stdlib isn't usable in  nogc code?

Maybe its not a problem that needs fixing, or maybe  ogc people 
expect to have to do some extra work themselves.
Sep 06
prev sibling next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.


I am fine with how things are, but here are some ideas.

I am OK with removing ` nogc` because it's annoying to use and a 
bit useless. It kind of forces you to take a side, even though 
nogc code can work with gc code.

BetterC is weird, but it does do something. If ` nogc` were to be 
removed, BetterC could act as a replacement for those who want to 
avoid using the gc and enforce that at compile time.
Sep 07
parent reply Lance Bachmeier <no spam.net> writes:
On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 BetterC is weird, but it does do something. If ` nogc` were to 
 be removed, BetterC could act as a replacement for those who 
 want to avoid using the gc and enforce that at compile time.


How do you replace this code with BetterC? Answer: You don't.

```
import std;
void main() {
     writeln(add(3, 4));
}
 nogc int add(int x, int y) { return x+y; }
```

The use cases of  nogc and BetterC are very different. With 
BetterC you lose classes, dynamic arrays, and associative arrays, 
among other things.
Sep 07
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 08/09/2024 1:06 AM, Lance Bachmeier wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:
 

 BetterC is weird, but it does do something. If ` nogc` were to be 
 removed, BetterC could act as a replacement for those who want to 
 avoid using the gc and enforce that at compile time.


 
 How do you replace this code with BetterC? Answer: You don't.
 
 ```
 import std;
 void main() {
      writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```
 
 The use cases of  nogc and BetterC are very different. With BetterC you 
 lose classes, dynamic arrays, and associative arrays, among other things.


Just because you lose access to almost all of druntime and phobos does 
not mean you cannot replace almost everything.

```d
module app;
import sidero.base.console;

 safe nothrow  nogc:

void main() {
     writeln(add(3, 4)); // 7
}

int add(int x, int y) {
     return x + y;
}

```

So far the only thing I haven't been able to find a solution for when 
needed is exceptions in terms of niceness.
Sep 07
parent reply Lance Bachmeier <no spam.net> writes:
On Saturday, 7 September 2024 at 13:28:39 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 08/09/2024 1:06 AM, Lance Bachmeier wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:
 

 BetterC is weird, but it does do something. If ` nogc` were 
 to be removed, BetterC could act as a replacement for those 
 who want to avoid using the gc and enforce that at compile 
 time.


 
 How do you replace this code with BetterC? Answer: You don't.
 
 ```
 import std;
 void main() {
      writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```
 
 The use cases of  nogc and BetterC are very different. With 
 BetterC you lose classes, dynamic arrays, and associative 
 arrays, among other things.


 Just because you lose access to almost all of druntime and 
 phobos does not mean you cannot replace almost everything.

 ```d
 module app;
 import sidero.base.console;

  safe nothrow  nogc:

 void main() {
     writeln(add(3, 4)); // 7
 }

 int add(int x, int y) {
     return x + y;
 }

 ```

 So far the only thing I haven't been able to find a solution 
 for when needed is exceptions in terms of niceness.


On run.dlang.io:

```
onlineapp.d(1): Error: unable to read module `console`
onlineapp.d(1):        Expected 'sidero/base/console.d' or 
'sidero/base/console/package.d' in one of the following import 
paths:
import path[0] = /dlang/dmd/linux/bin64/../../src/phobos
import path[1] = /dlang/dmd/linux/bin64/../../src/druntime/import
```

Searching on code.dlang.org: Found 0 packages. So not much of a 
replacement.
Sep 07
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 08/09/2024 2:39 AM, Lance Bachmeier wrote:

 On Saturday, 7 September 2024 at 13:28:39 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 On 08/09/2024 1:06 AM, Lance Bachmeier wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 BetterC is weird, but it does do something. If ` nogc` were to be 
 removed, BetterC could act as a replacement for those who want to 
 avoid using the gc and enforce that at compile time.


 How do you replace this code with BetterC? Answer: You don't.

 ```
 import std;
 void main() {
      writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```

 The use cases of  nogc and BetterC are very different. With BetterC 
 you lose classes, dynamic arrays, and associative arrays, among other 
 things.


 Just because you lose access to almost all of druntime and phobos does 
 not mean you cannot replace almost everything.

 ```d
 module app;
 import sidero.base.console;

  safe nothrow  nogc:

 void main() {
     writeln(add(3, 4)); // 7
 }

 int add(int x, int y) {
     return x + y;
 }

 ```

 So far the only thing I haven't been able to find a solution for when 
 needed is exceptions in terms of niceness.


 
 On run.dlang.io:
 
 ```
 onlineapp.d(1): Error: unable to read module `console`
 onlineapp.d(1):        Expected 'sidero/base/console.d' or 
 'sidero/base/console/package.d' in one of the following import paths:
 import path[0] = /dlang/dmd/linux/bin64/../../src/phobos
 import path[1] = /dlang/dmd/linux/bin64/../../src/druntime/import
 ```
 
 Searching on code.dlang.org: Found 0 packages. So not much of a 
 replacement.


Well yes, I have not published it for others to use so far.

But anyone could do this, its not that hard to wrap printf, which is 
still available to you if you use -betterC.

https://github.com/Project-Sidero/basic_memory/tree/main
Sep 07
prev sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier 
wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 BetterC is weird, but it does do something. If ` nogc` were to 
 be removed, BetterC could act as a replacement for those who 
 want to avoid using the gc and enforce that at compile time.


 How do you replace this code with BetterC? Answer: You don't.

 ```
 import std;
 void main() {
     writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```

 The use cases of  nogc and BetterC are very different. With 
 BetterC you lose classes, dynamic arrays, and associative 
 arrays, among other things.


You just don't use ` nogc`.
My point is that your code is already nogc. No need for an 
attribute.
Sep 07
next sibling parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

 On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier 
 wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 BetterC is weird, but it does do something. If ` nogc` were 
 to be removed, BetterC could act as a replacement for those 
 who want to avoid using the gc and enforce that at compile 
 time.


 How do you replace this code with BetterC? Answer: You don't.

 ```
 import std;
 void main() {
     writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```

 The use cases of  nogc and BetterC are very different. With 
 BetterC you lose classes, dynamic arrays, and associative 
 arrays, among other things.


 You just don't use ` nogc`.
 My point is that your code is already nogc. No need for an 
 attribute.


And if you are unsure if a function allocates with the gc, you 
can always test. In my experience, if you don't use the `~` 
operator, array literals or delegates, then you are fine.

Just an idea. As I said, I am fine with how things are now.
Sep 07
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:

 On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

 On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier 
 wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 BetterC is weird, but it does do something. If ` nogc` were 
 to be removed, BetterC could act as a replacement for those 
 who want to avoid using the gc and enforce that at compile 
 time.


 How do you replace this code with BetterC? Answer: You don't.

 ```
 import std;
 void main() {
     writeln(add(3, 4));
 }
  nogc int add(int x, int y) { return x+y; }
 ```

 The use cases of  nogc and BetterC are very different. With 
 BetterC you lose classes, dynamic arrays, and associative 
 arrays, among other things.


 You just don't use ` nogc`.
 My point is that your code is already nogc. No need for an 
 attribute.


 And if you are unsure if a function allocates with the gc, you 
 can always test. In my experience, if you don't use the `~` 
 operator, array literals or delegates, then you are fine.

 Just an idea. As I said, I am fine with how things are now.


 nogc is a viable option for optimizing hot paths, in some cases 
at least.

First you profile to find where your code is doing most of the 
work, then you start from the bottom by adding  nogc step by step 
on such performance hungry functions, it will also enforce 
changes to these functions from making spontaneous changes.
Sure there is also -vgc flag that will show you everything, but 
often only hot paths is all you need.

But like was already said people often tends to use it as a 
hammer to smash everything, and then they suddenly find out this 
does not scale or not even work, or solves the problem they never 
had.
Sep 07
prev sibling parent reply claptrap <clap trap.com> writes:
On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:

 On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

 On Saturday, 7 September 2024 at 13:06:45 UTC, Lance Bachmeier 
 wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev wrote:


 You just don't use ` nogc`.
 My point is that your code is already nogc. No need for an 
 attribute.


 And if you are unsure if a function allocates with the gc, you 
 can always test.


And test every function you call, and every function that 
function calls, and so on. And hope that nobody changes the 
implementation after you've checked it, etc..
Sep 08
parent monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 8 September 2024 at 09:14:21 UTC, claptrap wrote:

 On Sunday, 8 September 2024 at 00:18:53 UTC, Kapendev wrote:

 On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

 On Saturday, 7 September 2024 at 13:06:45 UTC, Lance 
 Bachmeier wrote:

 On Saturday, 7 September 2024 at 08:05:10 UTC, Kapendev 
 wrote:


 You just don't use ` nogc`.
 My point is that your code is already nogc. No need for an 
 attribute.


 And if you are unsure if a function allocates with the gc, you 
 can always test.


 And test every function you call, and every function that 
 function calls, and so on. And hope that nobody changes the 
 implementation after you've checked it, etc..


IFF d had a full time embedded and wasm std dev, and a backlog of 
bug reports shorter then 10 years long, it would be fine as they 
make whatever style guide changes and edge cases could be solved 
as they came up from real use.

Adding nogc to an existing old tech debt project is less 
realistic then doing an separate new std; and that new std could 
just be compiled with betterc
Sep 08
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Sunday, 8 September 2024 at 00:10:05 UTC, Kapendev wrote:

 You just don't use ` nogc`.
 My point is that your code is already nogc. No need for an 
 attribute.


Same can be said for every other attribute, let's get rid of all 
of them!

No of course not. We use attribute not because we can't write 
that code without them, but because we want the compiler to check 
if something doesn't unexpectedly find its way in.

With changing requirements and changing authors, it is easy for 
almost all of your assumptions and conventions to break. Having 
an attribute is so much better than having to write a comment 
and/or needing to be extra vigilant at code review time.
Sep 07
prev sibling next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:

 A lot of people are arguing (especially on Discord) that 
 ` nogc` should be discarded entirely in favor of betterC.

 [...]


Please, just a big no.

/P
Sep 07
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
Some introspection:

` nogc` has an unintended effect of forcing its users to do 
optimization in the form of using preallocated memory. Might be 
replicated by using IDE extensions, which could warn the user for 
`malloc()` and similar calls.
Sep 07
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
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.
Sep 09
parent monkyyy <crazymonkyyy gmail.com> writes:
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.
Sep 09
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 09