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

71–80 of 105 posts

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

#71

Post by WorldMaker »

kbolino wrote: post #62
simonask wrote: post #47

Earlier quoted context omitted.

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…

The third bullet is also presumably referring to C#'s ancient wider support for unsafe { } blocks for low level pointer math as well as the modern tools Span and Memory which are GC-safe low level memory management/access/pointer math tools in modern .NET. Span/Memory is a bit like a modest partial implementation of Rust's borrowing mechanics without changing a lot of how .NET's stack and heap work or compromising as much on .NET's bounds checking guarantees through an interesting dance of C# compiler smarts and .NET JIT smarts.

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

#72

Post by AppleBananaPie »

rustyhancock wrote: post #57
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 can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.

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

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

#73

Post by Surac »

I started using .Net with 2.0, learned the api and framework and was very happy with all the functions. i never had the need to switch to the more idiomatic idoms. Sometimes on the go i picked up some new tricks and adopted some new types. Form me a good programmer knows how to avoid cognitive overload and how things work under the hood. Why use LINQ when i can use a foreach or a hashmap. Most of the time people don't understand how i get so much performance out of C#, then i tell them KISS. And know your type system.

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

#74

Post by seabrookmx »

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…

> I don't get to see them really in the Linux ecosystem

Sounds like you're just in a part of the ecosystem that doesn't touch C#. Aside from gamedev, C# is mostly a back-end web language, and almost all new builds are going to deploy to some Linux based serverless offering or something like Kubernetes. At my work, we're a mix of Python/Typescript/C# deploying to Google Kubernetes Engine and Cloud Run.

As for the language, your parallels to Java are accurate but outdated. Older versions of C# were very very similar to Java, but C# progressed when Java didn't. For better or worse (depending on your tastes), C# is more comparable to Kotlin or Swift these days than Java.

That's to say nothing of C#'s contributions to other programming languages; async/await and unsafe{} blocks were both first seen in C# before being adopted elsewhere.

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

#75

Post by seabrookmx »

drzaiusx11 wrote: post #38
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…

Mono was in a usable state on Linux for literal decades before becoming official and integrated into what is core today, that is unless you needed windows forms, which much like MSFT UI frameworks today had multiple failed attempts spanning those same decades...

Only if you didn't care about performance.

We attempted a move to mono for backend web services maybe 3 years before .NET Core released, and it was a complete no-go. 10x reduction in performance on the same hardware.

This wasn't specific to our workload either. I was big into the game Terraria at the time, and I saw similarly poor performance when running it's game server under mono vs .NET 4.x

While some of the mono toolchain was integrated into .NET Core, CoreCLR was a rewrite and immediately solved this problem.

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

#76

Post by Fred27 »

rustyhancock wrote: post #57
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 can't comment on Godot or Unity which both use primarily C#. Unreal engine which uses C++ primarily, has the problem that it's a humongous mostly legacy code macro heavy system . If anything being proficient in C++ before you start is harmful because of the puckering of orifices when you hear about it's mostly quirky powerful macros all the way down.

I agree. I came to Unreal with only a basic level of C++. Having Unreal handle memory management for you was useful, but I can imagine the chaos an Unreal-only C++ developer might cause when unleashed on another C++ codebase.

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

#77

Post by MattCruikshank »

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?

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

#78

Post by slopinthebag »

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…

It's also because gamedev is very highly iterative, so if you're abstracting stuff you end up throwing away your abstractions when things inevitably change. And that costs more than just changing some if statements.

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

#79

Post by enbugger »

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?

> I don't want to design anything in any UI.

I had the same need and found Raylib_cs suit very well for that

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

#80

Post by kbolino »

WorldMaker wrote: post #71
kbolino wrote: post #62

Earlier quoted context omitted.

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…

The third bullet is also presumably referring to C#'s ancient wider support for unsafe { } blocks for low level pointer math as well as the modern tools Span and Memory which are GC-safe low level memory management/access/pointer math tools in modern .NET. Span /Memory is a bit like a modest partial implementation of Rust's borrowing mechanics without changing a lot of how .NET's stack and heap work or compromising a…

The FFM API actually does cover a lot of the same ground, albeit with far worse ergonomics IMO. To wit,

- There is no unsafe block, instead certain operations are "restricted", which currently causes them to emit warnings that can be suppressed on a per-module basis; it seems the warnings will turn into exceptions in the future

- There is no "fixed" statement and frankly nothing like it all, native code is just not allowed to access managed memory period; instead, you set up an arena to be shared between managed and native code

- MemorySegment is kinda like Memory/Span but harder to actually use because Java's type-erased generics are useless here

- Setting up a MemoryLayout to describe a struct is just not as nice as slapping layout attributes on an actual struct

- Working with VarHandle is just way more verbose than working with pointers

Post reply on HN