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