4 ms·

I've used C# quite a bit due to the Unity game engine. Moment to moment, it's pretty enjoyable to code in and easy to read. The cross-platform nature is usually

I've used C# quite a bit due to the Unity game engine. Moment to moment, it's pretty enjoyable to code in and easy to read. The cross-platform nature is usually really nice too (C# DLLs typically work on all platforms without issue). However, I do have a few complaints: We spend a lot of time fighting the garbage collector. This leads to awkward situations where certain variables that would ideally be function-local need to be made into member variables so we can reuse the memory each frame. This makes our code more complex and less local. The choice to make "class" vs "struct" dictate whether memory is allocated on the heap or stack is annoying. I think there are a lot of problems with this: overloading keywords borrowed from C/C++, not being sure where memory will be allocated unless you go check the type definition, not having the option to instantiate a single type in both memory areas. At first glance, you think C# doesn't have to deal with pointers. But in reality, just about everything IS a pointer, just with no syntax to indicate it. The fact that (almost) everything can be null makes code more complex. I also find some of the syntax introduced in newer C# versions hard to read - but I guess I also feel that way about C++! Ultimately, I still really enjoy/prefer C or C++. Despite their flaws, they give you a lot of options and a lot of control that I sometimes wish I had in C#.

briHass 3y ago
You see issues with stack allocated variables in a function? There should be negligible cost to that. The recent introduction of Span (or Memory for heap) has met most of my needs for fighting the GC and pseudo pointers without being 'unsafe'
zamalek 3y ago
> We spend a lot of time fighting the garbage collector. Have you considered object pools? Getting objects into an older generation will eliminate their impact on regular collections. https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.objectpool.objectpool-1 https://learn.microsoft.com/en-us/dotnet/api/microsoft.exten... You want to be intentional about how long objects hang about. In C# game dev it starts becoming an architectural concern. That being said, allocation problems aren't unique to managed languages. You'll definitely see at least one pool somewhere in a large-scale C++ game. It's always costly.
neonsunset 3y ago
GC and nullability issues are an unfortunate result of Unity using forked flavour of Mono runtime (that is significantly behind feature-wise and uses Boehm GC). When Unity 6 comes out, all of these will hopefully become a thing of the past. The larger .NET ecosystem does not have much issues with GC performance nor with nulls since most new code written is with enabled nullable reference types so you pretty much always know if a reference is nullable or not.

briHass 3y ago

You see issues with stack allocated variables in a function? There should be negligible cost to that. The recent introduction of Span (or Memory for heap) has met most of my needs for fighting the GC and pseudo pointers without being 'unsafe'

zamalek 3y ago

> We spend a lot of time fighting the garbage collector. Have you considered object pools? Getting objects into an older generation will eliminate their impact on regular collections. https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.objectpool.objectpool-1 https://learn.microsoft.com/en-us/dotnet/api/microsoft.exten... You want to be intentional about how long objects hang about. In C# game dev it starts becoming an architectural concern. That being said, allocation problems aren't unique to managed languages. You'll definitely see at least one pool somewhere in a large-scale C++ game. It's always costly.

neonsunset 3y ago

GC and nullability issues are an unfortunate result of Unity using forked flavour of Mono runtime (that is significantly behind feature-wise and uses Boehm GC). When Unity 6 comes out, all of these will hopefully become a thing of the past. The larger .NET ecosystem does not have much issues with GC performance nor with nulls since most new code written is with enabled nullable reference types so you pretty much always know if a reference is nullable or not.