3 ms·

While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very car

While I agree they can sometimes compete in numerically heavy tasks, the place where they fall behind is memory management. Systems like databases need very careful memory management and GC is not always your friend there. I'm still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language, although I'm not sure it is at all possible.

Const-me 7y ago
> the place where they fall behind is memory management It's sometimes possible to design C# code in a way that doesn't stress GC too much, so the majority of bandwidth bypasses the GC. For instance, here's my old .NET project which plays streaming media for hours without interrupts, with a hard limit of 15MB RAM for the whole process: https://github.com/Const-me/SkyFM https://github.com/Const-me/SkyFM Doing so became easier in modern .NET, with these value tuples and spans. > still hoping some day we'll be allowed both GC and Rust-like manual memory management in a single language Microsoft tried, managed C++, then C++/CLI. The CLI is still supported if you want to try, but IMO they both were way too complex: 2 types of pointers, two runtimes with weird interaction between them, worst of both sides on safely and ease of use. AFAIK most people only used these languages for a thin layer of glue to integrate native C++ with C#. And even for that limited use case, COM interop or C interop often worked better. Even MS switched to COM interop in the next iteration, C++/CX.
Too 7y ago
Rc/shared_ptr comes pretty close to GC from usability point of view?