No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.
Looking at Unity made me understand the point of C++ coroutines
31–40 of 190 posts
Re: Looking at Unity made me understand the point of C++ coroutines
#32No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.
In all of my years of professional game dev, I can verify that this is not even remotely true. They're used basically everywhere. They're very common when you need something to update for a set period of time but managing the state outside a very local context would just make the code a mess.
Unity's own documentation for changing scenes uses coroutines
Re: Looking at Unity made me understand the point of C++ coroutines
#33More broadly the dimension of time is always a problem in gamedev, where you're partially inching everything forward each frame and having to keep it all coherent across them. It can easily and often does lead to messy rube goldberg machines. There was a game AI talk a while back, I forget the name unfortunately, but as I recall the guy was pointing out this friction and suggesting additions we could make at the prog…
[dead]
Re: Looking at Unity made me understand the point of C++ coroutines
#34Earlier quoted context omitted.
If you need to implement an async state machine, couldn't that just as easily be done with std::future? How do coroutines make this cleaner/better?
std::future doesn't give you a state machine. You get the building blocks you have to assemble into one manually. Coroutines give you the same building blocks but let the compiler do the assembly, making the suspension points visible in the source while hiding the mechanical boilerplate. This is why coroutine-based frameworks (e.g., C++20 coroutines with cppcoro) have largely superseded future-chaining for async stat…
I feel like thats really oversellign coro -- theres still a TON of boilerplate
Re: Looking at Unity made me understand the point of C++ coroutines
#35No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.
Echoing the thoughts of the only current sibling comment: lots of "serious" developers (way to gatekeep here) definitely use coroutines, when they make sense. As mentioned, it's one of the best ways to have something update each frame for a short period of time, then neatly go away when it's not needed anymore. Very often, the tiny performance hit you take is completely outweighed by the maintanability/convenience.
Re: Looking at Unity made me understand the point of C++ coroutines
#36Always jarring to see how Unity is stuck on an ancient version of C#. The use of IEnumerable as a "generator" mechanic is quite a good hack though.
Not that ancient, they just haven't bothered to update their coroutine mechanism to async/await. The Stride engine does it with their own scheduler, for example. Edit: Nevermind, they eventually bothered.
It's ancient. The latest version of Unity only partially supports C# 9. We're up to C# 14 now. But that's just the language version. The Mono runtime is only equivalent to .NET Framework 4.8 so all of the standard library improvements since .NET (Core) are missing. Not directly related to age but it's performance is also significantly worse than .NET. And Unity's garbage collector is worse than the default one in Mono.
Re: Looking at Unity made me understand the point of C++ coroutines
#37More broadly the dimension of time is always a problem in gamedev, where you're partially inching everything forward each frame and having to keep it all coherent across them. It can easily and often does lead to messy rube goldberg machines. There was a game AI talk a while back, I forget the name unfortunately, but as I recall the guy was pointing out this friction and suggesting additions we could make at the prog…
This timing additions to a language is also at the core of imperative synchronous programming languages like Este rel, Céu or Blech.
Re: Looking at Unity made me understand the point of C++ coroutines
#38No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.
Just out of interest, how many serious unity devs have you talked to?
Re: Looking at Unity made me understand the point of C++ coroutines
#39No serious devs even uses Unity coroutines. Terrible control flow and perf. Fine for small projects on PC.
Echoing the thoughts of the only current sibling comment: lots of "serious" developers (way to gatekeep here) definitely use coroutines, when they make sense. As mentioned, it's one of the best ways to have something update each frame for a short period of time, then neatly go away when it's not needed anymore. Very often, the tiny performance hit you take is completely outweighed by the maintanability/convenience.
...and then crash when any object it was using gets deleted while it's still running, like when the game changes scenes, but it becomes a manual, error-prone process to track down and stop all the coroutines holding on to references, that costs much more effort than it saves.
I've been a serious Unity developer for 16 years, and I avoid coroutines like the plague, just like other architectural mistakes like stringly typed SendMessage, or UnityScript.
Unity coroutines are a huge pain in the ass, and a lazy undisciplined way to do things that are easy to do without them, using conventional portable programming techniques that make it possible to prevent edge conditions where things fall through the cracks and get forgotten, where references outlive the objects they depend on ("fire-and-forget" gatling foot-guns).
Coroutines are great -- right up until they aren’t.
They give you "nice linear code" by quietly turning control flow into a distributed state machine you no longer control. Then the object gets destroyed, the coroutine keeps running, and now you’re debugging a null ref 200 frames later in a different scene with an obfuscated call stack and no ownership.
"Just stop your coroutines" sounds good until you realize there’s no coherent ownership model. Who owns it? The MonoBehaviour? The caller? The scene? Every object it has a reference to? The thing it captured three yields ago? The cure is so much worse than the disease.
Meanwhile: No static guarantees about lifetime. No structured cancellation. Hidden allocation/GC from yield instructions. Execution split across frames with implicit state you can’t inspect.
Unity has a wonderful editor that lets you inspect and edit the state of the entire world: EXCEPT FOR COROUTINES! If you put your state into an object instead of local variables in a coroutine, you can actually see the state in the editor.
All of this to avoid writing a small explicit state machine or update loop -- Unity ALREADY has Update and FixedUpdate just for that: use those.
Coroutines aren’t "cleaner" -- they just defer the mess until it’s harder to reason about.
If you can't handle state machines, then you're even less equipped to handle coroutines.
Re: Looking at Unity made me understand the point of C++ coroutines
#40More broadly the dimension of time is always a problem in gamedev, where you're partially inching everything forward each frame and having to keep it all coherent across them. It can easily and often does lead to messy rube goldberg machines. There was a game AI talk a while back, I forget the name unfortunately, but as I recall the guy was pointing out this friction and suggesting additions we could make at the prog…
This is more evident in games/simulations but the same problem arises more or less in any software: batch jobs and DAGs, distributed systems and transactions, etc.
This what Rich Hickey (Clojure author) has termed “place oriented programming”, when the focus is mutating memory addresses and having to synchronize everything, but failing to model time as a first class concept.
I’m not aware of any general purpose programming language that successfully models time explicitly, Verilog might be the closest to that.