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

Looking at Unity made me understand the point of C++ coroutines

mropert.github.io

Post reply on HN
Print view View original

141–150 of 190 posts

Re: Looking at Unity made me understand the point of C++ coroutines

#141

Post by momocowcow »

jayd16 wrote: post #121
DonHopkins wrote: post #39

Earlier quoted context omitted.

...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…

So if you need to conditionally tick something or you want to wait for an effect to finish, etc., you're using Update() with if() statements? The same code in a coroutine hits the same lifecycle failures as Update() anyway. You don't gain any safety by moving it to Update(). > No structured cancellation. Call StopCoroutine with the Coroutine object returned by StartCoroutine. Of course you can just pass around a canc…

Enjoy shipping console titles that run at a constant 60 fps with no GC.

Again, fine for pet projects on PC :)

Re: Looking at Unity made me understand the point of C++ coroutines

#142

Post by jayd16 »

momocowcow wrote: post #141
jayd16 wrote: post #121

Earlier quoted context omitted.

So if you need to conditionally tick something or you want to wait for an effect to finish, etc., you're using Update() with if() statements? The same code in a coroutine hits the same lifecycle failures as Update() anyway. You don't gain any safety by moving it to Update(). > No structured cancellation. Call StopCoroutine with the Coroutine object returned by StartCoroutine. Of course you can just pass around a canc…

Enjoy shipping console titles that run at a constant 60 fps with no GC. Again, fine for pet projects on PC :)

I'll continue to bite... What AAA 60+fps mobile game written Unity without coroutines are you referring to?

Re: Looking at Unity made me understand the point of C++ coroutines

#143

Post by maleldil »

quietbritishjim wrote: post #119
01HNNWZ0MV43FF wrote: post #113

Earlier quoted context omitted.

async is simply a difficult problem, and I think we'll find irreducible complexity there. Sometimes you are just doing 2 or 3 things at once and you need a hand-written state machine with good unit tests around it. Sometimes you can't just glue 3 happy paths together into CSP and call it a day.

Using structured concurrency [1] as introduced in Python Trio [2] genuinely does help write much simpler concurrent code. Also, as noted in that Simon Tatham article, Python makes choices at the language level that you have to fuss over yourself in C++. Given how different Trio is from asyncio (the async library in Python's standard library), it seems to me that making some of those basic choices wasn't actually that…

Python's stdlib now supports structured concurrency via task groups[1], inspired by Trio's nurseries[2].

[1] https://docs.python.org/3/library/asyncio-task.html#id6

[2] https://github.com/python/cpython/issues/90908

Re: Looking at Unity made me understand the point of C++ coroutines

#144

Post by matheusmoreira »

nottorp wrote: post #137

> turns it into some sort of ugly state machine Why are people afraid of state machines? There's been sooo much effort spent on hiding them from the programmer...

They're essentially callable, stateful, structured gotos. Difficult to understand for the uninitiated.

For example, generators. Also known as semicoroutines.

https://langdev.stackexchange.com/a/834

This:

  generator fib() {
      a, b = 1, 2
      while (a
Becomes this:

  struct fibState {
      a,
      b,
      position
  }

  int fib(fibState state) {
      switch (fibState.postion) {
          case 0:
              fibState.a, fibState.b = 1,2
              while (a
The ugly state machine example presented in the article is also a manual implementation of a generator. It's as palatable to the normal programmer as raw compiler output. Being written in C++ makes it even uglier and more complicated.

The programming language I made is a concrete example of what programming these things manually is like. I had to write every primitive as a state machine just like the one above.

https://www.matheusmoreira.com/articles/delimited-continuati...

Re: Looking at Unity made me understand the point of C++ coroutines

#146

Post by troad »

djmips wrote: post #145

The 'primitive' SCUMM language used for writing Adventure Games like Maniac Mansion had coroutines - an ill fated attempt to convert to using Python was hampered by Python (at the time) having no support for yield.

I did not know that, that's neat. Are there any blog posts or articles that go deeper into this?

Re: Looking at Unity made me understand the point of C++ coroutines

#147

Post by throwaway17_17 »

jandrewrogers wrote: post #118
zozbot234 wrote: post #93

Earlier quoted context omitted.

People love to complain about Rust async-await being too complicated, but somehow C++ manages to be even worse. C++ never disappoints!

I find C++ coroutines to be well-designed. Most of the complexity is intrinsic because it tries to be un-opinionated. It allows precise control and customization of almost every conceivable coroutine behavior while still adhering to the principle of zero-cost abstractions. Most people would prefer opinionated libraries that allow them to not think about the design tradeoffs. The core implementation is targeted at eff…

I don’t know if the language is yours, but I think the wording and its intended meaning (the sentence starting with ‘The core implementation…’) may be one of the most concise statements of my personal programming language design ethos. I’m jealous that I didn’t come up with it. I will certainly credit you when I steal it for my WIP language.

I will be adding the following to my “Primary Design Criteria” list: The core design and implementation of any language feature is explicitly targeted at the efficient creation of opinionated, composable abstractions rather than providing those abstractions at the language level.

Re: Looking at Unity made me understand the point of C++ coroutines

#148

Post by throwaway17_17 »

fooker wrote: post #122
jandrewrogers wrote: post #118

Earlier quoted context omitted.

I find C++ coroutines to be well-designed. Most of the complexity is intrinsic because it tries to be un-opinionated. It allows precise control and customization of almost every conceivable coroutine behavior while still adhering to the principle of zero-cost abstractions. Most people would prefer opinionated libraries that allow them to not think about the design tradeoffs. The core implementation is targeted at eff…

C++ standards follow a tick-tock schedule for complex features. For the `tick`, the core language gets an un-opinionated iteration of the feature that is meant for compiler developers and library writers to play with. (This is why we sometimes see production compilers lagging behind in features). For the `tock`, we try to get the standard library improved with these features to a realistic extent, and also fix wrinkl…

Regarding your mention of compiler magic and Swift, I don’t know much about the language, but I have read a handful of discussions/blogs about the compiler and the techniques used for its implementation. One of the purported benefits/points of pride for Swift that stood out to me and I still remember was something to the effect of Swift being fundamentally against features/abstractions/‘things’ being built in. In particular they claimed the example of Swift not having any literal types (ints, sized ints, bools, etc) “built in” to the compiler but were defined in the language.

I don’t doubt your point (I know enough about Swift’s generic resolution crapshow during semantic analysis to be justified in assuming the worst) but can you think of any areas worth looking into for expansion of the compiler magic issues.

I have a near reflexive revulsion for the kinds of non-composability and destruction of principled, theoretically sound language design that tends to come from compiler magic and shortcuts, so always looking for more reading to enrage myself.

Re: Looking at Unity made me understand the point of C++ coroutines

#149

Post by CyberDildonics »

zozbot234 wrote: post #93
Joker_vD wrote: post #9

Simon Tatham, author of Putty, has quite a detailed blog post [0] on using the C++20's coroutine system. And yep, it's a lot to do on your own, C++26 really ought to give us some pre-built templates/patterns/scaffolds. [0] https://web.archive.org/web/20260105235513/https://www.chiar...

People love to complain about Rust async-await being too complicated, but somehow C++ manages to be even worse. C++ never disappoints!

C++ is great, coroutines are not. Neither of these are good ways to handle concurrency. You really need a more generalized graph and to minimize threads and context switching. You can't do more than the number of logical cores on a CPU anyway.
Post reply on HN