In beeflang garbage collector (garbage seeker) do not clean the memory, it only works in debug mode to help the programmer find and fix memory leaks, double frees, etc. In release mode, the program runs in full speed since there is no garbage collector. I think this is the best approach about memory management.

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:

This idea is based upon a mistaken ideology instead of what is actually going on with manual memory management and modern garbage collectors. Explained here:
Garbage Collection for Systems Programmers

On Tuesday, 20 February 2024 at 17:24:40 UTC, Carl Sturtivant wrote:

Good programmers should have the most control of whats going on in their software. Garbage collection isn’t a silver bullet, as you said, so it should NOT be the mandatory/default memory management.

Garbage seeker helps you to create a great software, improve your skills, without force you to accept one solution of memory management.

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:

Dlang as a dynamic array as a primitive [] its day 1 is provided by gc and turning off the gc breaks it.

Dlang doesn't have a robust ecosystem of easy to use data structures so the few we have are invaluable.

qed, ditching gc would require a massive change and it would break the vast majority of code(again primitive data type, ask python how changing strings went) /thread

On Tuesday, 20 February 2024 at 18:15:45 UTC, Marconi wrote:

"mandatory/default" is muddling two very different things.

1. Mandatory GC.
   Agreed that it should NOT be mandatory.

2. Default GC.
   Makes perfect sense as per the article.

Direct control? No. Only when it is necessary for the real-time behavior of the software. This is why we have operating system kernels and high level languages with run-time systems. So programmers can automatically delegate much in many different ways and have things done for them, obviating the need for low level repetitive make-work, administration of details, error prone stuff.

Using the word "control" here misses the point. Taking this literally would mean not using an OS Kernel because as discussed in the article it removes control and does not provide guarantees! Then you'd just write code for hardware in a language in which everything you write corresponds to a known action of the hardware with a concrete time bound. Forth achieves this. Sometimes it's a useful thing to do because it can guarantee "hard real-time" when that is needed.

Mostly what is needed is "soft real-time". A modern GC gives the fastest storage allocation as indicated in the article, and for soft real-time is a good default solution. Manual allocation is more expensive as indicated in the article. Worse, it actually has less control that presumed by ideology. Quoting it:

So using the OS kernel to provide manual memory management is fraught with lack of control! But gives the illusion of control to you. Did you read the section "the illusion of control" and "lies people believe about memory management"? Back to the article:

On Tuesday, 20 February 2024 at 18:15:45 UTC, Marconi wrote:

You're viewing this entirely from the perspective of the types of programs you write. Someone writing programs in Javascript or Ruby is likely to not think about these things, nor have any reason to do so. They're becoming less important for the majority of programmers every year. I have a work machine with 128 GB of RAM. The GC doesn't usually even run. Why should I waste any time on memory management when it's never an issue?

D is very much a language for the things you do with a scripting language. That may actually be its best selling point, since you're free to let your program can grow to tens of thousands of lines and you never have to worry about performance.

Having to think about memory management in any way forces a solution on everyone. There are obviously cases in which the programmer does need to think about memory management, but that's not an argument to distract everyone else from the core problem they're trying to solve.

Complete avoidance of the GC is a disco-era idea that is no more relevant in 2024 than punch cards.

On Wednesday, 21 February 2024 at 16:28:46 UTC, bachmeier wrote:

+1

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:

Sounds peculiar. As far as I understand it's a way to verify if manual management is mastered. However, for a language that proposes manual management and on linux I'd just use valgrind. It's a useful tool when debug infos are also generated.

On Friday, 23 February 2024 at 11:37:22 UTC, Basile B. wrote:

I think it sounds like a clever solution, wish them the best of luck. valgrind has enormous overhead, much more than normal GCs. (Even ASAN has fairly large overhead.)

On Friday, 23 February 2024 at 14:04:03 UTC, Daniel N wrote:

Sure, never wish someone to fail.

What I miserably failed to explain is that IMO this is not a GC, it's a tool.
Not bad, and actually useful, but dont call that a GC.