[drenvuk]

You're not the only one. Coroutines are complicated as hell and have too much boiler plate BUT once you handle it for a general enough case you get javascript-esque async await syntax which is very, very nice.

Take for instance, this code which relies on libuv for its event loop and co_await to retain its state during its execution: https://gist.github.com/Qix-/09532acd0f6c9a57c09bd9ce31b3023...

Lets say that you want to batch a bunch of database operations into one transaction. You could queue them up over the course of a few milliseconds, run the transaction, and then for each context that relied on different db operations simply return to each's previous point instead of having to call a handler. Granted, the handler is now inside of the `await_transform` needed to work with `co_await` but think of the possibilities. No weirdly separate callback function, no real need to make a class that encapsulates all of the operations for let's say a user's post request, and to top it all off, you can do this on a single thread. It's a tool for cleaner code but I'll be damned if it is really easy to understand.

It's just so much stupid boiler plate and a strange way of putting it together.

[asdfasgasdgasdg]

It still boggles the mind that they made it so hard to use this stuff in terms of boilerplate. Hopefully that will all be abstracted into a library that handles io, networking, multiprocessing and synchronization so most of us can just focus on writing the bits that do stuff. But I will never understand how the std maintainers could not manage to do this when every other language is doing async await support in their standard library Io utilities.

[sebastos]

I think the reason it's like this is because the C++ maintainers are super focused on noticing whenever there is a choice to be made, and being careful not to make it for you. Given the option between foisting situationally bad performance on you and foisting lots of syntax and interface complexity on you, they always choose the latter. Which I suppose makes sense: C++ niche is that it's the Big Gun you pull out when there's serious work to be done. So they figure you're already going to be dealing with massive complexity anyway, and you're going to be prepared for it. May as well let give you _all_ the access rather than fumbling at the 1 yard line by making some opinionated choice that is a non-starter for somebody, somewhere.

[einpoklum]

> I think the reason it's like this is because the C++ maintainers are super focused on noticing whenever there is a choice to be made, and being careful not to make it for you

If you think that's the case, explain why I can't decide I want to pass an argument to a function in a register:

https://stackoverflow.com/q/58339165/1593077

Also, modern C++ has actually made it possible to write much more elegant code, for many delicate tasks, without sacrificing the performance benefits. So a convenient default doesn't necessarily have to contradict non-opinionated nature.

[DSingularity]

Most of that boilerplate will be hidden in the libraries which use it. Unless you are a library author I don’t know why you would care about the boilerplate-like elements from the standard— you will only use co_yield and co_await.

[j16sdiz]

C++ compilers are famous for their cryptic error messages. Standard Libraries are the reason.

[pjmlp]

Lack of concepts was the reason, it will only get better now.

[tialaramex]

So far as I can see in 2026 the C++ programmers will be assuring us that (some feature from C++26) is going to fix all the awful clag in the C++23 programs which, in turn, offered (some feature from C++23, maybe it's a simpler exception mechanism) but alas instead created more clag, despite their promise to clear up the mess from C++20...

I am an old man, and so I remember when left and right every C++ programmer was excited about how the Standard Template Library was going to make everything OK and those of us who were still jeering would be writing C++ soon. How did that go?

[pjmlp]

I see it differently.

Many will keep hating C++, while ignoring that Java, .NET (C#, F#, VB, C++/CLI), Python, JavaScript, PHP, Ruby,.... all suffer from similar complexity, spread around 30 - 40 years of language evolution and ecosystems.

Others will cling to their outdated toolchains because the language owners played a Python 3 on them.

While some will understand that the world isn't perfect and make do with what is out there.

[bluGill]

That is the way of everything in the world.

[PaulDavisThe1st]

One reason could be that C++ tends to be used more in performance-critical contexts, and frequently the abstractions present in "every other language" can get in the way of performance.

[cobalt]

also the memory management model in c++ is much more complex - most other languages just use garbage collection to deal with reference lifetimes

[PaulDavisThe1st]

garbage collection is one of the abstractions that can interfere with performance. it's out of the question for real time contexts, for example.

[pjmlp]

Depends,

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

On the other hand there is real time where even malloc() is forbidden.

https://en.m.wikipedia.org/wiki/MISRA_C

[PaulDavisThe1st]

The first link covers cases most simply described as "it needs to be fast, as fast as possible, but things won't go wrong if there's a random 8msec delay".

Then there's "things will go wrong if there's a random 8msec delay".

Then there's "people will die and/or property will be destroyed if there's a random 8msec delay".

I was referring only to the last two. And yes, that means no malloc.

[hedora]

The first one targets “sub-millisecond”, which is a eternity in current systems.

According to the third link:

> we observed a negative correlation between MISRA rule violations and observed faults

So, MISRA isn’t really helping with real time at all.

The second link claims pauses are capped at 10us, which (if true) is actually competing with careful use of malloc.

[pjmlp]

On Windows that library is WinRT.