On 9/21/2016 at 3:57 AM, BBeck said:

What changed is that we entered the 21st Century and computers are orders of magnitude faster. So, quite frankly, you can waste clock cycles now.

This is a very dangerous mindset, take it from me. When everyone on your team thinks that there are plenty of cycles to spend everyone will forget to profile and realize that they don't have the cycles they assumed they did. It leads to a lot of negligence and slack when it comes to profiling your code.

This kind of thinking can lead to a butterfly effect of inefficient code that eventually stacks up to be a huge performance hog of a system so rigidly locked in by its coding paradigm (OOP) that it becomes extremely expensive and time consuming to untangle and fix.

Don't get me wrong, C# has wonderful quality of life features and some of those are very powerful for certain use cases. I mean, use the best tool for the job. But at the end of the day with C# you lose control over where your performance budget is spent and are locked into its strict OOP paradigm which can make things harder to optimize or refactor. You don't want memory to move at random during gameplay, it can cause random stalls and performance instability. I wouldn't advise it for performance critical code like a game engine where you'll want to keep an eye on your (most likely tight) system resource budgets.

There's a reason C++ is still used as the core for game engines even today. C# is a good compliment to it and adds flexibility and ease where those are more valuable than raw cycles, but it's not a good fit for tasks that require tight system resource control.

Edit: just realized this thread popped back up because of an edit. Hope my post wasn't too late/revived a dead thread.