Comment by overgard | Hacker News Reader

Comment by overgard | Hacker News Reader

One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready. It puts you in this awkward situation of, ok, do I develop against this stable thing only to have to replace it in 6 months, or do I do Unity's beta testing for them and waste a ton of my time dealing with their bugs?

The other thing I really dislike is that quality of life improvements in the editor are necessarily bundled with engine updates. With IDEs, usually I can use a newer IDE with an older version of the compiler in something like C++ or Java. But with Unity, if I want the editor enhancements I have to upgrade /everything/, and it's almost assuredly not backwards compatible, a bunch of things are going to break, and half my plugins are going to struggle. It seems like the only realistic way to use Unity is grab a LTS version, and then never-ever touch it until the project is done.

Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games. When I was working in Unity professionally a few years ago I remember we would write code in such a way to avoid creating any garbage for the GC. But that meant that most of the nice features of C# were verboten -- no LINQ, only using certain types of loops, etc etc. Maybe the situation has improved, but it seems like there were better language choices.

> One of the most infuriating things about Unity is they tend to deprecate/stop maintaining working things even though the replacement is still in preview and/or not ready.

A.k.a. life as a software engineer at Google.

I've found that this is just such a common experience, not just with Unity, but everywhere. I think the real problem with Unity is that it's hard to get good guidance about whether to choose the new/experimental path or the old/deprecated path. There are random packages (ProGrids? New input system?) that are marked experimental but ready for production use except the documentation is not as good as it should be. Then there's stuff like DOTS, which is much harder to use in production.

> Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games.

This is more of an implementation quality issue than a language design problem. Unity was stuck on an old version of Mono for a long time, for a licensing reason or something like that. I'm aware that newer C# versions have much better GC performance, but it's not something I have personal experience with.

> Also, while I'm generally a fan of C#, I think it was somewhat of a poor choice for games.

What do you think would be better? C++ is too verbose and full of footguns, and python and javascript are dynamically typed (which is imo bad for learning, because the error messages happen at runtime instead of compile time). I'm a big fan of rust, but even using the Bevy game engine has occasionally reminded me that I appreciate just letting the garbage collector worry about memory management.

(The issues with the garbage collector have mostly been resolved at this point, now that they've implemented incremental GC.)

GDScript in Godot does not use a garbage collector but has a nice Lua-like feel.

Personally I like pure C best

GDScript is a garbage collected language, it uses reference counting. That's literally a garbage collection method: https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

The Unity Editor is moving towards being the container for extensible packages. There is source code provided for rendering pipelines, input handling, UI, and code compiling. This is a lot better than the Unity 4 days where everything would be bundled into the monolith.

But, Unity is not an IDE and neither is Unreal.

You can happily disable the GC for performance-sensitive situations with one line of code: GarbageCollector.GCMode = GarbageCollector.Mode.Disabled; https://docs.unity3d.com/ScriptReference/Scripting.GarbageCo...

Then you can call GC.Collect() to garbage collect e.g. between levels.

LINQ is totally fine as long as you don't do it in e.g. Update() which is called every frame. There are lots of other things you start to learn over time such as .transform internally calls GetComponent<Transform>() which in itself isn't a problem but calling it in an Update() on e.g. VR where you have 72-144 frames per second might not be wise especially if you have 10x Update() methods doing this. That's why Unity has had the Profiler for many years - to pinpoint what is causing garbage to pile up and what methods are killing performance.

Unreal uses GC (refcounting) too, no?

Reply on news.ycombinator.com