The C++ lifetime proposal doesn't seem have to a lot to do with templates. https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...
Are you talking about something else?
In Rust 2019 and beyond: limits to some growthisocpp
CppCoreGuidelines
CSS2015–2026
isocpp / CppCoreGuidelines
CppCoreGuidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
85Distinct people
100Mentions
1Explicit recommenders
45.5KGitHub stars
What to know before exploring
What it is
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
Once you've become familiar with the basics of the language, I highly recommend taking a look at C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines
filereaper used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- microsoft/gsl · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year100 dated mentions
Observed mentions: 2015-09-16 08:12:12 UTC to 2026-01-26 15:51:17 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 21 | 11 | 10 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 20 | 2 | 18 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 16 | 3 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
"Within C++ is a smaller, simpler, safer language struggling to get out."
-- Bjarne Stroustrup
The C++ Core Guidelines are a collaborative effort led by Bjarne Stroustrup, much like the C++ language itself. They are the result of many
person-years of discussion and design across a number of organizations. Their design encourages general applicability and broad adoption but
they can be freely copied and modified to meet your organization's needs.
Getting started
The guidelines themselves are found at CppCoreGuidelines. The document is in GH-flavored MarkDown. It is intentionally kept simple, mostly in ASCII, to allow automatic post-processing such as language translation and reformatting. The editors maintain one
version formatted for browsing. Note that it is manually integrated and can be slightly older than the version in the master branch.
The Guidelines are a constantly evolving document without a strict "release" cadence. Bjarne Stroustrup periodically reviews the document and increments the version number in the introduction. Checkins that increment the version number are tagged in git.
Many of the guidelines make use of the header-only Guidelines Support Library. One implementation is available at GSL: Guidelines Support Library.
Background and scope
The aim of the guidelines is to help people to use modern C++ effectively. By "modern C++" we mean C++11 and newer. In other
words, what would you like your code to look like in 5 years' time, given that you can start now? In 10 years' time?
The guidelines are focused on relatively higher-level issues, such as interfaces, resource management, memory management, and concurrency. Such
rules affect application architecture and library design. Following the rules will lead to code that is statically type-safe, has no resource
leaks, and catches many more programming logic errors than is common in code today. And it will run fast -- you can afford to do things right.
We are less concerned with low-level issues, such as naming conventions and indentation style. However, no topic that can help a programmer is
out of bounds.
Our initial set of rules emphasizes safety (of various forms) and simplicity. They may very well be too strict. We expect to have to introduce
more exceptions to better accommodate real-world needs. We also need more rules.
You will find some of the rules contrary to your expectations or even contrary to your experience. If we haven't suggested that you change your
coding style in any way, we have failed! Please try to verify or disprove rules! In particular, we'd really like to have some of our rules
backed up with measurements or better examples.
You will find some of the rules obvious or even trivial. Please remember that one purpose of a guideline is to help someone who is less
experienced or coming from a different background or language to get up to speed.
The rules are designed to be supported by an analysis tool. Violations of rules will be flagged with references (or links) to the relevant rule.
We do not expect you to memorize all the rules before trying to write code.
The rules are meant for gradual introduction into a code base. We plan to build tools for that and hope others will too.
Contributions and LICENSE
Comments and suggestions for improvements are most welcome. We plan to modify and extend this document as our understanding improves and the
language and the set of available libraries improve. More details are found at CONTRIBUTING and LICENSE.
Thanks to DigitalOcean for hosting the Standard C++ Foundation website.
Read the full README on GitHubWhat Hacker News says
16 sourcesMaybe just to elaborate: In contrast to rust, C++ is a standard defined language, with >3 mature and competitive implementations, two of which (clang / microsofts compiler) provide excellent tooling and support for refactoring (clang in particular) beyond any other language in existence (maybe except Java). Instead of looking at cppreference.com, maybe consider browsing https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... the Cpp Core Guidelines, this outlines a forward looking vision of how good c++ code should look like.
A lot of the static guarantees that rust provides can be modelled in C++ as well, see for example "https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel.... Eventually someone will write a rust-style borrow checker as a clang analysis pass. Already now it is possible to express a lot of
compile time pr
Read the rest
operties cleanly in c++, with features such as constexpr lambdas, static_assert etc. Additional features such as Concepts / meta-classes / modules will improve C++ expressivity even further.
In short, yes C++ has a lot of stuff and everyone knows that it is hard to get a grip on all its features and misfeatures. But there has been a continuous effort to rectify and improve on its short comings. See for example https://clang.llvm.org/extra/clang-tidy/checks/list.html for a list of clang based code transformations that are able to automatically improve your c++ code.
The way I see it, just because of legacy reasons (I can interface with the majority of commercial software developed in the last 30 years (CAD, EDA software, Houdini, Abelton, ...)), tooling reasons (the rust compiler is a slow hot mess, compared to the state of the art c++ compilers) and momentum (there is a large incentive to continuously improve c++, because it is the foundation of a large fraction of commercial software out there) it is unlikely that rust will outcompete c++ in a significant way in the long run.
To close of with an example the lean theorem prover https://github.com/leanprover/lean, implemented in C++ handily beats the 20+ year old Coq prover. One of its key features is multicore support. If you look into its implementation details, the equivalent rust code would have to work around a lot of rust "safety" features, essentially because in many cases it is hard to convince a hardcoded heuristic like a borrow checker that whatever you are doing is safe. The static guarantees that rust gives wouldn't help you at all in correctly implementing some of the very involved algorithms a theorem prover kernel has to implement, while standing in the way of the implementation being straightforward. This leaves aside the obvious tooling (you can use Visual Studio, good profilers and debuggers) and integration (SAT checkers like Z3, LLVM backend) advantages.
> Maybe if they started defining a 'modern c++' subset...
Here it is: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In C++17 constexpr Compile-time Ray Tracer (2017)Like C++ Core Guidelines? https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In CppCon 2018: Simplicity: Not Just For Beginners [video]While I agree that C++ has improved a lot, and while all these extensions to the standard library can, when used carefully, considerably increase readability... well, there remains the fact that they still need to be used with extreme care.
See https://github.com/isocpp/CppCoreGuidelines/issues/1038 for an example of what I'm talking about.
So, readability increases, but the mental load of making sure that stuff doesn't break in subtle and non-euclidian ways keeps increasing, at least when refactoring existing codebases.
In CppCon 2018: Simplicity: Not Just For Beginners [video]C++ Lifetime safety: Preventing common dangling [pdf]
4 points · Open discussionAnother alternative is to migrate to Modern C++. I just did a quick look through the code base.
https://github.com/phusion/passenger/blob/stable-5.3/src/cxx...
Has some issues.
There are pointers everywhere, even a void* *
It does not use RAII to manage resources, instead there a a bunch of raw pointer with sizes and a manually called free function
void freeAESEncrypted(AESEncResult &aesEnc);
Just from this brief look, it does not at all surprise me that the development velocity is suffering.
Joel's article on why you should never rewrite software is worth mentioning. There is probably a lot of institutional knowledge that is embedded in the code which will be lost if you convert to Go.
A better alternative might be to incrementally update the code to C++17 following C++ best practices https://github.com/isocpp/CppCoreGuidelines.
That way
Read the rest
you always have a working product, that has the features and performance that people have come to expect, while at the same time you are eliminating technical debt and increasing development velocity.
In regards to the question about networking libraries all conflicting with each other, it is about to get better. The C++ committee will standardize a C++ Networking library in the near future. The good news is that it is based on asio https://think-async.com/ and asio is tracking the evolving standard. Most new C++ networking libraries are also standardizing on asio.
1. In the introduction, Herb Sutter mentions this talk is also for people that might not know about C++11 features.
2. Use std::string for when you need to own a string. Use std::string_view when you need to reference a string [a]. Generally you want std::string_view for parameters and std::string for member variables. Return values and local variables can be either, but if you're not sure, std::string is safer though slower.
3. You chain optional, but only with nested functions, and you code starts looking more and more like lisp. If you are a fan of a chained syntax, you might be interested in libraries that support "ranges". boost already has ranges and there are proposals to add them to C++20.
[a] If you want more specifics and detail, the CppCoreGuidelines have a section on when to use which string.
https://github.com/isocpp/CppCoreG
Read the rest
The guidelines seem like a document to me: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In 7-Zip: From Uninitialized Memory to Remote Code ExecutionIt's supposed to be part of "Guideline support library", see this section: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
The only implementation so far seems to be from Microsoft: https://github.com/Microsoft/GSL/blob/master/include/gsl/gsl...
In C++ Core GuidelinesAnyone know what these guidelines are talking about when they refer to a 'final_action' object, or the function/keyword 'finally'? I'm referring to E.19. I could not get the example below to compile even using the newest gcc with -std=c++1y at godbolt.org. It seems potentially useful, if it actually exists.
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In C++ Core GuidelinesSmall annoyance (I haven't read the entire thing, but I have strong feelings about this): gsl::index is disgustingly verbose. If you use stl, just use size_t. If you're using something else, follow the conventions they use (be it size_t, int, or whatever). Their examples [1] conveniently omit size_t to push their alternative.
[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In C++ Core GuidelinesRead the Core Guidelines. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
In Ask HN: Best way to learn modern C++?I'd add the CppCoreGuidelines to the list:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
It's a lot of the content in the above but crowdsourced, open for PRs, searchable, and readable from the browser.
In Ask HN: Best way to learn modern C++?Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.