[elmigranto]

Use managed language, it will handle memory stuff for you, you don’t have to care.

But also read these 400 articles to understand our GC. If you are lucky, we will let you change 3 settings.

[bob1029]

You can provide your own GC implementation if you really wanted to:

https://learn.microsoft.com/en-us/dotnet/core/runtime-config...

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/g...

[JaggerJo]

Interesting!

[phito]

It works just fine out of the box. The articles/manuals are just if you want to really understand how it works and get the most out of it. What's the issue with that?

[CharlieDigital]

In my 20+ years using C#, there's only been one instance where I needed to explicitly control some behavior of the GC (it would prematurely collect the managed handle on a ZMQ client) and that only required one line of code to pin the handle.

It pretty much never gets in your way for probably 98% of developers.

[pjmlp]

Dr. Dobbs and The C/C++ Users Journal archives are full of articles and ads for special memory allocators, because the ones on the standard library for C or C++ also don't work in many cases, they are only good enough as general purpose allocation.

[samus]

You need these settings when you drive your application hard into circumstances where manual memory allocation arguably starts making sense again. Like humongous heaps, lots of big, unwieldy objects, or tight latency (or tail latency) requirements. But unless you're using things like Rust or Swift, the price of memory management is the need to investigate segmentation faults. I'd prefer to spend developer time on feature development and benchmarking instead.