C# in Unity 2026: Writing more modern code • Hacker News Board

Re: C# in Unity 2026: Writing more modern code

#101

Post by pjmlp » Fri, Apr 10, 2026, 10:57 AM UTC

WorldMaker wrote: post #69

ablob wrote: post #32

Earlier quoted context omitted.

C# has had the reputation of not being viable for Linux for a long time. Therefore, the people already on Linux didn't have a reason to use it or even try it. If you're already doing stuff in other languages it's hardly worth it to switch to C#. I personally use it quite a lot - but I came as a windows user writing all my utilities in C#. Also, afaik C# is mostly used in corporate environments that don't open-source…

A lot of C#'s reputation for not being viable for Linux came from the other direction and a lot of FUD against Mono. There were a lot of great Linux apps that were Linux first and/or Linux only (often using Gtk# as UI framework of choice) like Banshee and Tomboy that also had brief bundling as out-of-the-box Gnome apps in a couple of Linux distros before anti-Mono backlash got them removed. Also, yeah today Linux sup…

Yes, however as acknowledged by the .NET team themselves, in several podcast interviews, this is mostly Microsoft shops adopting Linux and saving Windows licenses.

They still have a big problem gaining .NET adoption among those that were educated in UNIX/Linux/macOS first.

Mandy Mantiquila and David Fowler have had such remarks, I can provide the sources if you feel so inclined.

Re: C# in Unity 2026: Writing more modern code

#102

Post by rustyhancock » Fri, Apr 10, 2026, 3:47 PM UTC

PacificSpecific wrote: post #93

AppleBananaPie wrote: post #72

Earlier quoted context omitted.

Never worked with it myself but I've always heard the people who do describe it as Unreal c++ because to them it's completely different than regular c++ and this must be one of the reasons why

That's pretty much correct. I kind of have to switch to "unreal c++" context whenever I'm working in it. They have their own standard library etc

Don't forget if you make the editor access a nullptr it'll probably crash and take out any unsaved changes to blueprints!

Re: C# in Unity 2026: Writing more modern code

#103

Post by ivm » Fri, Apr 10, 2026, 9:30 PM UTC

MattCruikshank wrote: post #77

Fred27 wrote: post #52

As a primarily C# developer who has done some game engine work, I recently gave Godot a go for licensing reasons. Apart from some quirkiness I'm fairly impressed. Much nicer C# support compared to Unity. I've done a fair bit of Unreal C++ but to be honest unless you really need the performance that's just too much hard work. Having said that getting the code working properly with a nice 3D UI is my priority, not havi…

I don't want to design anything in any UI. I want to use a game engine as a library. I'm curious, as a primarily C# developer, how do you feel about Godot, in this respect?

Probably MonoGame is the best option for your case then

Re: C# in Unity 2026: Writing more modern code

#104

Post by enbugger » Tue, Apr 14, 2026, 12:56 PM UTC

pjmlp wrote: post #87

enbugger wrote: post #81

Earlier quoted context omitted.

Godot is nowhere near to something like C# HPC, Jobs and Burst. And I’m afraid even GDExtension can’t help with that. At least not with Godot’s scene structure which prioritises simplicity over performance.

I agree, however most indies don't need them, and most pros are getting into Unreal instead. Also something like Burst is a workaround for using Mono with C#, which gets solved in Godot with C++. How's the whole DOTS adoption going?

>gets solved in Godot with C++

if only by rewriting half of the Godot codebase. With design choices they made, Godot will never be performant enough for RTS/Crown simulation games.

https://github.com/godotengine/godot/issues/101494

>How's the whole DOTS adoption going?

I'm quite impressed to what people build on top of it: https://github.com/Dreaming381/Latios-Framework https://assetstore.unity.com/packages/tools/animation/mesh-a... and many more

Re: C# in Unity 2026: Writing more modern code

#105

Post by everyone » Tue, Apr 14, 2026, 7:46 PM UTC

jayd16 wrote: post #70

everyone wrote: post #23

I'm a very experienced Unity C# programmer, and I certainly don't equate "good" with using all the new fancy features of a language. Fancy features are less maintainable imo. Less programmers will know about them and they're less likely to have equivalents in other languages. Making something more exotic / confusing / hard to parse is defo not worth saving a few lines of code.. I'd much rather see a longer function u…

I don't know... I feel like a lot of these features do increase developer intent without breaking muscle memory. Properties are got and set like fields. Record types feel like classes with restrictions so the linter can warn you about broken assumptions. etc etc. Others increase readability. A LINQ statement is a lot easier to parse than a long block inside a foreach. New doesn't mean good but a lot of these are new…

I disagree about LINQ. You can easily do the same job in a little function with only stuff people learn in week 1 of programming, just for and if else and arrays. It's very clear precisely what's happening in this case, and its easy to alter. (Everyone is gonna know that stuff, not everyone is gonna be using LINQ regularly enough to understand it completely)

LINQ on the other hand is like another language entirely, awkwardly squished into your C#, reminds me of SQL code inside a big string inside another language's code. It's also not clear what it's actually doing which can be death for performance in games as LINQ usually allocates shittonnes of new stuff. (I'm certainly not advocating for premature optimisation, but I defo am advocating for knowing precisely what you are writing) The benefit of LINQ is that its a bit faster to write compared to a little function, but length-of-time-it-takes-to-actually-write-code is very rarely an important constraint in my experience.