See as a C# dev, all the time I think to myself l, "Proffessionally, you should pick up and really learn C++ mate"
Then I see blog posts like this where the author writes for pages and pages about how to get something as simple as await to work manually and I immediately am reminding why even after 11 years I still haven't picked up C++ outside of little things for SBCs and whatnot.
I can see the fun in building such things by hand, but at a certain point I want to be able to actually start a project and jump straight into writing the application itself, and not need a tonne of boilerplate just to get modern functionality.
I will note for this statement:
This is less of a problem if your coroutines are long-lived.
Is typically true. Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
Usually, in my opinion, constantly spinning up and spinning down coroutines is a code smell, and us remedied with some form of pub/sub model where your "background" coroutines should always be running, and they just idle waiting at some kind of subscribed pipe for events to respond to and process.
That way you allocate everything you need at the start, then it all just sits and runs for the entire app lifespan.
Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
That’s an interesting perspective. At that point, what is even the point of coroutines over using threads? I thought the main reason for their existence was being lightweight enough to spin up whenever, wherever you need.
From the article, it seems that coroutines and "green threads" (e.g. goroutines and lua coroutines) are quite different things. As far as I understood, coroutines are just a way to pause/resume operation while retaining local scope state
See as a C# dev, all the time I think to myself l, "Proffessionally, you should pick up and really learn C++ mate"
Then I see blog posts like this where the author writes for pages and pages about how to get something as simple as
await
to work manually and I immediately am reminding why even after 11 years I still haven't picked up C++ outside of little things for SBCs and whatnot.I can see the fun in building such things by hand, but at a certain point I want to be able to actually start a project and jump straight into writing the application itself, and not need a tonne of boilerplate just to get modern functionality.
I will note for this statement:
Is typically true. Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.
Usually, in my opinion, constantly spinning up and spinning down coroutines is a code smell, and us remedied with some form of pub/sub model where your "background" coroutines should always be running, and they just idle waiting at some kind of subscribed pipe for events to respond to and process.
That way you allocate everything you need at the start, then it all just sits and runs for the entire app lifespan.
That’s an interesting perspective. At that point, what is even the point of coroutines over using threads? I thought the main reason for their existence was being lightweight enough to spin up whenever, wherever you need.
From the article, it seems that coroutines and "green threads" (e.g. goroutines and lua coroutines) are quite different things. As far as I understood, coroutines are just a way to pause/resume operation while retaining local scope state