Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# in Unity 2026: Writing more modern code

darkounity.com

Post reply on HN
Print view View original

41–50 of 105 posts

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

#41

Post by drzaiusx11 »

pjmlp wrote: post #31
coinfused wrote: post #25

Looking forward to when Unity will migrate to CoreCLR. Soon! https://www.youtube.com/watch?v=_t6xVfrmEWU

That soon is like a decade in the making. And with many folks going into alternatives like Godot, it means C# ends up losing the mindshare it got. Yes, you can use C# with Godot, but most folks end up with GDScript, or GDextension.

Iirc Godot is taking the approach from both sides however and also working on a libgodot which will allow a "bring your own runtime" which I'm much more interested in than the integrated "environments" that are Unity and Godot today. I'm likely in the minority though as they only started making a library export after the all in one environment was stable enough...

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

#42

Post by tranceylc »

grebc wrote: post #35
captainbland wrote: post #14

Earlier quoted context omitted.

I think as a solo developer there's actually a good argument for increasing code density and coupling (things which in large multi developer projects are seen as spaghetti), as it can help you keep a lot of that code in mental and visual context at one time. It loses flexibility and readability for others, but you don't usually have enough time to concern yourself with such flexibility if you're working on a project…

This is pretty anti-thetical to most good practices but the older and more experienced I get the more(13 years as a C# dev) I think copy & pasting sections of code is wayyyyyy more appropriate than extracting into a method/class/library or other forms of abstraction. Everything starts out with good intentions when someone comes along and says “hey you could make that an abstraction” and I just clench my jaw because I…

I agree with everything except for it being anti-thetical to good practice. I have noticed a lot of experienced devs agree with that sentiment.

It has been a pretty common trend for the last few years of people breaking out of the “OOP style programming” and practices they were taught at university. I am not saying avoiding things like over abstraction is new, but I do think there is a newer generation of programmers who have been taught and warned about drawbacks from practices like that.

Similarly, my anecdotal experience tells me more newer game devs are aware of basic memory practices being better than overly complex OOP code. Think flat arrays and simple cache alignment over something abstract and over engineered

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

#43

Post by wheybags »

weli wrote: post #2

A lot of game devs are terrible programmers. A friend of mine 10 years ago asked me for help with his Unity project. He is not a tech savvy person but we both took programming in high school, enough for him to make small games with a lot of tutorials and stack overflow. His codebase was horrible, a lot of logic that I would have already though of abstracting away. For example saving dialogs on json files and the cond…

Something I've noticed about software dev vs game design: software is better (easier to read, understand, maintain, etc) when you have clean, separated modules. Game design is better (more fun) when everything is connected (eg in an fps, everything relates to gunplay, damage systems, environmental destruction, in a building game, everything relates to building, the building ui, inventory, resources etc). I think this mismatch shows up in game code.

Combine that with actual hard performance constraints, and if you're a "normal" software dev casually browsing some game code, it can be shocking (eg Celeste movement code: https://github.com/NoelFB/Celeste/blob/master/Source/Player/...).

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

#44

Post by drzaiusx11 »

I am not a game developer (I've made a few in the past but didn't use any frameworks besides direct libsdl calls), but if this article rings true for anyone in that field I'm a bit surprised things as basic as properties, structs and tuples are "not used" by unity devs, this is some basic stuff that has been supported even by Mono for decades. Just basic syntactic sugar though, so not a big deal either way. Just surprising to me at least.

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

#45

Post by pjmlp »

moron4hire wrote: post #22
tryfinally wrote: post #11

Earlier quoted context omitted.

C# 9, but with some hacks you can bump it up to C# 10 - actually works and surprisingly stable. Can't wait for them to finally migrate to CoreCLR, though.

I got out of doing Unity development 7 years ago because I was tired of waiting for them to migrate to CoreCLR (among many other reasons).

Unfortunately the way they managed to stick with MonoRuntime and Burst, kind of made more harm than good, regarding C# adoption on the games industry.

Many issues people associate with C#, are actually only relevant in Unity, because of this.

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

#46

Post by tancop »

c# 14 added field backed properties where you dont need that `_health` in the first place you just write `public int Health { get => field; set => field = Mathf.Clamp(value, 0, 100)`. that way you never accidentally use the internal field without the checks. problem is unity still stuck on c# 9.0 so it might be years before you can actually use this in a game

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

#47

Post by simonask »

shevy-java wrote: post #19

> The Unity engine has evolved a lot in modern days, but I noticed a trend where Unity developers are still using "outdated" techniques when writing their C# code. Some years ago I tried to get into C# + Mono. Eventually I opted for Java instead, for many reasons; I'll skip that here. C# is very strange to me. In a way I feel that C# belongs like Java in the same "post C++" family; C kind of paved the way, C++ was me…

C# has a unique powerful position in the video game space. In almost every other niche, there are better (or just trendier) solutions, but C# is the only major language that actually gives you a combination of features that are important in video games:

- Dynamic runtime with loose coupling and hot reload of code - extremely useful during development.

- Value types. You don't want every Vector4 to be heap allocated when you're doing 3D graphics, because that's going to be absolutely unusable.

- Access to a relatively low-level substrate for basically-native performance when needed - extremely useful when you're trying to actually ship something that runs well.

Taken in isolation, C# isn't best in class for any of them, but no other language offers all three, especially not if you also want things like a really good debugger and great IDE tools.

To my knowledge, Java has none of these features (yet), and they aren't really important in a lot of the areas where Java is popular. But this is why C# in particular is very strong in the video games niche.

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

#48

Post by 999900000999 »

orthoxerox wrote: post #37
999900000999 wrote: post #7

Earlier quoted context omitted.

If you’re a solo developer, if it works. I’ve seen worse in enterprise shops and then I’ve gotten into nasty arguments with people who don’t care about programming. They can’t be wrong. C# is a high level language that can handle a degree of sloppy programming. I was working on a small tool yesterday. It was easier to vibe code it from scratch in C# than to modify an existing Rust project. The only weird part is VS C…

I would say that C# is "less colored" than Rust. Handling a moved argument, a borrowed argument, a copied argument is different in Rust, you have to think upfront about memory lifetimes. If you are wrong the first time, changing the ownership is not a simple localized refactoring.

To be 100% fair, it’s much easier for llms to start new projects and Rust is simply a more difficult language.

I have what I need working in C#, and as a C# developer I actually understand what’s going on.

The only downside is now instead of having a portable Rust project, I have something which heavily leans into Windows APIs.

I assume with high level languages some smart people figured out all the memory stuff.

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

#49

Post by orphea »

raincole wrote: post #17
orphea wrote: post #12

Earlier quoted context omitted.

Many tools can be misused. Object.Member can throw a NRE, is it a big mistake to have the dot operator?

It's such a weird question. Yes, "dot operator can throw a NRE" is of course a big mistake. A billion-dollar mistake, you can even say.

No, I'm not asking if "dot operator can throw a NRE" is a mistake; I'm asking if the dot operator, the ability to access members at all, is a mistake.

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

#50

Post by badsectoracula »

weli wrote: post #2

A lot of game devs are terrible programmers. A friend of mine 10 years ago asked me for help with his Unity project. He is not a tech savvy person but we both took programming in high school, enough for him to make small games with a lot of tutorials and stack overflow. His codebase was horrible, a lot of logic that I would have already though of abstracting away. For example saving dialogs on json files and the cond…

FWIW sometimes when making games it helps to have everything in one place, even though later you may want to split things up for later projects :-P so sometimes you get big balls of mud with lots of checks everywhere for the actions you want.

As an example, most of the gameplay logic for Post Apocalyptic Petra[0] (a 3D platformer/adventure/riddle solving game i made for an MSDOS game jam a few years ago) is in the entity class for the player character[1] - including things like collisions, etc :-P. It is a bit hacky, but it works.

Though if i ever made that sequel i wanted to where i want to have an extra character following you around, i'd need to move a bunch of things to other more generic places so that they can be shared by both the player character and the AI.

[0] https://bad-sector.itch.io/post-apocalyptic-petra

[1] https://codeberg.org/badsector/PetraEngine/src/tag/pap-0.99o...

Post reply on HN