If you're in trouble and cannot find an answer to a question which goes beyond Stack Overflow...
If you have a not-so-usual solution for your problems but need to justify it to your boss...
If you like to think on your own rather than blindly follow "common wisdom" and "profound truth"...
...then 'No Bugs' Hare on Soft.ware might be the right place for you.
Your mileage may vary. Batteries not included

The choice of programming language for your Next Big Project can be difficult. Even worse, it can seem easy… when it is not. On the one hand, strictly speaking, you can write any program in any of Turing-complete languages. On the other hand, that doesn’t mean it will be easy. In fact, writing a program in a poorly suitable programming language could be extremely difficult.

Programming Languages, page 1:

Unchecked Exceptions for C++

Quote: “‘unchecked’ std::errors are treated as ‘something which should never ever happen, but in practice MAY occur as a result of potentially-recoverable bug'”
Another Quote: “Failing-Fast does NOT mean we should necessarily Fail-Hard(!). In certain (production!) cases, Failing-Fast-AND-Soft IS a substantially better alternative.”

App-level Developer on std::error Exceptions Proposal for C++. Part II. The Discussion.

Quote: “having an ability to associate extra information with std::error is important for us – both for our own std::error exceptions, and for conversion from existing C++ exceptions”
Another Quote: “I think that current C++ standard is Badly Lacking(tm) a concept of ‘segfault’ (which is supported by CPUs on VAST majority of modern systems with modern C++ compilers)”

App-level Developer on std::error Exceptions Proposal for C++. Part I. The Good

Quote: “No single error handling method is good enough for ALL the projects – which in turn leads to segmentation, with some of the projects using exceptions, and some others using error codes”
Another Quote: “Right above I said that I like the std::error exception proposal a.k.a.[P0709R0]. However, as soon as I look at competing proposals, I begin to love it.”

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

Quote: “Allocator-based serialization for (Re)Actors is extremely fast (for x64 – around tens of ms per 100MB of state)”
Another Quote: “Per-(Re)Actor allocators can be implemented without any changes within (Re)Actor itself (i.e. all the necessary changes can be confined to Infrastructure Code).”

Using Parallel <algorithm> Without a Clue: 90x Performance Loss Instead of 8x Gain

Abstract: “I made an experiment which demonstrates Big Fat Dangers(tm) of implying that parallelization can be made as simple as just adding a policy parameter to your std:: call.”
Quote: “it is still necessary to understand what we’re doing”