4 ms·

You're replying to me as if the comment was in a vacuum It's responding to: > complexity just for the sake of it, > lots of pain for minimal gain > If you n

You're replying to me as if the comment was in a vacuum It's responding to: > complexity just for the sake of it, > lots of pain for minimal gain > If you need async/await you'll do better in modern .NET despite the GC > if you need the highest CPU performance you'll do better in C++ despite the unsafety To this I respond, GC is such a massive problem (I guess you can fill in "for some categories of problems" but I think it's obvious) that some people need to avoid it. And those people often turn to C++, where the "unsafety" is a very big problem.

anonymoushn 2y ago
I don't think so? My reply is that if you can't afford to stall for a really long time, like dozens of frames at 60hz at least, then your choices are often to deal with unsafety in C++, to deal with the GC in .NET, or to write everything from scratch in Rust (including many things for which you would typically use libraries) because idiomatic Rust and the associated ecosystem won't solve your tail latency issues. The last option is not obviously more attractive than the approach of working really hard to not make garbage that Unity devs are usually forced into after years of development when they start testing on Switch.
- neonsunset 2y ago
  You can deal with that in .NET the "C++" way too, given that you can write abstractions with structs and generics instead of objects, use malloc and stackalloc, and more. You are not married to GC heap, despite some suggesting otherwise. Generally speaking 60hz is not a problem but it starts to matter more with the popularity of high refresh rates. There are much more extreme cases like 1000hz game loop in OSU!, which pretty much has to use the same techniques as realtime systems that utilize GC-based language: https://github.com/dotnet/runtime/issues/96213#issuecomment-2155746773 https://github.com/dotnet/runtime/issues/96213#issuecomment-...

anonymoushn 2y ago

I don't think so? My reply is that if you can't afford to stall for a really long time, like dozens of frames at 60hz at least, then your choices are often to deal with unsafety in C++, to deal with the GC in .NET, or to write everything from scratch in Rust (including many things for which you would typically use libraries) because idiomatic Rust and the associated ecosystem won't solve your tail latency issues. The last option is not obviously more attractive than the approach of working really hard to not make garbage that Unity devs are usually forced into after years of development when they start testing on Switch.

neonsunset 2y ago
You can deal with that in .NET the "C++" way too, given that you can write abstractions with structs and generics instead of objects, use malloc and stackalloc, and more. You are not married to GC heap, despite some suggesting otherwise. Generally speaking 60hz is not a problem but it starts to matter more with the popularity of high refresh rates. There are much more extreme cases like 1000hz game loop in OSU!, which pretty much has to use the same techniques as realtime systems that utilize GC-based language: https://github.com/dotnet/runtime/issues/96213#issuecomment-2155746773 https://github.com/dotnet/runtime/issues/96213#issuecomment-...