• Marconi (5/5) Feb 20 In beeflang garbage collector (garbage seeker) do not clean the
• Carl Sturtivant (6/11) Feb 20 This idea is based upon a mistaken ideology instead of what is
• Marconi (9/21) Feb 20 Good programmers should have the most control of whats going on
• Carl Sturtivant (32/68) Feb 20 "mandatory/default" is muddling two very different things.
• bachmeier (19/24) Feb 21 You're viewing this entirely from the perspective of the types of
• Carl Sturtivant (2/27) Feb 21 +1
• Timon Gehr (16/19) Feb 29 So-called "good programmers" have been responsible for awful
• Dukc (8/18) Feb 29 I'd say you're both right. Good programmers should have the
• H. S. Teoh (68/80) Mar 02 The past 3 decades or so of industry experience has proven beyond a
• monkyyy (8/13) Feb 20 Dlang as a dynamic array as a primitive `[]` its day 1 is
• Basile B. (5/10) Feb 23 Sounds peculiar. As far as I understand it's a way to verify if
• Daniel N (4/15) Feb 23 I think it sounds like a clever solution, wish them the best of
• Basile B. (5/21) Feb 23 Sure, never wish someone to fail.

Marconi <soldate gmail.com> writes:

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.

Carl Sturtivant <sturtivant gmail.com> writes:

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

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](https://bitbashing.io/gc-for-systems-programmers.html)

Marconi <soldate gmail.com> writes:

On Tuesday, 20 February 2024 at 17:24:40 UTC, Carl Sturtivant 
wrote:
 On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

 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](https://bitbashing.io/gc-for-systems-programmers.html)

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.

Carl Sturtivant <sturtivant gmail.com> writes:

On Tuesday, 20 February 2024 at 18:15:45 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](https://bitbashing.io/gc-for-systems-programmers.html)

 Garbage collection isn’t a silver bullet, as you said, so it 
 should NOT be the mandatory/default memory management.

"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.

 Good programmers should have the most control of whats going on 
 in their software.

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:

 **`free()` is not free.** A general-purpose memory allocator 
 has to maintain lots of internal, global state. What pages have 
 we gotten from the kernel? How did we split those up into 
 buckets for differently-sized allocations? Which of those 
 buckets are in use? This gives you frequent contention between 
 threads as they try to lock the allocator’s state, or you do as 
 jemalloc does and keep thread-local pools that have to be 
 synchronized with even more code.

Tools to automate the “actually freeing the memory” part, like 
lifetimes in Rust and RAII in C++, don’t solve these problems. 
They absolutely aid correctness, something else you should care 
deeply about, but they do nothing to simplify all this 
machinery. Many scenarios also require you to fall back to 
shared_ptr/Arc, and these in turn demand even more metadata 
(reference counts) that bounces between cores and caches. And 
they leak cycles in your liveness graph to boot.

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:

Modern garbage collection offers optimizations that alternatives 
can not. A moving, generational GC periodically recompacts the 
heap. This provides insane throughput, since allocation is 
little more than a pointer bump! It also gives sequential 
allocations great locality, helping cache performance.

[...]
Many developers opposed to garbage collection are building 
“soft” real-time systems. They want to go as fast as 
possible—more FPS in my video game! Better compression in my 
streaming codec! But they don’t have hard latency requirements. 
Nothing will break and nobody will die if the system 
occasionally takes an extra millisecond.

bachmeier <no spam.net> writes:

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

 Good programmers should have the most control of whats going on 
 in their software.

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.

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

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.

Carl Sturtivant <sturtivant gmail.com> writes:

On Wednesday, 21 February 2024 at 16:28:46 UTC, bachmeier wrote:
 On Tuesday, 20 February 2024 at 18:15:45 UTC, Marconi wrote:

 Good programmers should have the most control of whats going 
 on in their software.

 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.

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

 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.

+1

Timon Gehr <timon.gehr gmx.ch> writes:

On 2/20/24 19:15, Marconi wrote:
 
 Good programmers should have the most control of whats going on in their 
 software.

So-called "good programmers" have been responsible for awful 
vulnerabilities that ruined people's safety and privacy for decades. 
It's pure hubris to think a non-trivial manually-memory managed program 
has any hope to get manual memory management correct as long as only 
"good programmers" are contributing to it. The fact that you are even 
advocating for this dynamic testing approach rips a big hole into this 
narrative of "good programmers".

Dynamic testing is not reliable because you simply do not enter the 
advanced adversarial inputs that are often necessary to expose and 
exploit the vulnerabilities.

Of course, once you have bought into the need for manual memory 
management (real or imagined), dynamic testing is better than nothing. 
However, telling people that they are not good programmers unless they 
use dangerous language features is simply irresponsible. The opposite is 
often the case.

Dukc <ajieskola gmail.com> writes:

On Thursday, 29 February 2024 at 14:28:56 UTC, Timon Gehr wrote:
 On 2/20/24 19:15, Marconi wrote:
 
 Good programmers should have the most control of whats going 
 on in their software.

 So-called "good programmers" have been responsible for awful 
 vulnerabilities that ruined people's safety and privacy for 
 decades. It's pure hubris to think a non-trivial 
 manually-memory managed program has any hope to get manual 
 memory management correct as long as only "good programmers" 
 are contributing to it.

I'd say you're both right. Good programmers should have the 
low-level control past the type system when needed... but not 
because they would be so good they can avoid mistakes there - 
they can't! They should have that tool, because they _understand 
they will do damage if they have to wield it_ - and therefore, do 
so only when there really is good reason to.

Or at least, that's how it should be.

"H. S. Teoh" <hsteoh qfbox.info> writes:

On Thu, Feb 29, 2024 at 03:28:56PM +0100, Timon Gehr via Digitalmars-d wrote:
 On 2/20/24 19:15, Marconi wrote:
 
 Good programmers should have the most control of whats going on in
 their software.

 
 So-called "good programmers" have been responsible for awful
 vulnerabilities that ruined people's safety and privacy for decades.
 It's pure hubris to think a non-trivial manually-memory managed
 program has any hope to get manual memory management correct as long
 as only "good programmers" are contributing to it. The fact that you
 are even advocating for this dynamic testing approach rips a big hole
 into this narrative of "good programmers".

The past 3 decades or so of industry experience has proven beyond a
doubt that humans are notoriously bad at manual memory management. Just
read the latest CVEs and note how big a percentage of serious security
vulnerabilities are the result of bugs in manual memory management.
Despite decades of industry experience, this percentage has not dwindled
significantly in codebases that use manual memory management.

In my day job I work with expert C/C++ programmers with decades of
experience under their belts, some of whom exceed my skill level.  We
all know the theory behind how to manage memory correctly.  Guess what?
The very same experts continue making slip-ups and mistakes that cause
memory leaks, pointer bugs, use-after-free, etc.. In spite of decades of
having to fix such bugs and think about how to avoid them.  Clearly,
something isn't adding up.  If decades of field expertise has not
reduced the incidence rate of memory-related bugs, one begins asking
whether the problem isn't so much with "good programmers" as it is with
the fact that *humans are bad at manual memory management*. Conceptually
it's very simple -- allocate once, use n times, free once.  In practice
it's a huge tangled web of complexity that even C experts with decades
of experience have trouble fully mastering.  (Needless to say already
what happens when the fragile codebase falls into the hands of less
experienced coders: expect nothing less than a total sh*tshow.)

And tellingly enough, after about a decade or so in our current project,
the lead programmers have moved away from using malloc/free directly and
have implemented some kind of RC-based system. The fact that this
decision was made tells you that even these experts with decades of
experience realize that manually managing memory is an exercise in
futility; something more automatic is necessary to prevent frequently
repeated slip-ups.  Unfortunately, C being what it is, people still slip
up anyway, like forgetting to call the function that decrements the RC
count once they're done with the pointer, etc..  So the lead programmers
moved toward region allocators -- let the junior programmers make as big
a mess as they want, at the end of the task just free the entire region,
no memory leaks. Problem solved, right?  Nope. Dangling references, use
after free, etc., still abound.

Being C experts, said lead programmers are very down on the idea of GC
(as is usual with people with that background -- including myself at one
time).  But observing all of the above, I really can't help asking, is
GC really *that* bad?  If we'd used a GC language from the beginning,
how many hundreds, maybe even thousands, of man hours would have been
saved from not having to chase down hard-to-catch pointer bugs, memory
leaks, and other such lovely side-effects of mixing humans with manual
memory management.  How much less crashes customers would have seen, and
how much more time and energy we could have spent on implementing
features instead of hunting down pointer bugs.

Of course, if job security is your goal, then by all means, go ahead and
promote more manual memory management.  Me, I wanna make progress in the
problem domain and actually write useful code, not play babysitter with
manually-managed allocations and cleaning up all the leaks afterwards.
I've done my fair share of spending tens even hundreds of hours chasing
down hard-to-find, non-reproducible heisenbugs caused by dangling
pointers, including tracing down the disassembly of the code and
narrowing down the exact conditions to reproduce a rare race condition
(took me a month to find it), all to pinpoint exactly where things went
wrong.  I'm sick and tired of doing this same old thing over and over
again.  Life is too short for manual memory management.  Pass me the GC,
please.

"Good programmers" that always do the Right Thing(tm) don't exist. Even
if they did, 99% of code out there isn't written by them.  That means
99% of code with manual memory management is full of bugs and lurking
security holes waiting to be exploited.  The list of CVEs over the years
prove this beyond any reasonable doubt.  It isn't 1995 anymore; we
programmers, as a profession, ought to do better than still grasping
onto manual memory management when much better options are now
available.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I must
unfortunately bring it to your attention that I am, in fact, NOT verbose.

monkyyy <crazymonkyyy gmail.com> writes:

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

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

Basile B. <b2.temp gmx.com> writes:

On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

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.

Daniel N <no public.email> writes:

On Friday, 23 February 2024 at 11:37:22 UTC, Basile B. wrote:
 On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

 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.

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

Basile B. <b2.temp gmx.com> writes:

On Friday, 23 February 2024 at 14:04:03 UTC, Daniel N wrote:
 On Friday, 23 February 2024 at 11:37:22 UTC, Basile B. wrote:
 On Tuesday, 20 February 2024 at 16:40:28 UTC, Marconi wrote:
 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.

 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.

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

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.