7 ms·

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-

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-/09532acd0f6c9a57c09bd9ce31b3023f 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 5y ago
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.
- PaulDavisThe1st 5y ago
  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 5y ago
    also the memory management model in c++ is much more complex - most other languages just use garbage collection to deal with reference lifetimes
    - PaulDavisThe1st 5y ago
      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 5y ago
        Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ 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 https://en.m.wikipedia.org/wiki/MISRA_C
        hedora 5y ago
        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 5y ago
        Hence why I stated "Depends". It is real time enough to drive battleship weapon systems, the kind of apps where the wrong people die when a GC goes wrong. https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...
        PaulDavisThe1st 5y ago
- sebastos 5y ago
  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 5y ago
    > 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 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 5y ago
  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 5y ago
    C++ compilers are famous for their cryptic error messages. Standard Libraries are the reason.
    - pjmlp 5y ago
      Lack of concepts was the reason, it will only get better now.
      - tialaramex 5y ago
        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 5y ago
        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.
        5y ago
- pjmlp 5y ago
  On Windows that library is WinRT.

asdfasgasdgasdg 5y ago

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.

PaulDavisThe1st 5y ago
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 5y ago
  also the memory management model in c++ is much more complex - most other languages just use garbage collection to deal with reference lifetimes
  - PaulDavisThe1st 5y ago
    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 5y ago
      Depends, https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ 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 https://en.m.wikipedia.org/wiki/MISRA_C
      - hedora 5y ago
        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 5y ago
        Hence why I stated "Depends". It is real time enough to drive battleship weapon systems, the kind of apps where the wrong people die when a GC goes wrong. https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...
      - PaulDavisThe1st 5y ago
sebastos 5y ago
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 5y ago
  > 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 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 5y ago
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 5y ago
  C++ compilers are famous for their cryptic error messages. Standard Libraries are the reason.
  - pjmlp 5y ago
    Lack of concepts was the reason, it will only get better now.
    - tialaramex 5y ago
      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 5y ago
        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.
        5y ago
pjmlp 5y ago
On Windows that library is WinRT.