It's surprising that C++'s development trend continues.<p>When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.<p>I'd be happy if someone else wrote it, but it's not a language I want to write myself
Personally I don't find programming with C++ that hard. The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code.<p>I have to go through the same warm-up more or less for any language I work with, so it's not that different than writing Python, Go or Java for me.
I find C++ not hard at all when working with familiar idioms, restrictions and toolings (familiar to me). But it's hard jumping into new codebases and adjusting yourself to new patterns. Recently I did a lot of programming using C++23 Modules and it was a breeze.<p>There's basically dozens of very nice languages inside C++. That can be a blessing or a curse.<p>I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.
What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.
The tooling people have - as of about a year ago said they are ready. Now everyone who considers themselves early adopters is using then. Most are waiting for the early adopters to figure out what the best practices are so we don't make a mess
YC startup. Toolchain was Clang and sh.<p>Chromium is gonna be more conservative than that for sure.
In February this year Herb tweaked a test case. That was his last commit to his "CPP2 syntax experiment". Don't expect it to "become a standard".<p><a href="https://github.com/hsutter/cppfront/commits/main/" rel="nofollow">https://github.com/hsutter/cppfront/commits/main/</a>
>I'm anxious for Herb Sutter's CPP2/CPPFront to become a standard.<p>Why? It doesn't remove complexity, it (partially) hides it and makes the whole thing even more complex.
Looked up what C++23 Modules were and I must say I was not let down.
I agree.<p>You don't learn or know C++ in the way you learn or know C.<p>You never have the total language spec in mind. Much of it you will never (and for some of it should never) come across.<p>The way I think of it<p>C is an abstraction of the machine, so thin it's nearly transparent.<p>C++ is an abstraction over programming paradigms, letting you pick how you think.<p>Everything else abstracts the machine away, replacing it with a VM, runtime, or model of its own.<p>The same way a good project has a clear model of the problem it should have a clear C++ pattern in use.
There are so many standards and idioms that it gets confusing. There are still legacy codebases out there — some codebase still use C++98 as their standard, others use C++11... And with Unreal Engine, the modern C++ standard is C++14, right? There are things like smart pointers, but some places don't even use them. I feel like there are just too many features. When I saw template metaprogramming — that new feature — I realized I have no talent for C++.
I have developed things with C++98, C++11 and C++14. Every of these standards are so vast, so remembering everything (even in a single standard) is not possible. Instead of knowing everything, I first fix the standard I want or need to work with.<p>Then I design the thing I want to build. I <i>always</i> design what I want to build beforehand. This takes a couple of iterations from high level to low-ish level. That last design becomes a bit language dependent. Then I select some of the core tools that I'm going to use (which kind of pointers, classes or structs, etc.)<p>With that design in mind, I go "library shopping" both for file formats (if any) or other stuff like vectors, etc.<p>Armed with the reference docs of these, I write my code with the toolbelt I have built for the project.<p>Some things are hard, but they are not impossible. I find thinking like compiler helps a lot.
> When I saw template metaprogramming — that new feature — I realized I have no talent for C++.<p>It's not a new feature. And tbh, compared to Typescript, C++ templates are tame ;)<p>(but yeah, deciding when to stop digging into the template metaprogramming rabbit hole requires some common sense and sanity, too much template complexity is almost never worth the hassle)
This is true of any language. Python with flask vs django, with/without type hints. JavaScript with anhular and vue.<p>The varying standards are no different to major python versions or go versions - arguably there’s even less between most versions than there is in your average go release.<p>The differences in apps and frameworks don’t matter for day to day - std::string, Unreal’s FString and QT’s QString all are similar enough that 99.9% of the time.<p>Metaprogramming is one of those things; you either write it or you don’t. Knowing some basics is required but the vast majority of people use a handful of pre existing things without understanding the nuances of how it works under the hood.
> The downside is it needs a brain warm-up, and this is per project, but once that flywheel is spinning, I find it almost effortless to write code.<p>How is that different from other languages, which don't need the brain warm-up?
The difference, if you split hairs, that the brain warm-up takes a bit longer. Maybe a couple of hours, or a day at most.<p>Otherwise it's not different <i>for me</i>. I don't feel different while writing with any other language. I guess the main reason is I always think like the computer first and translate that thinking to the programming language at hand.
For games, C++ becomes a much simpler language since game code bases usually ignore the C++ stdlib (at least mostly, and for good reasons, e.g. see [0]). And without the stdlib C++ is actually kinda-sorta okay-ish.<p>Related, the main problem with the C++ ecosystem is that everybody carves out their own language subset, so it's not one ecosystem but many ecosystems with contradicting styles and language/stdlib subsets. This makes code reuse via libraries much harder than it should be.<p>[0] <a href="https://hftuniversity.com/post/the-c-standard-library-has-been-walking-itself-back-for-fifteen-years-and-the-receipts-are-public" rel="nofollow">https://hftuniversity.com/post/the-c-standard-library-has-be...</a>
I fully agree. In my personal project, I ended up using the STL to get off the ground, but in the end I replaced pretty much everything with custom-written code.<p>Once you get rid of the STL, compile times get so much better. With modern c++23 features, templates actually become really convenient to write, and at the core there is a really useful and pleasant to use language.<p>I try to avoid c++ libraries and instead rely on c-style APIs. Usually the c++ style libraries force you into using the STL, which comes with a heavy tax on compile times, without much benefit in comfort of use.
Your citation refers to the register keyword and trigraphs, among other language features -- the author seems to have forgotten his own point, among a number of other inconsistencies and contradictions, and at times seems to go out of his way to come across as a jerk, e.g., "This is what fifteen years of standards work on an eight-letter keyword looks like".<p>People love to rag on the standards committee. I was on X3J11, the C Language Standards Committee, in 1989 ... in fact, due to alphabetical order I was the first person on the planet to vote to approve the C language standard -- the one that first standardized register and trigraphs. Standards work is hard and everyone hates you for it.
If you don't use the STL you end up re-implementing it yourself. Usually poorly.
> Usually poorly.<p>On the contrary. You can focus exactly on the features the higher level game code needs. The C++ stdlib is (for the most part) poorly designed, usually poorly implemented, the main reason for slow build times, and its complexity explodes because it needs to consider all edge cases that most code bases don't ever trigger.<p>A specialized dynamic array class in a few hundred lines (at most!) and with just the required features is <i>much</i> more useful than the 20kloc monster that's pulled in with `#include <vector>` and which doesn't even do bounds checking in the 'idiomatic' usage.
Saying it doesn't even do bounds checking (in release builds) is to miss one of the major points of C++ - not paying for what you don't need. It's not a mistake, it's a feature.<p>You complain about it not being suitable for game development in one comment but then expect bounds checking in release builds? You're sitting in multiple lanes at the same time.<p>NIH implementations are usually grossly inferior because as it turns out, it's quite hard to get it right and those edge-cases aren't important until you start getting bitten by them when you'd rather be shipping features.
> bounds checking in release builds<p>Bounds checking overhead is negligible for all but the absolutely hottest code paths (fwiw we shipped active asserts, including bounds checking asserts in all the PC games I was involved with - carefully monitoring the overhead of course).<p>The main reason to not use the stdlib isn't so much about squeezing out the last bit of performance, but about control of what actually happens under the hood (and also compilation times). The overall runtime cost of all those active asserts (not just the range checks, <i>everything</i>) was somewhere in the 2..3% range, which is fine when budgeted for upfront.
Yes I don't disagree that sometimes a specific container or a data structure is great for the problem. Problem is that most of the game code and related code (so tooling,editor, auxiliary engine code) does need a typical STL type functionality and then when the org has "omg no STL" blanket rule someone ends up implementing STL and that's almost always worse than the STL that ships with the tool chain. Even worse..it'll be missing features and data structures and then people have to write sub-optimal code to work around it's limitations.
I find it hard to agree that the stdlib is poorly designed and implemented. In my entire career it has pretty much worked entirely to spec.<p>Yes, it can exhibit non-optimal performance, and in some specific cases (regex's especially), extremely poor performance, but that's not the same as being poorly designed and implemented, especially given the breadth of the thing.
Which is why one of the security measures in C++26 is to make bounds checking idiomatic, finally.
some of the STL is easy to improve on. For example, std::unordered_map performs poorly due to pointer stability requirements in the standard. Most performance sensitive C++ codebases will use something like abseil's hash maps instead.
Which is worse? std's mess or one you control? I'd take any random game engine's STL over std any day.
C+ Standard Template Library is the best designed part of C++ library. It was designed by Alexander Stepanov.<p><a href="https://en.wikipedia.org/wiki/Alexander_Stepanov" rel="nofollow">https://en.wikipedia.org/wiki/Alexander_Stepanov</a>
So, a few things (aside from the whole nomenclature argument already in another reply)<p>1. Stepanov's generic programming is a good idea. Every language you've seen with "generics" that's his idea, to the extent "The STL" is generic programming, everybody agreed it's a good idea.<p>2. But the STL is very old now, so while the idea is good, this is one of the oldest (Stepanov had tried this in other languages before C++) implementations and so other implementations are often better, because they've learned from experience<p>3. As well as pretty good generic algorithms, the STL also provides a lot of container types (what Rust would call collection types) and these vary not between "excellent" and "mediocre" but between "mediocre" and "inexplicably terrifying". The most charitable explanation is that they're just intended for teaching. If you teach DS&A to a Computer Science class you want the Extrusive Doubly Linked List to teach in class. If you write software you almost certainly never need this type, but it's front an centre in the C++ STL.<p>There's a single "I guess I would use this" container type, std::vector. It has an insane special case for bool, because WG21 are idiots, but it's otherwise a good enough growable array type and it's not worth building your own instead given the constraints.<p>Everything else is silly, or bad, or both. std::unordered_map feels like a hash table I made in class in the mid 1990s, but it's actually the provided standard hash table container in C++ 11 onwards. std::list is just that extrusive linked list for some insane reason. The Microsoft standard library maintainer STL could not offer me any justification for what std::deque is actually <i>supposed</i> to be for.
I would argue that even the basic concept behind STL is misguided. The rationale I often see is "you only need N algorithms for M container type, instead of N*M". This ignores the fact that algorithms and data structures are not independent of each other, and also that most of the time these days you're operating on vectors, so M ~= 1.<p>Case in point: list::sort. You don't want to try running quicksort on a linked list. Or remove_if: great we've abstracted the difficult task of removing things without erasing them, except we can't do it on maps. (C++20 seems to add an erase_if, apparently admitting that the two-step remove/erase is silly).<p>Then there's the fact that C++ iterators are basically pointers into the data structure, where for vectors (your common case) you'd do much better with index/container pairs, both for stability and bounds checking.
AFAIK, std::map is also OK for what it is: an ordered, node-based (tree) map. These are (almost) always slower than hash tables. Of course, std::unordered_map, the std hash table, sucks because of unforced errors. For that, there is boost::unordered_flat_map.
> There's a single "I guess I would use this" container type, std::vector.<p>About that one... I would claim that in a majority of cases where an std::vector is used, what the author really wanted was a similar type, but whose size and capacity are fixed on construction and never change. The standard C++ library does not offer such a type - so people use vector because it's handy.<p>Agree with your takes on most of the containers. I also dislike how optionals are never used with containers as they were standardized later (and even then, problematically w.r.t. references). Thus, for example, if I lookup an object in a map of T's, the result should IMNSHO be an optional reference to a T.
It has some very useful principles, but also some super-annoying gaffes and mis-design aspects. One example: Allocators. What a mess! Or the fact that if a map lookup fails, an exception is thrown. I can't count the times I've had some app just bail out on me with an at() exception, because the author neglected to handle it (and the map/unordered map interface did not force them to). That does not detract from Stepanov's important work.
The kind of programmer who don't check (or think through so that they can't fail) their map lookups is also the kind of programmer who don't bother with const. What a non-const unchecked map lookup gives you is a default-constructed value that has just been inserted for the only reason that operator[] returns a reference, which must "point" to something. That's bad and can be confusing, but it doesn't crash.<p>I see that problem much more often than crashes due to unchecked map lookups in production, which are very rare for me. Less than once a year.
Nowadays also used by many of us (wrongly) to refer to the overall C++ standard library, instead of what was inherited from C.
That article probably isn't the best source to cite. You can look at the discussions on it elsewhere, although I'd just dismiss it as slop.<p>The standard library is mostly fine to use unless you have specific needs.<p>The bit about libraries is nonsense, sorry.
You're right that C++ has a lot of features. But like mentioned elsewhere most projects define their own conventions and the subset of features that they use.<p>Also the nice thing about having a large set of features is that C,++ allows you to write very nice abstractions (or not) at both very low or at very high level. In other words you can be very low level with online ASM and bit operations and bit and direct memory manipulation or very high level almost like a script language. Whatever the problem domain needs C++ has got you covered.
You can be pretty productive even with 70% of the language :) It is a common misconception that C++ is suitable only for game engines and similar domains. It is perfectly fine for applications domain as well.<p>As a side note, regarding your profile info, unless you are based in North Korea, please at least add one 0 to your rate. You'll get more long-term and high-quality clientele.
> You can be pretty productive even with 70% of the language<p>Or even far less than that. I like to use it as C with lambdas and namespaces. Sprinkle in metaprogramming as needed. Even just not having to remember to call cleanup code thanks to dtors would alone be enough to sell me on it.
Only by people that started working in Web during the 2000's.<p>Back in the 90's, it was the main business language alongside Smalltalk, Delphi and VB.<p>Hence the plethora of C++ frameworks to chose from, sadly most dead since .NET and Java took over most of the use cases.
Honestly, I don't expect to find clients here. Fundamentally, you have to trust me to give me work. The amount of money doesn't really matter much to me.
Not really, despite all its warts, it is exactly because of them that many reach out to C++.<p>Many of us don't like C, it was already too little and too unsafe, when the first C++ compilers started to hit the market in early 1990's, hence why all desktop OSes moved into C++ for their frameworks.<p>The return to C has caused by the rise of FOSS, UNIX winning the server room, and early GNU coding standards to use only C as main compiled language.<p>Additionally as many other programming language ecosystems have discovered, it is easy to beat C++ in version 1.0, and eventually all of them grow to get the complexity of their own.<p>I reach for C++, because the language runtimes, compiler tooling, and GPGPU frameworks I care about are partially written in C++, and I am not in the place to be writing new ecosystems myself.
The language is fine, mostly, nowadays.<p>The ecosystem isn't fine - just to get a project going requires picking a non-trivial set of tools and approaches, none of which the C++ standard enforces or guides to.<p>For example, will you manage dependencies via packages? If so, with what? What will you use for building your project? The list goes on and on.
No it's not.<p>The language keeps growing, with<p>- new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less<> key for transparent lookup in maps)<p>- new features not usable by the layman (coroutines ...)<p>- Cryptic syntax (reflection...)<p>- Stuff you are told not to use because of performance reason and that cant be fixed because of ABI (regex)<p>- Compile errors that are 1km long (no, concepts are not helping here, the 'nicer' message is still buried into a hot pile of template instantiation callstack).
I wonder how many programming languages would be able to devoid of all or some of these problems when they are 40 years old.<p>It's easy to compare new and old languages, and saying older languages are wrinkly. Let's see how other shiny programming languages look like when they are 40 years old.
Python, Java, Lua, Ruby are ~30 years old, Ada being as old as C++.<p>Sure, none is perfect and they have cruft and warts, but they are not such a mess as C++ is.
So a bit like Python or any other language of similar age.
I personally find the lack of native package management in C++ as a blessing. Go, Python, Rust has it, and this always causes pulling in infinite number of packages for any trivial operation.<p>sudo-rs was pulling in 1M+ LOC as its dependency chain at one point. I believe they removed the biggest offenders, but I didn't check it recently.
funny, I think the same about rust.
(Safe) Rust is a lot better about the "Pit of Success" design than C++<p>There are fundamental technical choices to deliver that, but also ergonomic things like notice Rust's []::sort is a stable sort, whereas C++ std::sort is an unstable sort. If you don't know about sort stability in Rust what you wrote works and in C++ you get a nasty surprise.
>There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.<p>If you'd already been using it for 10+ years you wouldn't feel that way, because you'd already have memorized a lot of it.
Except the language keeps growing, with<p>- new features overlapping old features previous standards without replacing them or deprecating them.
- new features not usable by the layman
- ...<p>See function::copyable_function vs std::function, modules, coroutines, Reflection syntax is cryptic at best, ...
You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment.<p>Hell, if you wait long enough, they'll just deprecate it before you can care to bother.
And that's the usual fallacy (just ignore the bad stuff).<p>But if you work with C++ in professional context, you will encounter it somewhere (library, teamate's PR, legacy code, LLM output, book / blog / conference ...). |<p>You actually need to know the bad stuff to be able to judge it and discard it.
Since I've been working in C++ a lot recently I decided to watch the video as I waited for a build to complete. So the length is about right. And fortunately, the video is a delight!
So happy to see Andrei Alexandrescu was included in this documentary. His book on modern C++ design was a mind opener at the time I read it. Maybe still is today. Anybody else read it?
I always tell web developers I teach that the language of the internet isn’t JavaScript it’s C++.<p>Web devs are just users playing in a C++ dev’s program. ;)
I'm going to rent the local cinema and invite all my normal friends and family for this. About time they watch something decent.
I love a free documentary about something that I'm passionate about. So many thanks.<p>However, I'm a my own kind of weird. I cannot watch a documentary that's made out of people saying short sentences. I get that it's made to 'have them tell the story', but I need a narrator to tell me what to think because I get distracted.<p>Still lots of love to the creators, of course.
Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still
My only problem with C++ is that it’s too verbose. my eyes need to parse huuge chunks of things when I just want some convenient syntax for it. otherwise the idioms are pretty universal for most programming languages nowadays.
The trouble with that is the more mental capacity you exert on the language the less you have available for the task at hand.
Try Java
C++ is quite amenable to making things less verbose. For example: Instead of a standard library algorithm taking a pair of iterators, you could have a function taking a container and calling the other function with its start() and end(). And then, with newer versions of the language, you can use a ranges-based function. There are lots of such syntactic hacks, from `using` through typed literals all the way to preprocessor macros (which we want to avoid, but are still there).<p>That's how you emulate language features that aren't there originally. I've "impelemented" a static code block, like in Java:<p><a href="https://stackoverflow.com/a/34321324/1593077" rel="nofollow">https://stackoverflow.com/a/34321324/1593077</a><p>and that's all in C++98. The implementation is a bit ugly but the use is terse and self-expalantory.
I‘m out of the loop: we‘ve had Python, Clojure and possibly something else recently. Is that a series by the same people working through several languages? Is it happenstance? Is it a trend, and every programming language is now scrambling to get their own video documentary?
Yes, these are the same people: <a href="https://www.cultrepo.com/" rel="nofollow">https://www.cultrepo.com/</a><p>Apparently, they are making documentaries about open source software.
That‘s cool, since it establishes a brand. If one was done well, the others probably are, too, so even if it‘s not your language of choice, it will be interesting.
What a lineup of contributors—Stroustrup, Stepanov, Kernighan, Lattner, and more in one film. Forty years from 'C with Classes' to the fastest-growing of the top four languages is a remarkable arc, and it's nice to see the people behind it get their due. Adding this to the weekend watchlist. Thanks for sharing, Herb!
wild that c++ is apparently the fastest growing top 4 language right now
Thank you for releasing this for free! :)
> currently (as of Q3 2025) the fastest-growing of the top four languages in the world… +90% users in the past 3.5 years.<p>Because of AI, right?
C++ is one of the languages less suited to the strengths of coding agents.<p>The language which still supports C-style pointers, arbitrary datatype conversions, and inherits architecture-specific undefined behavior gives you too many ways to fail at solving a problem.<p>As a programmer, I love coding in C++ because I know what I'm doing. I'd hate reviewing C++ code though.
If this is a rhetorical question I genuinely don't know what's the implied answer. Why would AI specifically make C++ grow?
A few reasons:
1. Header files make C++ verbose. Header files are well within LLM's ability
2. LLMs can handle setting up cmake for you
3. C++ is very well documented relative to (most) newer languages
4. LLMs can port modern features like websockets and build API wrappers easily, reducing the disadvantage against web (since most documentation is for JS/python/go)<p>Coding languages have been developing for speed of (manual) writing - akin to how human languages did with modern alphabets. Now that writing is a lot easier, languages will likely evolve towards a focus on execution (or in the case of human languages, speed of reading and precision of understanding)
All of those seem like barriers that make C++ unappealing in general, but you're deciding to overcome the barriers using an LLM and seeing that as a strength somehow?
Yeah, C++, the language known for its speed of reading...
Let's assume that it's because of AI for this case.<p>Is this good or bad?
but do vibe coders even use c++? won't they use js or python?
Good, thank you!
<p><pre><code> +90% users in the past 3.5 years
</code></pre>
huh? That is incredible growth. How is it even measured?
Herb's blog post links to the SlashData Developer Nation Survey, so presumably that's what the claim is based on. The company has a methodology page here [1], and it looks like the Developer Nation panel [2] is one of the sources used by that company.<p>[0]: <a href="https://www.slashdata.co/research/developer-population" rel="nofollow">https://www.slashdata.co/research/developer-population</a><p>[1]: <a href="https://www.slashdata.co/company/methodology" rel="nofollow">https://www.slashdata.co/company/methodology</a><p>[2]: <a href="https://developernation.net/" rel="nofollow">https://developernation.net/</a>
You can hear the engineer in that second question. They hear a wild statistic pulled out of someone's ass and ask what is that sticking to the side?
Is it better than the Erlang documentary?
[dead]
[dead]
[flagged]
I have the utmost respect for Casey, but his disdain for Stroustrup is unfounded. The fact of the matter is C++ occupied a niche in the right place and at the right time, and it grew from there. Many mistakes have been made, but Stroustrup is in no way personally responsible for all of them and I don't think Stroustrup is a bad programmer (something I've heard Casey say in some of his videos). You can argue that the committee route is not the best, but C++ is here to stay and by some metrics adoption is actually growing.
Strangely, I've never seen any nice code from Casey despite all of the mud slinging he's done over the years. Maybe it exists somewhere but I watched a lot of Handmade Hero when it was starting off and the code was a mess.<p>It feels as though he just attracted an audience of junior developers who take everything he says as gospel, as is often the case with social media programmers. Lord knows I've argued with some of them and they usually crumble as soon as they don't have one of his opinions to throw back at you.
I'm confused. I looked at the Handmade Hero videos and I had no trouble following - it was simple straightforward procedural code.
As I understand it, his code does "exist somewhere". Bink 2 from RAD Game Tools, which seems to ship with practically all games.
He also developed the Walk System that shipped in "The Witness" (2016). You can see his blog posts and video lecture about that. I see that he and a Jay Stelly from Valve simplified the GJK algorithm, and he talks about how to implement it.
I know he has his Performance-Aware Programming series, where he talks about the technical details of hardware and how they relate to code performance.
Here, I even found a tweet listing all the things he'd written till that point: <<a href="https://xcancel.com/cmuratori/status/1412839131063873536" rel="nofollow">https://xcancel.com/cmuratori/status/1412839131063873536</a>>.
Perhaps you didn't look hard enough?<p>Can someone give me links to Bjarne Stroustrup's code? I tried searching but I'm having a hard time finding anything. I would like to verify some of the claims being made in the other comments (it's hard to tell if someone's code is better or worse relative to another person's without having access to the code and comparing important metrics and all that.)
I agree. His negativity has probably detracted quite a few people from him that otherwise are quite aligned. Still, his historical remark is rather peculiar.<p>As for the language, yes, sadly, it’s with us seemingly to stay. I code it professionally and I can’t find a single interesting, or even good, thing about it. Apart from wide adoption of course. Everything about it feels extremely badly designed from the user perspective (though it’s probably technically very impressive) with many details, that probably the sanest strategy is to use a small subset of the language. At least I don’t have to use STL at work, that’s something positive, I guess :)
> You can argue that the committee route is not the best, but C++ is here to stay and by some metrics adoption is actually growing.<p>You can argue that chemical companies route is not the best, but cancer is here to stay and by some metrics adoption is actually growing.
Casey also got less aggressive when talking about Stroupstrup lately, especially after his last talk at Better software conference, where he mentioned him multiple times with a lot more historical context.