C++20 added minimal support for coroutines. I think they’re done in a way that really doesn’t fit into C++, mostly because they don’t follow the zero-overhead principle. Calling a…
Yes, alas C++ is fun, but very quirky. Perhaps too much. For big (new) projects I wouldn’t recommend it. People are trying to fix it but it’s hard and without breaking old features I don’t think it will be possible to make it better and improve it even more.
I’ve tried what you’re suggesting in order to write highly concurrent multi-threaded applications. I’ve used frameworks that are supposed to handle all the details of concurrency and synchronization for you. Inevitably they have flaws in their implementations where either the framework itself exhibits UB/data races/deadlocks, or else the design makes it far too easy to write your own UB/data races/deadlocks.
The worst part is that these problems usually don’t show themselves until your software has been running in production for thousands of hours, and then reproducing the problem to try to debug it is effectively impossible. I’ve had cases where I resort to building my C++ application in release with debug symbols and then run it inside of gdb in production. I haven’t benchmarked the effect of running it in gdb, but I have to imagine it kills much of the value of even using a high performance language.
Now I exclusively use Rust for any new development, and it’s never delivered any unwelcome surprises to me after deploying.
Yes, alas C++ is fun, but very quirky. Perhaps too much. For big (new) projects I wouldn’t recommend it. People are trying to fix it but it’s hard and without breaking old features I don’t think it will be possible to make it better and improve it even more.
The only way to fix C++ is if you’re willing to break backwards compatibility and invent C++2.0.
But that already exists, and it’s called Rust.
@5C5C5C @SuperFola You don’t have to fix C++. Just use the appropriate level of abstraction. Else be happy that there is backward compatibility.
I’ve tried what you’re suggesting in order to write highly concurrent multi-threaded applications. I’ve used frameworks that are supposed to handle all the details of concurrency and synchronization for you. Inevitably they have flaws in their implementations where either the framework itself exhibits UB/data races/deadlocks, or else the design makes it far too easy to write your own UB/data races/deadlocks.
The worst part is that these problems usually don’t show themselves until your software has been running in production for thousands of hours, and then reproducing the problem to try to debug it is effectively impossible. I’ve had cases where I resort to building my C++ application in release with debug symbols and then run it inside of gdb in production. I haven’t benchmarked the effect of running it in gdb, but I have to imagine it kills much of the value of even using a high performance language.
Now I exclusively use Rust for any new development, and it’s never delivered any unwelcome surprises to me after deploying.