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

61–70 of 105 posts

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

#61

Post by tryfinally »

drzaiusx11 wrote: post #28
tryfinally wrote: post #3

Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc. [0]: https://github.com/Cysharp/ZLinq

Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)

The modern .NET runtime can get devirtualize interface calls and eliminate temporary object allocations in some scenarios. It's a bit of a black box - who knows when it actually works? - but still, it's a nice boost here and there.

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

#62

Post by kbolino »

simonask wrote: post #47
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 w…

I think these are all valid arguments, but I do want to point out that Java is addressing them.

The first bullet is possible with the JetBrainsRuntime, a fork of OpenJDK: https://github.com/JetBrains/JetBrainsRuntime

The second bullet is a headline goal of Project Valhalla, however it is unlikely to be delivered in quite the way that a C# (or Go or Rust etc.) developer might expect. The ideal version would allow any object with purely value semantics [1] to be eligible for heap flattening [2] and/or scalarization [3], but in experimental builds that are currently available, the objects must be from a class marked with the "value" qualifier; importantly, this is considered an optimization and not a guarantee. More details: https://openjdk.org/projects/valhalla/value-objects

The third bullet (IIUC) is addressed with the Foreign Function & Memory API, though I'll admit what I've played around with so far is not nearly as slick as P/Invoke. See e.g. https://openjdk.org/jeps/454

[1] value semantics means: the object is never on either side of an == or != comparison; the equals and hashCode methods are never called, or are overridden and their implementation doesn't rely on object identity; no methods are marked synchronized and the object is never the target of a synchronized block; the wait, notify, and notifyAll methods are never called; the finalize method is not overridden and no cleaner is registered for the object; no phantom or weak references are taken of the object; and probably some other things I can't think of

[2] heap flattening means that an object's representation when stored in another object's field or in an array is reduced to just the object's own fields, removing the overhead from storing references to its class and monitor lock

[3] scalarization means that an object's fields would be stored directly on the stack and passed directly through registers

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

#63

Post by WorldMaker »

drzaiusx11 wrote: post #28
tryfinally wrote: post #3

Fans of LINQ may enjoy ZLinq[0], which is a less versatile but much more performant way to write LINQ-like queries. I certainly use a lot of (Z)Linq in my code; the performance tradeoff is just fine for one-off initialization, UI code, editor tooling, etc. [0]: https://github.com/Cysharp/ZLinq

Zero allocation impl? very cool! Arguably, the original runtime should have done this in the first place given the limitations/tradeoffs aren't so bad, but I guess that ship sailed 20 years ago (man that hurts)

Most .NET projects that Linq originally targeted ran in so called "Server" and/or "Workstation" GCs (.NET has had very generic public names for its GCs for a long time which were also somewhat misnomers because even some Desktop apps would run in "Server" GC and it was possible for vice versa [0]) where allocations were cheap, garbage collection was relatively cheap (because both GCs were multi-generational, had strong [but different] tuning for their generations, etc).

Unity inherited a much simpler Boehm GC from Mono. Under a (single generation) Boehm GC allocations are a bit more expensive and garbage collection sometimes a lot more expensive. (A Boehm GC was much easier for C++ engine code to understand/interact with, which is also part of why the .NET modernization project for Unity got so complicated and still has such a ways to go left.)

[0] Fun aside: in fact, modern docker advice for .NET is to switch "server applications" to use "Workstation GC" if you need to stack multiple containers on the same host because of differences in expected memory usage.

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

#64

Post by WorldMaker »

orphea wrote: post #49
raincole wrote: post #17

Earlier quoted context omitted.

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.

One take on it is that yes, the single dot operator was an ancient mistake which is why so many programming language features are about making it smarter. Properties as mentioned in this article are an ancient way to fake the dot operator into a "field" but actually make method calls. Modern C# also picked up the question dot operator (?.) for safer null traversal and the exclamation dot operator (!. aka the "damnit operator" or "I think I know what I'm doing operator") for even less safe null traversal.

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

#65

Post by jayd16 »

moron4hire wrote: post #26

Game developers are not paid to be good developers. They're paid to be young, naive, and easily brow-beat into working unpaid overtime. I think one of my biggest problems with Unity is that it enabled a massive market of me-too "business men" who "employ" unpaid and underpaid interns to hack together asset-store-ware they then dump on the app stores. When a gem game stutters, people blame their crappy phones rather t…

Why wouldn't a released game grow their portfolio?

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

#66

Post by jayd16 »

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…

There is a huge amount of closed source, ecommerce shops that use C#. Its popular in game dev too but TIOBE is probably attributable to the ecommerce.

If you know Java, you should give C# a try. Its a slicker Java with some good decisions that actually make it viable for a lot of things Java struggles at, like better interop with pointers and things like native UI (Maybe Loom will eventually overtake async/await for UI dev but not quite yet).

It works very well on many more use cases than it used to. .NET has followed with the Linux servers in the cloud industry reality and is very stable.

Its just a good language. Try it out.

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

#67

Post by doctorpangloss »

m_w_ wrote: post #56

Some nice tips in here ([field: SerializeField] for example) - but as others note, it's not about modern code, as many of these features have been available for an embarrassingly long time. It's always felt to me that there's some fundamental friction between idiomatic C# and Unity. I remember, after reading about new features C# 8.0, someone wrote that C# 9 would write all your code for you, and that C# 10 would jus…

game development for steam and mobile audiences became so inaccessible due to Unity, iOS and Android's complexity & evolution, a lot of "game" development was programmers engaging in an intellectually curious but otherwise meaningless engine-twiddling circle jerk of sorts. people with good game ideas were not necessarily able to tackle the complexity of those engines - and, based on how bad the games on Roblox are, they aren't using alternative platforms either. they just have had to spend an incredible amount of time to develop something. for everyone else, there is already basically zero audience for most games, so we're going to have heard about, "I made a Rust ECS game engine that runs on a Wiimote" or whatever, because there's an audience for blog posts on hacker news.

then claude code swung everything back in the other direction. things are accessible again. does any of what the article says matter anymore? games are the ultimate, "if it looks good and works correctly, it is good" software product, nobody is going to care if you use [field: SerializeField] or records or whatever.

so yeah, will Claude Opus 6 mail you a check every month? who even needs Unity?

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

#68

Post by oaiey »

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…

We are deploying .NET (Core) on Linux since soon 10 years. With hundreds of devs and dozens of services on thousands of servers.

We have not touched a Windows server in years.

In 2026 .NET is deployed like anything else into Linux containers and Lambdas. Obviously there are still people who love their ui based servers but that is because of that and not because of .NET.

Adoption of new features is gradually and explorative, obviously in an enterprise everything is on a LTS 2-3 back but adoption after that delay is rather quick to my observation.

.NET like Java have this "it is there and we extend it. And the new platform is also .NET because you have your dozens of devs already"

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

#69

Post by WorldMaker »

ablob wrote: post #32
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 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 support is officially maintained in modern .NET and many corporate environments are quietly using Linux servers and Linux docker containers every day to run their (closed source) projects. Linux support is one of the things that has saved companies money in running .NET, so there's a lot of weird quiet loyalty to it just from a cost cutting standpoint. But you don't hear a lot about that given the closed-source/proprietary nature of those projects. That's why it is sometimes referred to as "dark matter development" from "dark matter developers", a lot of it is out there, a lot of it doesn't get noticed in HN comments and places like that, it's all just quietly chugging along and doesn't seem to impact the overall reputation of the platform.

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

#70

Post by jayd16 »

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 and good.

Post reply on HN