Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 i have been thinking about dijkstra’s comments regarding complex languages. I use cpp because it makes things easier like generic programming and abstracting away lots of complexity to clearly express your ideas without loosing performance, but he obviously was onto something when he was in for simpler languages, and I think everyone would prefer a magical simple language like scheme but expressive as hell. Maybe we are too far away from that, hopefully not by hundreds of years.
I have literally dreamed of this exact idea. I'm so amped at the prospect of this becoming real. 🤞 Herb Sutter, as always, proves that he deserves our respect.
Funny how he does everything the C. Muratori/J. Blow crowd is advocating, even to the point where he didn't add classes in his transpiler yet. But watch how they still sh!t all over cpp2 no matter what...
@@llothar68 unless I'm misunderstanding what you're saying, we have? Since c++11 we've had std::codecvt specialisations that convert to and from UTF-8 explicitly, and we also have the null terminated multibyte stings library which while not explicitly UTF-8 is effectively always going to be because that's just the most common multibyte encoding in use
@@llothar68 Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
Ever since I saw that one talk by Herb on an actual good way of passing arguments, that talk never left me as I thought about it again and again, and now I can't describe how happy I am to see Herb still keep actively pushing C++ towards this direction of simplifying it. I even shed a tear at some point watching the talk and I believe it means a lot to the whole C++ community as it does to me, so I just wanna say thank you a million to Herb for doing this fascinating job of actively and sincerely trying to make our world better
@kodirovsshik Thank you for the kind words, I'm glad you find it a promising direction! @@domenicocipriani604 @loarto You can find the parameter passing (arguments) in the second half of my CppCon 2020 talk... the links are here: github.com/hsutter/cppfront#2020-parameter-passing
It's more opinionated (by one person) and farther along, and it does speaks to me. But carbon could become good too, we just don't know yet afaik. These initiatives do illustrate that ppl want something breaking from C++ if 2 such similar (popular) initiatives exist (and probably others like Circle).
Carbon did the important task of breaking from the crowd and saying, yes, it is time for a new language to supplant C++ and it needs to come out of the C++ community itself so that the concerns that the community cares about in a language are addressed
@@frydac Well, Carbon makes it easier to highlight (or just find by eye) symbol declarations. Herb promises that he can write a context-free grammar, but it's fragile and any future change has to be careful not to make the parsing more complex. With keyword-first principle, we guarantee the grammar will be (and stay) simple in this respect.
Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 It's a language that is designed by starting with a practical but very limiting in design terms premise - take C and make it more expressive and more useful while keeping it seamless. But it's also exactly what allowed it become so successful. You can't blame the designer for doing what had to be done. For competition there was ObjC but the performance was not great, turns out gluing Smalltalk to C you get the drawbacks of both. C++ manages to be more than the sum of parts, which is not so trivial, and the better designed languages heavily lean on hindsight experience of C++. Wirth designed languages, where are they now? They've never been flawless either. The language grew unwieldy at the stage when it was already being designed by committee, so blaming it on one guy is a little silly. Something as important as C++ emerges, you simply don't get to keep dictatorship over it.
This is exactly what we need in the world. I started learning Rust because of the amount of work I'd need to do to go from "my code compiles" through to "and now it's not a pending lawsuit". Rust is not for everyone, so I'm really happy to see C++ moving towards a world where it catches up to (and hopefully exceeds!) Rust's ergonomics and safety.
Rust is a moronic language. If you're thing is safety, WHY THE HELL WOULD ALLOW SOMETHING LIKE THE UNSAFE COMMAND? All the problems (and benefits) of C++ is how many features there are and how there's always a way around their restrictions. Why move from a language that allows anything to a language that allows anything.................with far less libraries. Rust hasn't solved anything. Also ergonomics is super relative.
@@robrick9361The whole point of unsafe is to isolate essential but uncheckable low level operations to compartmentalized blocks that can be more easily reasoned about and verified by hand (functions, modules). Good C++ design already follows the same principle (References/Smart pointers vs pointers, Range for vs raw for, collections vs raw new/delete). The only difference is that Rust has stronger compile time checking to enforce this compartmentalization. As for ergonomics, while it is true that it is partially determined by preference/experience, there are objectively more ergonomic ways of programming, otherwise we would all still be using assembly. Rust does have features that make it easier to express your intent than C++, such as sum types with pattern matching. And as for solving no issues, you should go ask Google, who have observed a staggering reduction in memory safety violations in the parts of Android that have been written in Rust, or Microsoft, who are investing heavily in Rust support for Windows, or Mozilla, who's multi-threaded CSS renderer project failed multiple times before they successfully reimplemented it in Rust, that "Rust solves nothing". I'm sure they will find it very amusing.
@@robrick9361 Because rust got it's start on LLVM which needs interop with C. Even then, you have to explictly go out of your way to make "unsafe" Rust code. You're so hyperfocused on a "GOTCHA" that you missed the fact Rust has a way better toolchain than cpp. Better package manager, better syntax, Composition over inheritance, the list goes on.
Very nicely done, Herb! This approach not only bypasses the backwards-compatible limitations baked into C++ while still allowing mixing code, but keeps the language feeling like a refreshed C++ instead of something completely new. I think this compromise will be a appealing to many C++ developers. I think Rust is an excellent alternative to C++ (and is available today) but comes at the cost of learning a different way of thinking about memory safety and interoperability headaches with C++. Carbon is another experimental language trying to overcome these issues with a new language that prioritizes compatibility but is not familiar to those coming from C++. I suspect cppfront will be an easier sell to those currently heavily-invested in C++ but want more simplicity and safety guarantees.
Even a luminary like Scott Meyers had lost hope years ago. In his last few public talks back in 2017 (that are available on his website), it's very clear that he had enough. In one of his talks (at Dconf), he said that he was still taking engagement talks as long as it wasn't about C++, and that the C++ design committee didn't really care about the creeping complexity. I think that one is a bit harsh but it speaks volume as what he thought about the evolution of the language. Herb's experiment is a stroke of genius, as it is both the disruption that is needed and the continuity and back compatibility that is a requirement.
With committee that is so focused on backward compatibility, there won't be any progress in C++. It needs a serious redesign. Like a dozen or so new keywords and removal of non-intuitive bits like initializer lists. Templates need a serious redesign to be more readable. And so on. It needs a massive purge to be a better language.
This is not just a fascinating idea/experiment, but may even fall into the "essential for continued language evolution" category! I really hope it succeeds
I think C++ is on life support. Hardware is at the point where you can create GUI apps (yes, I know C++ is a systems programming language) much more rapidly in other languages and still have acceptable performance, than you ever could with C++. That it's still difficult for beginners to the language to install and link to GUI frameworks/libraries in C++, is a real hindrance.
@@mx2000 Rich client apps are not on the way out. Only the ones which require no computational power. That's a good chunk of them, but certainly not all. What I like about that is that you can install Linux on someone's computer and he won't be able to tell the difference if he's a office / web user.
@@atlantic_love C++ is a mess, programming language without any idea expressed with good design, see the list of wishes from Stroustrop books where Stroustroup listed some items for himself about what the language needs to be like.
@@atlantic_love Yes but when you have large data sets you have a good C++ optimization and memory control. Performance is still king and never fast enough.
This is super exciting. I'm a Rust engineer & I love Rust, but I would also love to see C++ become modern & safe so that we can all build better software with less headaches.
Wow, I didn't realize there would be cameras on the mic stands! Super glad I was able to twist Matt's arm into hacking support into Compiler Explorer before the talk was over - your reaction was priceless 😄. Thanks for a great closing keynote as always.
It's great that Herb is doing this. I am designing a way to do this in C, but once it's done, no one will know or care about it except for me. When Herb is done, it has a good chance of actually going somewhere. Even if not in the standard, there's no way it doesn't get a community behind it after this talk...
I'm amazed that Herb Sutter after so many years is still going strong, still is thinking cogently, and even looking much younger than his years. Kudos.
I love this. It definately took a rust-like approach to compiler warnings / errors, which is great. Not only are the messages clear and they tell you how you can fix your mistake, but it also helps keep safety within c++ programs. I also enjoy some of the "syntactic sugar" resembilng some of the newer programming languages. I also never knew about the whole NSA ordeal with type unsafety and them advising against c & c++. Thousand Thanks to Herb Sutter And cppcon
Amazing work Herb. I now again have hope for C++'s future. Also, very good point in the end about naming the syntax cpp2 explicitly. Human nature is one of the reasons there is still so much confusion about the language.
This is literally like a dream come true. More than once I've written fake cpp code in an empty editor just to imagine what a unified function syntax would be like, what a unified paramter passing paradigm would be like without all the const ref crap. There is an echo in my soul that this just makes so much sense, and I beleive it is a common feeling among many cpp coders. Yet cpp toolchain always felt like a behemonth that's too big and too complicated for a lone developer to tackle on. So a great many lone developers are left to just imagine what's possible. It really need someone like Sutter to push this venture. Please make this happen. Sutter is like jesus reborn for cpp.
I cannot describe how much I loved every single part of it, only then to be crushed how literal perfection is gonna be stained by (1:24:55) the confusion that is gonna be caused by an empty return in the function that is supposed to return certain values (though, to be fair, it’s gonna be so freaking convenient at avoiding the little annoyance of repeating the structure shape, that I’m gonna use it anyway. Just like I use the ternary operator where it completely screws the code readability)
I have been ranting for years why C style arrays and pointer decay kills the consistent value semantics of C++ This idea of doing away with pointer arithmetic is absolutely the best thing. Also uniform syntax!!!
It's been a long time I've done c++, but that got my attention back. I could imagine something like this being the default and you can enter "unsafe mode" like in other languages for the "old" c++ style.
That's just a fantastic idea! As Herb said, he wants to teach people more about how to program instead of the details of C++. So and I want to program more instead of learning about quirks of particular syntax/semantics of C++. Herb, you have full support of the random dude from the internet!
Fantastic, I don't need backwards compatibly for my green fields programs. And I may not need to learn TS, if this can run in the browser with decent screen IO. :) Thanks to Herb for his long term efforts.
Onece I'm finished my thesis, I'm going to start working on LSP and treesitter for this (with Neovim support in mind). If this reaches escape velocity, it's going to be huge. A transpiler isn't as exciting as something like Carbon, but I think this is the right increment to move forward.
I wouldn't call that mess of Carbon exciting... Carbon was the main reason why it took me so long to view this video and take it seriously. Carbon from where I stand seems more like a disease while such project finally feels like a benefit to both C++ and programming in general. I'd love to see your transpiler in action but please don't ever implement yet-another-useless-new-language-that-should-stay-in-the-lab-and-instead-extend-C++-with-its-one-trick-pony-feature.
@@DerDoMeN Thanks for your comment. Just for clarity, when I was mentioning a “transpiler”, I meant Herb's. It seems to me that `cppfront` is (right now) a transpiler from Herb's Syntax 2 to ISO C++ and STL + cpp2. I was only talking about implementing some tools (a language server and treesitter support) for it.
How about cppfront being a compiler flag for GCC or clang or MSVC, similar to "-std=c++XX" ? Then potentially it would feel like a built-in part of the language. And since parsers are generated anyways, we could easily go from [Cpp2->Cpp->IL] to [Cpp2->IL]. The solution cannot possibly be to kill C++ by creating a new language, as that does not solve any existing problems but potentially creates several new ones. And C++ is too complicated for practicality in the future. Anyone who would do the same research that Herb Sutter has done, would likely arrive at the same conclusion (or a very similar one).
@@007LvB think the other way around, that's exactly cpp2. With cppfront, you can either write in pure cpp2 or mixed cpp1 and cpp2 and as time goes by, there def would be support for more things
I've been avoiding C++ in projects because of all the complexity and the chances to fail miserably. But this looks pretty good! I have one important question though: Why not `const` as the default for everything everywhere? I am a firm believer in "the laziest solution should be the best", so adding sth like an explicit `mut` instead of `const` would fit that paradigm.
I agree, many people have the sentiment that mutable by default was a mis step, but to correct it now would break the world. However with cpp2 that isn't a concern anymore. It could even be a flag if there was any strong pushback against it.
@@Firestar-rm8df A flag would mean you can't look at the code in isolation and figure out the meaning. Flags shouldn't be able to change semantics like that, I'd say.
@@Adowrath There are already plenty of compiler flags that can change behavior. and preprocessor macros. That's why flags and build scripts are often checked into your repo with the source code as it is a part of your code, just at a higher level of abstraction. -fno-strict-aliasing for example. I'm not saying this is a good thing, I'm saying this is how it is and we wouldn't be any worse off, and having the flag you can set is better than requiring everything to be mutable by default. Also, I imagine you would likely get a compile error if you toggled the flag for a code base erroneously as const-incorrectness simply doesn't compile, which is the beauty of const.
@@indiesigi7807 do you know anything about clean code? You should const everything, and having it as the default is even better. An optimal program would be completely made up of constexpr statements, so that only the I/O is not const
Liked most of it. Not sure why everyone wants “name: type” syntax in all these newer languages. I frankly find it less readable than what we currently do,especially for any kind of chained logic like assigning from a function return. Also, having lots more keywords and punctuation would make the resulting c++2 MORE legible and simple, not less. Just imagine using the functional keywords “pack()” and “unpack()” instead of all the magic “…” for packs of types, fold expressions, etc. Notice that the best improvements come when Herb introduces a few keywords and all sorts of old BS goes away: “in”, “out”, “inout”, “is”, “as”, etc. Others I’d propose are: move: Have a keyword to do moves, demand move semantics (e.g. a specialization of “in”). No more && junk. pack(), unpack(), type, types: Replace all the BS with ellipsis to handle list of types, packs of types, decltype, etc. Would transparently add support for having named sets of types in general contexts. Reflect(), reify(): reflection with a readable syntax. One thing I’d argue strongly against is making supposedly “unnecessary” punctuation optional. There’s a reason human language evolved in the OPPOSITE direction. Down that road is things like Python where you end up with pathologies like whitespaces determining scope.
Yes - programs are WRITTEN AND READ BY HUMANS. A "std::reflect( ).getMembers()" is a lot easier to understand, read and write than " meta = ^[...[::]...]". keywords are not out enemies - esoteric operators and the reliance on templates is.
I also think "int x" is easier to both read and write than "x: int". And that was one of the first things that bothered me. I'm sure H.S. has some good arguments about that, though. But we will see. There are as many different features in C++ as there are differences in what C++ programmers prefer. This feels like the right initiative to pursue for the community, but most of it will probably be some sort of democratic mess anyways.
The parameter passing syntax looks like it would be non-trivial to learn and therefore may impede the adoption of cpp2 if it is implemented as shown in this talk. GC, if added, will probably lead to fatal fragmentation of the community, as it did with D, because half of the community will just switch it off. This whole proposal in general is great as an improvement to teaching, learning and safely using of C++. One other problem I see is that it is not a huge immediate improvement in most C++ use cases, so bottom-up adoption may be slow.
I don't think it's that complicated to teach primarily because the default (in) is the right answer 75% of the time, and when it's not it's obviously not, and inout is the answer.
I love the syntax of cpp2. And loving the all the features of herb trying to make, light weight exception, static reflection, metaclass, gc support. It will kill C++ dialects like UE C++ and QT C++ which is amazing. But something I miss is that some kind of ambition that make people thrills. I really wish that circle, carbon, val and cpp2 get marry somehow. We need better mechanics for meta programming. We need better approach that make evolution process faster. We need compile-time memory safety built-in to the language. We, C++ programmers need some features that make us claim proudly that we are at front of PL rather than C++ won't die because of backward compatibility.
It is not going to kill UE C++, the reason UE CPP exists is because it is tightly integrated to UE's Blueprint system. It does more than just making CPP safer. That being said, It would go a long way on making UE CPP simpler. So end result would be something like UE CPP2 where you still have Blueprint extensions but built on top of CPP2 instead
I didn't run of to a different language, I came in as a compiled language newcommer and chose rust, partly because C++ just appeared bloated, with a lot of "Yes, this is the most straight-forward way, but it's unsafe and we don't do that anymore", and no consensus as to what current best practice even is. I wish this project the best of luck :)
When Herb put C# handle allocation into a dialect of C++ (gc_arena, 2016), I thought "what a waste" . Making gc.new available is the appropriate place, the C++ place, to put this kind of compatibility. You can still have full cpp2-like syntax whether you must run in CLR or not. I saw gc_arena on an early slide and wondered how much time was going to be wasted there. Answer: NONE! As soon as he talked about allocating memory on the stack, on the heap, wherever, I realized that he'd arrived at an answer to this that anyone, even a curmudgeon like me, could be delighted at. Good Job, Herb. I've also been bounds-check resistant because -- well, short answer is, the last time this was a flaming conversation for me was in the 90s, before Moore's Law had done most of what it could to processor speed. I saw code-bloat and exec time grind-down in that direction. Having cpp2 do it naturally, natively like that (post-[size]Moore, too) is DEFINITELY a step in the right direction. And even from outside the US, we have to take "Wherever possible, do not use memory-unsafe languages" really, really, seriously. This is a way to do that. I want to be HAPPY to write C++ for a long time yet and cpp2 may be the best way forward. (see 40'00 - 45'00) okay, I'm a full-on C#/.NET hater.Hate on me for it. I think I have valid reasons but I acknowledge that there is lots of good code -- e.g. Zachtronics -- written in C#. This is not the place for those reasons.
Thanks for providing this talk! He already had me at nodiscard is a default. I think this experiment will decide about the future of C++. It has reached a level of complexity with a bunch of optional but actually essential rules to follow, that makes it unappealing to work with. Especially if you compare it to younger languages with all these features baked into the language standard. I hope this will bring C++ to a state of the art level.
I have been on a "Rewrite it in Rust" path for the past few years, and am down to one last rather large C++ project that I was wondering if I should rewrite as well. Recently I decided to finally take the plunge, but this talk made me rethink it. I'll leave it C++ for now and see how cppfront develops. The cppfront code is surprisingly small, considering what it can do -- Herb managed do a lot with relatively little code. I'm cautiously optimistic!
I love rust grammar. Don't get me wrong. However instead of transpiling, why we can't simply deprecate all those dangerous sharp edges (malloc, allocating new, union, unboundchecked accesses) that now c++ already has safer alternatives then just remove or internalise/classical-mode them. If the *actual* problem is today people still *keep* using them as before. Why won't c++ just stop them from using those?
I worked for a company that built a front for a second language, and used Prolog to write this. Prolog was very powerful for this purpose (perhaps not that fast, though).
I don't understand why people rave about this presentation. The problems described don't require new (ugly) syntax or compiler to be solved, we just need to improve current compilers. The real problem in cpp is that with every new feature it forces you to go templates which really hard to debug
Templates can be arcane, that's true. But a lot of the problems with C++ are around things like defaults, where we have to teach people to overcome language defaults that are often wrong, and it's not possible to change defaults because any change would be a massive break. For example, we teach people to be careful about the compiler-generated special class functions that are generated silently by default and that are dangerous for many classes, and to remember to suppress those when they're often wrong... but we can't change the language to not generate them because that would break all the classes that rely on them, we can only do that if we have a second syntax that is not in use today. Another set of problem is around where the language just has multiple divergent ways to do the same thing in different places, and we can't really fix that without unifying those ways. I have one suggestion: Would you please check out slide 95 at 1:39:00 and see if that list might be more persuasive regarding the amount of arcana we have to deal with in today's C++? If we can remove that 'accidental complexity' that isn't core to the language's value, I think we should try. $0.02!
@@herbsutter4340 You don't need another compiler or syntaxes. You just need additional flags and checks for current compilers. Then it is the same: if you want it - you use it.
@@fareloz I'd love that to be true. It needs more than assertion that it's possible though... a lot of smart language experts and tool developers have been trying that path for years. But perhaps you're right that there's something they've missed -- I welcome the detailed proposal and the working tool or prototype to try out, that demonstrates how it can be achieved in an adoptable way (tools for today's syntax that are efficient and noise-free enough for everyone to be able to turn on at build time) and also achieve the same goal (at least of reducing what we have to know/teach by 90%, and reduce CVEs by 98%... it can't make C++ 10% the cost to write tools for but I'd be happy just to get the first two if it's practically possible despite experience so far).
@@herbsutter4340 There are many caveats which compilers warning about already: usage if initialized variable or dereferencing of null pointer, usage of moved object and many other. You can always force this warnings to be an error. [[nodiscard]] can be added implicitly too by the compiler. Maybe I miss something from the talk (or just simply don't understand), but I don't why I need another layer for this.
cpp2 -> cpp1 -> c -> assembly Sounds like a great idea, 10 years down the line, cpp3 -> cpp2 The problem is maintaining back compatibility and it's always going to f@ck things up. Always, rust works so well because it is not designed to interop with c, yes it can but that's additional, not the core part.
I'm not convinced a systems level language should force smart pointers or particular trendy abstractions. For example, pointer manipulation is essential. There's too much handwaving in the answer to that question that was asked at the end. Maybe this is the direction of evolution of C++, but then it won't be C++ anymore. For me, C++ is the language I go to for maximum computing efficiency. This seems to be an example of the age-old tension in language design: Some people want a safe, productive language that is nice to use, but many want a useful language that can get out of their way when they program at a low level. Personally, I think that the safety features should be left to tools, and the language should be kept as simple and as unlimited/expressive as possible.
From a point of security, it actually makes a lot of sense for a systems language to enforce pointer safety. You gain more by having an extra indirection (which is not always used, as in the case where shared_ptr is passed as const&), than by risking a lot of security vulnerabilities. Our processors are quite a bit more powerful today than they were 20 years ago, and this question is less important today. The only place where this has some merit is in strict realtime applications, and even there we don't always want to manage everything. In my own opinion, safety is more important than speed. But we can test for safety and then disable those tests later with some compiler optimizations and flags. Besides, we also need to educate programmers as better programming practices evolve. Just as we did with goto, now it is happening with the preprocessor.
I read an article recently encouraging people to leave C++ for "safer" languages like Rust or C# but this talk shows C++ has the potential to reinvent itself to be a safe language. I'm excited for the eventual reincarnation of CPP2 to become a part of standard C++ in the future.
I wonder what’s left for memory safety after getting rid of nulls and pointer arithmetic? Ie, with those out of the way, why isn’t it 100% memory-safe?
36:30 Calling free functions with object syntax is very good, too. C# extension methods. This is very good not only from the toolability perspective, this is also good to better follow single responsibility principle: we shouldn't define draw and save functions inside the classes, but ability to call object.draw() is very nice.
44:38 The problem is simple to solve. Refrigerator, vacuum cleaner, iron, coffee machine and TV have no place in the Internet, and any network at all. Maybe TV, when user explicitely allows it to do so.
Herb has one of those beautiful brains that thinks incredible things and also has enough horsepower left over to explain it in a digestible way. I loved this idea so much. The semantics looks very simiar to object pascal, without the ugly verbosity. I wonder what anders hejlsberg would think about it.
TLDW: The answer is yes... if you write a new language and pretend it's still C++ by importing some of its baggage (the standard library, external build systems, exceptions, etc.) It's a lot like trying to keep a band name when the lead singer leaves. I'm not against this though, since it's about time C++ apologizes to its users by taking some time to help migrate and improve existing codebases that aren't getting ported to a new language for some time (if ever), even if a compelling replacement comes out.
I have done some research on C++20 modules, and it's so good to see them being incorporated in the standard now. However, there are some very fundamental problems that need to be addressed: Each time we compile a project, we need to scan all project files and construct a DAG dependency structure and compile the source files in order. EVERY TIME! I really want to see Cpp2 address this. Because it's a pain for tool developers and the main reason why module support is coming so slowly. A good paper "Remember the Fortran" (p1300) describes in detail what the problems are. Because of the precompiler Cpp cannot easily overcome this problem. But maybe Cpp2 can?
I bet the majority of C++ programmers already had this kind of dream for so long already. Yes, carbon seems to be promising, but imagine C++ moving towards the direction of this talk!
I see the value of this for C++ programmers, but I wonder what the experience (say 5 years from now if this is stable) for people who don't understand the generated code? Will the semantics stand on their own without contextualization with existing cpp jargon? Very interesting indeed.
@@BryonLape That is probably one of H.S.'s largest motivators? C++ should be a syntactically and semantically simple language that is easier to teach and learn. Bjarne Stroustrup seems to share this sentiment.
Hits so hard. Imho this seems to be the path forward to keep our hands on the full power of C++ while getting more compiler-driven safety with least friction.
The way I solved this problem with Script2 (Serial Chinese Room Interprocess and Telemetry Script) was I didn't use the std library and I instead wrote everything by hand using contiguous Automaton SCII data types that auto-grow from stack to heap. I use a single translation unit that can compile all the code in seconds. You really don't need to use multiple translation units until you're trying to complete many huge libraries in parallel using one translation unit per library.
imho, C++20 syntax is near-perfect. Just deprecate the ridiculous standard library and build a new one from scratch. Learning from libraries in newer languages might be a good idea.
All this work is - if looking at it from a birds eye point of view - still follow up cost of the fact, that C was/is used. C++ needed to be C compatible and hence inherited C quirks. Now someone tries to improve on that by creating another evolution of the "We want a better C". In the meantime, the people creating Zig do literally the same, but on a C level. "We want C without its mine fields". And in the next room, the Rust people try to "solve the problem" with some clean room approach, starting from scratch. Now I am not a fan of many aspects of Rust, and I used C++ for a few decades. But the whole ecosystem is toxic. "Dumbed down standards" of C++ and C show that (MISRA). Add to all that the costs incurred by the necessity to do "language xy bindings for some C/C++ library" and you see how insane the whole thing is and has been for nearly 30 years. The problem is IMHO not a language problem in the first place. It is an ABI problem. If someone were to define a "modern ABI", all languages (and OS) could easily support, all that backwards compatibility to C jazz would become obsolete. C would have to innovate (and support the standard ABI) in order to play nicely with others and in the long run, the whole community would no longer be held hostage to that terrible heritage of C. Oh yes - the "There is no C++ ABI" adds to the problem further. And adds costs, spent for people writing C facades for C++ libraries, so they can be used by the foreign function interface of other languages. The whole thing is madness. And we are just too neck deep into it all for way too long to see it. I see Rust as an honorable attempt to break out of that vicious cycle. But I think it is but a stepping stone and the future will bring a systems programming language, which is not such a diva as rust, but actually fun to use and equally safe. Cpp2, in contrast is a workaround of a workaround and as such, maybe practical but not really solving the root problem.
What Herb is proposing here is not making C++ more user-friendly, nor faster or simpler - this is proposing a new language and claiming it to be C++. and that with some of the worse things we have seen from other languages like more abstract syntax, more strange use of symbols ( I could understand using '_' as a placeholder 30 years ago but we are no longer limited to teletypers), 1 syntax but with 2 styles (so yes - 2 different syntax). Many developers have complaints about C++ but this is like saying Rust is C++ just cause it could be translated to C++.
I don't think it's a matter of improvement, it's a matter of survival. When there is a guideline telling you to stop using C++ then it's not up to you anymore. When your company says that we have to change language because otherwise our software will be labelled as 'unsafe' because C++ is in a list of unsafe languages what will you do?
re: around 1:04:00, if the bounds checking assert_in_bounds is applied to on any stl container with integral subscripts and a .size function, how does it behave with something like map? If I have a map mymap with 3 ints 5, 7, 143 as keys, then mymap[143] is fine, but way beyond the size of the map. (Also, I really like the cpp2 idea. This could be just what we need to clean up the language)
18:55 I was thinking the same, Herb. The *void f(int i) {* syntax is usable, I don't like the *auto f(int i) -> string {* syntax, because it's more text and you have return type written in 2 places. The *f: (i: int) -> string = {* is alright. What I'd also add is the ability to declare a variable of that type to return it: *f: (i: int) -> ComputedText: string{""} = { return Text; };* Why? Because it makes the code clearer: the code explains what it does. Right now you only see the type, like a string, but you don't actually see what exactly the string returns. Like, for example, sometimes it returns an int. Now I have to go and look up the documentation or read the source: does it return an error code, number of bytes processed, or something else?
Thanks! Belated answer: Yes, Cpp2 also has multiple/named return values. You can write your example like this: f: (i: int) -> (computed_text: std::string = "") = { computed_text = Text; } or better still, avoid the extra step of initializing the return value to "" only to overwrite it, like the following where the string is constructed directly from Text: f: (i: int) -> (computed_text: std::string) = { computed_text = Text; /*now a constructor call*/ } Finally, note that there is an implicit "return;" at the end of the function body, and if you want an early return you write just "return;". It's not "return computed_text;" because we already know what the return values' names are, and they were already set, so all you need is "okay function, now 'return;;".
@@herbsutter4340 Thank you for the answer. I'm thinking of trying it out for one of my personal CMake projects: it's a DLL mod for a game in C++ on Windows.
I'd like to add to the "this is just an experiment, it might fall" idea - even if it fails, it can generate value, bring something new or expand our knowledge - I think this is valuable either way. Then it would be probably of even more value if the decisions that were made were documented, so that someone could build on top of it. But that would probably pile up the work required
I think what wasn't clear in the talk about nullptr is that it's better to have compiler support for knowing a variable is uninitialized then to initialize it to something utterly useless. I'd like to see that generalized to any type, marking whether I want the default constructor or leave it uninitialized, and give the compiler freedom to elide the default constructor when it's capable of tracking definite first use.
I'm not sure if there's much meaning to the fact, but with Cpp2 you can (or should be able to?) do main: () -> int = { std::println("Hello, World!"); } which is the first time we've had the ability to write that on one line to the best of my knowledge. No #include needed, not even an import, just code.
Personally hate the use of underscore as a type placeholder. Would much prefer a keywork like auto or even var. Also dislike much of the departure from C syntax for control flow statements. Obviously C can be improved but everyone already knows and understands C so every difference is just one more thing someone has to learn, so why not minimize that rather than indulging yourself with your personal preferences.
It's almost adorable to hear Herb talk about context-free grammar. The JS language community has been using transpilers to prototype language evolutions for 10+ years now. And while the result isn't throwing out context-free grammar let's just say a certain amount of hacking happens at the lexical stage, and we don't always fully validate the AST when building it at initial parse time. Everyone loves context-free grammar until their favorite time-saving syntax extension violates it, then it becomes a tedious game of how can I hack the lexical scanner to look forward and insert special tokens, can I move some syntactic validation to after parsing ends, etc.
This really reminds me of how refreshing it is using the Burst compiler in Unity. Small bubble of "new c#" that is isolated and allows you to really claw back the performance where it matters.
I really want this to work as intended, but I start to have a sinking feeling right around 1:45:30 when Herb tries to reassure me that I can still use union with it if I want. Am I misinterpreting this? Because to me it sounds like Herb is trying to say you could always just mix and mash cpp1 and cpp2, just like you could always mix and mash c with cpp1, without any barriers or demarcation. I get that the prototype uses a transpiler, that's great that it makes it easy to prototype, and backwards compatibility with cpp1 is a side effect that is supported by that transpiler, but I'm thinking about how cpp2 would be implemented long term. Maybe it was a mistake to implement c++ using cfront - it just led to to the mindset that the language was an extension, when perhaps it would have served better as a clean break. Maybe now that mistake has reached a tipping point, only now we are repeating the same mistake by implementing another transpiler? Consider a dystopia: the year is 2050, Rust and Go are long dead - cpp2 stole all their market share since everyone thought that was the quick fix. However everyone still predominantly works with a bunch of broken legacy cpp1 code. The only difference now is that the resulting hybrid cpp1/cpp2 language is even more complicated than it was before, since alongside all the C++ sublanguages that existed circa 2022 (legacy C, macros, stl, template metaprogramming), there is now also the cpp2 sublanguage, which is so complex that it was designed to subsume all functionality from every other sublanguage. The language developers only served as the enablers to a stunted userbase. It's 2050 and no one ever bothered to implement any clean keyword demarcation or file type extension that could have helped tooling developers to make out what code is cpp1 vs cpp2. No one ever bothered to implement constraints that would have helped to coalesce the ecosystem towards cpp2 to the point where compilers could drop support for cpp1 and relegate it to special purpose compilers. No one ever even bothered to make the "-p" flag a default, and as far as that goes, the language still manages to get the default wrong by default. Backwards compatibility is so entrenched an idea that even when people want desperately to break from it they still find themselves clawing their way back to it. It's 2050 and all the compilers still have to support cpp1, and all the tooling has to work around a minefield of cpp1 code whose grammar is so complex they could never hope to support it without the backing of a major software company. I know we really want to avoid another Python 2->3 debacle, but the fact remains that Python made it through that migration no less popular for it and something was gained from it. And that isn't the only example. Fortran 77->90 comes readily to mind here - just as with pointer-arithmetic and memory-leaks-by-default, you have to admit it is a pretty stupid thing to say that type is assigned based on the first character of your variable names, and sometimes you just have to have the courage to admit that it was a stupid idea and make a clean break from it. Other times, just as when C made a clean break from Fortran, the resulting language is less performant. You just have to accept that some people will never change, they will always want their unions simply because that's faster, and to them you have to ask, "why aren't you using Fortran?"
This is nicely written! But I think it's still better than the alternative where everyone switches to Rust, and there will be no developers left to maintain the billions of lines of C++ that makes the entire world work. Dijkstra taught us to avoid goto, and so we don't use it even though our languages still allow it. If we adopt a rule of using Cpp1 to maintain legacy code and Cpp2 to extend it (open/closed principle), then we should see a gradual transition away from Cpp1 coding, resulting in a better world. Even though I understand (and actually appreciate) your sentiment, I think it's important to stay hopeful and optimistic - because that inspires people to solve problems. As long as there exists a healthy scepticism, which is abundantly present in the C++ community.
When you mentioned the intellisense, I know this is destined to succeed. Cpp is so special that cpp programmers are not physically possible to remember all the tools they have to use, simply because the tools are too many. The only possible way for cpp or any high performance container language to work is to utilize the auto completion to the extreme. Also, 2 details I would like to mention. I think I mentioned them in carbon's discussion page. 1, since you already made the rich ast to iso cpp code translation, I think it should not be too hard for you to make rich ast to cpp2 translation. When a break update happens, people can use this feature to get code on new version. Then, no tech debt any more. 2, macro is still something necessary in even cpp23. If a tool needs some init function for all the classes even for user defined classes, the only way maybe a customized parse tool, and the dev have to tell people to include some weird header in their cpp file. The parser generates the placeholder header. After all these work, it's time to compile. say, class A{...} initializes with a init(...) function. But if you don't want the users to write this for all the new classes, this trick kicks in. The result looks like: #include "some auto generated header.h" class A{...} I don't how to solve this, maybe meta programming.
Matt Godbolt is such a legend, adding support for cpp2 to compiler explorer during the talk.
1:43:38
Having such simple compiling instructions definitely helped, imagine if it had a bunch of dependencies, that wouldn't have been possible.
Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 i have been thinking about dijkstra’s comments regarding complex languages. I use cpp because it makes things easier like generic programming and abstracting away lots of complexity to clearly express your ideas without loosing performance, but he obviously was onto something when he was in for simpler languages, and I think everyone would prefer a magical simple language like scheme but expressive as hell. Maybe we are too far away from that, hopefully not by hundreds of years.
@@josephlagrange9531so you're a good designer huh
I have literally dreamed of this exact idea. I'm so amped at the prospect of this becoming real. 🤞
Herb Sutter, as always, proves that he deserves our respect.
If you know the C++ Comittee you know it will not become real before it's too late. It's 2022 and we still have no UTF-8 charset conversion handling.
Funny how he does everything the C. Muratori/J. Blow crowd is advocating, even to the point where he didn't add classes in his transpiler yet. But watch how they still sh!t all over cpp2 no matter what...
@@llothar68 unless I'm misunderstanding what you're saying, we have? Since c++11 we've had std::codecvt specialisations that convert to and from UTF-8 explicitly, and we also have the null terminated multibyte stings library which while not explicitly UTF-8 is effectively always going to be because that's just the most common multibyte encoding in use
@@llothar68 Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 Why copy-paste your comment all over?
Ever since I saw that one talk by Herb on an actual good way of passing arguments, that talk never left me as I thought about it again and again, and now I can't describe how happy I am to see Herb still keep actively pushing C++ towards this direction of simplifying it. I even shed a tear at some point watching the talk and I believe it means a lot to the whole C++ community as it does to me, so I just wanna say thank you a million to Herb for doing this fascinating job of actively and sincerely trying to make our world better
Link to talk?
Which is the talk about a good way of passing arguments?
@kodirovsshik Thank you for the kind words, I'm glad you find it a promising direction!
@@domenicocipriani604 @loarto You can find the parameter passing (arguments) in the second half of my CppCon 2020 talk... the links are here: github.com/hsutter/cppfront#2020-parameter-passing
@@loarto ua-cam.com/video/6lurOCdaj0Y/v-deo.html
This is the first "alternative" I've wanted to learn. Thank you for the dream of a better, way less complicated future.
Glad you like it!
This is soooo much more promising than Carbon IMO!
It's more opinionated (by one person) and farther along, and it does speaks to me. But carbon could become good too, we just don't know yet afaik.
These initiatives do illustrate that ppl want something breaking from C++ if 2 such similar (popular) initiatives exist (and probably others like Circle).
Carbon did the important task of breaking from the crowd and saying, yes, it is time for a new language to supplant C++
and it needs to come out of the C++ community itself so that the concerns that the community cares about in a language are addressed
I think Carbon borrows some good concepts from Go, while throwing away the garbage.
@@frydac dont forget, its made by google. They might kill it at any time if it does not seem profitable.
@@frydac Well, Carbon makes it easier to highlight (or just find by eye) symbol declarations. Herb promises that he can write a context-free grammar, but it's fragile and any future change has to be careful not to make the parsing more complex. With keyword-first principle, we guarantee the grammar will be (and stay) simple in this respect.
Finally, after YEARS of warmup, Herb Sutter finally says it: if C++ is so good, why isn't there a C++ 2?
Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531so you're a good designer huh
@@josephlagrange9531 It's a language that is designed by starting with a practical but very limiting in design terms premise - take C and make it more expressive and more useful while keeping it seamless. But it's also exactly what allowed it become so successful. You can't blame the designer for doing what had to be done.
For competition there was ObjC but the performance was not great, turns out gluing Smalltalk to C you get the drawbacks of both. C++ manages to be more than the sum of parts, which is not so trivial, and the better designed languages heavily lean on hindsight experience of C++.
Wirth designed languages, where are they now? They've never been flawless either.
The language grew unwieldy at the stage when it was already being designed by committee, so blaming it on one guy is a little silly. Something as important as C++ emerges, you simply don't get to keep dictatorship over it.
@@ryleitdept i would be inclined to believe that a random stranger on the internet could design a better language than c++
@@ryleitdept No, he doesn't have to be. You don't have to be a good film creator to be able to tell if a movie is good or bad.
This is exactly what we need in the world. I started learning Rust because of the amount of work I'd need to do to go from "my code compiles" through to "and now it's not a pending lawsuit". Rust is not for everyone, so I'm really happy to see C++ moving towards a world where it catches up to (and hopefully exceeds!) Rust's ergonomics and safety.
Why programming on c++ gives you a lawsuit?
Rust is a moronic language.
If you're thing is safety, WHY THE HELL WOULD ALLOW SOMETHING LIKE THE UNSAFE COMMAND?
All the problems (and benefits) of C++ is how many features there are and how there's always a way around their restrictions.
Why move from a language that allows anything to a language that allows anything.................with far less libraries.
Rust hasn't solved anything.
Also ergonomics is super relative.
@@robrick9361The whole point of unsafe is to isolate essential but uncheckable low level operations to compartmentalized blocks that can be more easily reasoned about and verified by hand (functions, modules). Good C++ design already follows the same principle (References/Smart pointers vs pointers, Range for vs raw for, collections vs raw new/delete). The only difference is that Rust has stronger compile time checking to enforce this compartmentalization.
As for ergonomics, while it is true that it is partially determined by preference/experience, there are objectively more ergonomic ways of programming, otherwise we would all still be using assembly. Rust does have features that make it easier to express your intent than C++, such as sum types with pattern matching.
And as for solving no issues, you should go ask Google, who have observed a staggering reduction in memory safety violations in the parts of Android that have been written in Rust, or Microsoft, who are investing heavily in Rust support for Windows, or Mozilla, who's multi-threaded CSS renderer project failed multiple times before they successfully reimplemented it in Rust, that "Rust solves nothing". I'm sure they will find it very amusing.
@@robrick9361 Because rust got it's start on LLVM which needs interop with C. Even then, you have to explictly go out of your way to make "unsafe" Rust code. You're so hyperfocused on a "GOTCHA" that you missed the fact Rust has a way better toolchain than cpp. Better package manager, better syntax, Composition over inheritance, the list goes on.
@@robrick9361 better a 10-line unsafe code block than a 10,000-line unsafe codebase
Very nicely done, Herb! This approach not only bypasses the backwards-compatible limitations baked into C++ while still allowing mixing code, but keeps the language feeling like a refreshed C++ instead of something completely new. I think this compromise will be a appealing to many C++ developers. I think Rust is an excellent alternative to C++ (and is available today) but comes at the cost of learning a different way of thinking about memory safety and interoperability headaches with C++. Carbon is another experimental language trying to overcome these issues with a new language that prioritizes compatibility but is not familiar to those coming from C++. I suspect cppfront will be an easier sell to those currently heavily-invested in C++ but want more simplicity and safety guarantees.
In addition to his technical skills, Herb is an excellent presenter and leader.
This really is quite good! I've been waiting years for someone to reduce complexity in C++!
Even a luminary like Scott Meyers had lost hope years ago. In his last few public talks back in 2017 (that are available on his website), it's very clear that he had enough. In one of his talks (at Dconf), he said that he was still taking engagement talks as long as it wasn't about C++, and that the C++ design committee didn't really care about the creeping complexity. I think that one is a bit harsh but it speaks volume as what he thought about the evolution of the language. Herb's experiment is a stroke of genius, as it is both the disruption that is needed and the continuity and back compatibility that is a requirement.
With committee that is so focused on backward compatibility, there won't be any progress in C++. It needs a serious redesign. Like a dozen or so new keywords and removal of non-intuitive bits like initializer lists. Templates need a serious redesign to be more readable. And so on. It needs a massive purge to be a better language.
This is not just a fascinating idea/experiment, but may even fall into the "essential for continued language evolution" category! I really hope it succeeds
I think C++ is on life support. Hardware is at the point where you can create GUI apps (yes, I know C++ is a systems programming language) much more rapidly in other languages and still have acceptable performance, than you ever could with C++. That it's still difficult for beginners to the language to install and link to GUI frameworks/libraries in C++, is a real hindrance.
@@atlantic_loveyou realize that game development is still C++ most of the time? Rich client apps are on the way out, games are here to stay.
@@mx2000 Rich client apps are not on the way out. Only the ones which require no computational power.
That's a good chunk of them, but certainly not all.
What I like about that is that you can install Linux on someone's computer and he won't be able to tell the difference if he's a office / web user.
@@atlantic_love C++ is a mess, programming language without any idea expressed with good design, see the list of wishes from Stroustrop books where Stroustroup listed some items for himself about what the language needs to be like.
@@atlantic_love Yes but when you have large data sets you have a good C++ optimization and memory control. Performance is still king and never fast enough.
This is super exciting. I'm a Rust engineer & I love Rust, but I would also love to see C++ become modern & safe so that we can all build better software with less headaches.
Wow, I didn't realize there would be cameras on the mic stands! Super glad I was able to twist Matt's arm into hacking support into Compiler Explorer before the talk was over - your reaction was priceless 😄. Thanks for a great closing keynote as always.
I find the idea of the gargantuan and ugly monster that is C++ continuing to evolve for another thirty years terrifying.
It's great that Herb is doing this. I am designing a way to do this in C, but once it's done, no one will know or care about it except for me. When Herb is done, it has a good chance of actually going somewhere. Even if not in the standard, there's no way it doesn't get a community behind it after this talk...
I'd be interested, how far have you got? Do you have a github repo?
I'm amazed that Herb Sutter after so many years is still going strong, still is thinking cogently, and even looking much younger than his years. Kudos.
I love this. It definately took a rust-like approach to compiler warnings / errors, which is great. Not only are the messages clear and they tell you how you can fix your mistake, but it also helps keep safety within c++ programs. I also enjoy some of the "syntactic sugar" resembilng some of the newer programming languages. I also never knew about the whole NSA ordeal with type unsafety and them advising against c & c++. Thousand Thanks to Herb Sutter And cppcon
so modest. i've got a feeling this is going to be a historical talk.
Amazing work Herb. I now again have hope for C++'s future. Also, very good point in the end about naming the syntax cpp2 explicitly. Human nature is one of the reasons there is still so much confusion about the language.
I've always believed this style of syntax versioning to be the correct way forward. Count me in!
This is literally like a dream come true. More than once I've written fake cpp code in an empty editor just to imagine what a unified function syntax would be like, what a unified paramter passing paradigm would be like without all the const ref crap. There is an echo in my soul that this just makes so much sense, and I beleive it is a common feeling among many cpp coders. Yet cpp toolchain always felt like a behemonth that's too big and too complicated for a lone developer to tackle on. So a great many lone developers are left to just imagine what's possible. It really need someone like Sutter to push this venture. Please make this happen. Sutter is like jesus reborn for cpp.
I cannot describe how much I loved every single part of it, only then to be crushed how literal perfection is gonna be stained by (1:24:55) the confusion that is gonna be caused by an empty return in the function that is supposed to return certain values (though, to be fair, it’s gonna be so freaking convenient at avoiding the little annoyance of repeating the structure shape, that I’m gonna use it anyway. Just like I use the ternary operator where it completely screws the code readability)
I have been ranting for years why C style arrays and pointer decay kills the consistent value semantics of C++
This idea of doing away with pointer arithmetic is absolutely the best thing.
Also uniform syntax!!!
The safety idea of showing errors and giving exact solutions for standard recommendations is really good.
This could be a gamechanger in terms of reducing complexity. Hyped to see this come forward!
Promising evolution, this transformation became inevitable, good luck Dear Herb ✌
It's been a long time I've done c++, but that got my attention back. I could imagine something like this being the default and you can enter "unsafe mode" like in other languages for the "old" c++ style.
1:04:00 If it works on anything with a subscript that has an integral value supplied and has a size(), it fails on std::map.
That's just a fantastic idea! As Herb said, he wants to teach people more about how to program instead of the details of C++. So and I want to program more instead of learning about quirks of particular syntax/semantics of C++. Herb, you have full support of the random dude from the internet!
Really amazing what he was able to accomplish with basic principles. I really look forward to a CPP future like the one he displayed in this talk.
I have been wanting cpp2 for a long time. It is much better than I imagined. Would love to see it succeed.
Fantastic, I don't need backwards compatibly for my green fields programs. And I may not need to learn TS, if this can run in the browser with decent screen IO. :) Thanks to Herb for his long term efforts.
learnt alot of c++ by just watching this video... kudos Herb for the effort and all the best with this very worthy experiment
Onece I'm finished my thesis, I'm going to start working on LSP and treesitter for this (with Neovim support in mind). If this reaches escape velocity, it's going to be huge. A transpiler isn't as exciting as something like Carbon, but I think this is the right increment to move forward.
I wouldn't call that mess of Carbon exciting... Carbon was the main reason why it took me so long to view this video and take it seriously.
Carbon from where I stand seems more like a disease while such project finally feels like a benefit to both C++ and programming in general.
I'd love to see your transpiler in action but please don't ever implement yet-another-useless-new-language-that-should-stay-in-the-lab-and-instead-extend-C++-with-its-one-trick-pony-feature.
@@DerDoMeN Thanks for your comment. Just for clarity, when I was mentioning a “transpiler”, I meant Herb's. It seems to me that `cppfront` is (right now) a transpiler from Herb's Syntax 2 to ISO C++ and STL + cpp2.
I was only talking about implementing some tools (a language server and treesitter support) for it.
How about cppfront being a compiler flag for GCC or clang or MSVC, similar to "-std=c++XX" ? Then potentially it would feel like a built-in part of the language. And since parsers are generated anyways, we could easily go from [Cpp2->Cpp->IL] to [Cpp2->IL].
The solution cannot possibly be to kill C++ by creating a new language, as that does not solve any existing problems but potentially creates several new ones.
And C++ is too complicated for practicality in the future.
Anyone who would do the same research that Herb Sutter has done, would likely arrive at the same conclusion (or a very similar one).
@@007LvB think the other way around, that's exactly cpp2. With cppfront, you can either write in pure cpp2 or mixed cpp1 and cpp2 and as time goes by, there def would be support for more things
Herb is such a BOSS! I hope this experiment leads somewhere - it'd make me get back to being a C++ developer again.
Even if it doesn´t succeed, you have created an awesome new language!
It is very surprising how much can be improved while being tethered to syntax1 code generation. Fantastic work.
I've been avoiding C++ in projects because of all the complexity and the chances to fail miserably. But this looks pretty good!
I have one important question though: Why not `const` as the default for everything everywhere? I am a firm believer in "the laziest solution should be the best", so adding sth like an explicit `mut` instead of `const` would fit that paradigm.
I guess Herb simply didn't implement it yet.
I agree, many people have the sentiment that mutable by default was a mis step, but to correct it now would break the world. However with cpp2 that isn't a concern anymore. It could even be a flag if there was any strong pushback against it.
@@Firestar-rm8df A flag would mean you can't look at the code in isolation and figure out the meaning. Flags shouldn't be able to change semantics like that, I'd say.
@@Adowrath There are already plenty of compiler flags that can change behavior. and preprocessor macros. That's why flags and build scripts are often checked into your repo with the source code as it is a part of your code, just at a higher level of abstraction. -fno-strict-aliasing for example. I'm not saying this is a good thing, I'm saying this is how it is and we wouldn't be any worse off, and having the flag you can set is better than requiring everything to be mutable by default. Also, I imagine you would likely get a compile error if you toggled the flag for a code base erroneously as const-incorrectness simply doesn't compile, which is the beauty of const.
@@indiesigi7807 do you know anything about clean code? You should const everything, and having it as the default is even better. An optimal program would be completely made up of constexpr statements, so that only the I/O is not const
Much respect, Mr. Sutter. I will keep an eye on this; amazing work.
Much appreciated!
Liked most of it.
Not sure why everyone wants “name: type” syntax in all these newer languages. I frankly find it less readable than what we currently do,especially for any kind of chained logic like assigning from a function return. Also, having lots more keywords and punctuation would make the resulting c++2 MORE legible and simple, not less. Just imagine using the functional keywords “pack()” and “unpack()” instead of all the magic “…” for packs of types, fold expressions, etc.
Notice that the best improvements come when Herb introduces a few keywords and all sorts of old BS goes away: “in”, “out”, “inout”, “is”, “as”, etc. Others I’d propose are:
move: Have a keyword to do moves, demand move semantics (e.g. a specialization of “in”). No more && junk.
pack(), unpack(), type, types: Replace all the BS with ellipsis to handle list of types, packs of types, decltype, etc. Would transparently add support for having named sets of types in general contexts.
Reflect(), reify(): reflection with a readable syntax.
One thing I’d argue strongly against is making supposedly “unnecessary” punctuation optional. There’s a reason human language evolved in the OPPOSITE direction. Down that road is things like Python where you end up with pathologies like whitespaces determining scope.
Yes - programs are WRITTEN AND READ BY HUMANS. A "std::reflect( ).getMembers()" is a lot easier to understand, read and write than " meta = ^[...[::]...]".
keywords are not out enemies - esoteric operators and the reliance on templates is.
I also think "int x" is easier to both read and write than "x: int". And that was one of the first things that bothered me. I'm sure H.S. has some good arguments about that, though.
But we will see. There are as many different features in C++ as there are differences in what C++ programmers prefer.
This feels like the right initiative to pursue for the community, but most of it will probably be some sort of democratic mess anyways.
This is a gold mine of explicit ideas for doing a C-2.
The parameter passing syntax looks like it would be non-trivial to learn and therefore may impede the adoption of cpp2 if it is implemented as shown in this talk. GC, if added, will probably lead to fatal fragmentation of the community, as it did with D, because half of the community will just switch it off. This whole proposal in general is great as an improvement to teaching, learning and safely using of C++. One other problem I see is that it is not a huge immediate improvement in most C++ use cases, so bottom-up adoption may be slow.
I don't think it's that complicated to teach primarily because the default (in) is the right answer 75% of the time, and when it's not it's obviously not, and inout is the answer.
The presented system of parameter passing is far easier than what we have today.
I love the syntax of cpp2. And loving the all the features of herb trying to make, light weight exception, static reflection, metaclass, gc support. It will kill C++ dialects like UE C++ and QT C++ which is amazing. But something I miss is that some kind of ambition that make people thrills. I really wish that circle, carbon, val and cpp2 get marry somehow. We need better mechanics for meta programming. We need better approach that make evolution process faster. We need compile-time memory safety built-in to the language. We, C++ programmers need some features that make us claim proudly that we are at front of PL rather than C++ won't die because of backward compatibility.
There was something completely missing, and not even mentionned in the evolutions: templates. I wonder what thoughts he has.
It is not going to kill UE C++, the reason UE CPP exists is because it is tightly integrated to UE's Blueprint system. It does more than just making CPP safer. That being said, It would go a long way on making UE CPP simpler. So end result would be something like UE CPP2 where you still have Blueprint extensions but built on top of CPP2 instead
@@lolilollolilol7773 I thought ‘_’ for the type made it a template. Relatively early in the talk - it was quick.
@@lolilollolilol7773 templates are first line on his todo-list, right before support for classes!
@@russianbotfarm3036 That lacks a bit of functionality though, for example: f(_: x, _:y) -> _(what type is this?)
I didn't run of to a different language, I came in as a compiled language newcommer and chose rust, partly because C++ just appeared bloated, with a lot of "Yes, this is the most straight-forward way, but it's unsafe and we don't do that anymore", and no consensus as to what current best practice even is. I wish this project the best of luck :)
implying rust isn't bloated
When Herb put C# handle allocation into a dialect of C++ (gc_arena, 2016), I thought "what a waste" . Making gc.new available is the appropriate place, the C++ place, to put this kind of compatibility. You can still have full cpp2-like syntax whether you must run in CLR or not. I saw gc_arena on an early slide and wondered how much time was going to be wasted there. Answer: NONE! As soon as he talked about allocating memory on the stack, on the heap, wherever, I realized that he'd arrived at an answer to this that anyone, even a curmudgeon like me, could be delighted at. Good Job, Herb.
I've also been bounds-check resistant because -- well, short answer is, the last time this was a flaming conversation for me was in the 90s, before Moore's Law had done most of what it could to processor speed. I saw code-bloat and exec time grind-down in that direction. Having cpp2 do it naturally, natively like that (post-[size]Moore, too) is DEFINITELY a step in the right direction.
And even from outside the US, we have to take "Wherever possible, do not use memory-unsafe languages" really, really, seriously. This is a way to do that. I want to be HAPPY to write C++ for a long time yet and cpp2 may be the best way forward. (see 40'00 - 45'00)
okay, I'm a full-on C#/.NET hater.Hate on me for it. I think I have valid reasons but I acknowledge that there is lots of good code -- e.g. Zachtronics -- written in C#. This is not the place for those reasons.
It's a different programming language that interoperates well with C++. Herb keeps saying "it is C++" but I don't know what that means.
I think he means that it's built using the same underlying concepts and features, as proven by the fact that it compiles down to C++
@@piotrarturklos C++ compiles down to assembly, but it doesn't make it assembly.
Thanks for providing this talk! He already had me at nodiscard is a default. I think this experiment will decide about the future of C++. It has reached a level of complexity with a bunch of optional but actually essential rules to follow, that makes it unappealing to work with. Especially if you compare it to younger languages with all these features baked into the language standard. I hope this will bring C++ to a state of the art level.
I have been on a "Rewrite it in Rust" path for the past few years, and am down to one last rather large C++ project that I was wondering if I should rewrite as well. Recently I decided to finally take the plunge, but this talk made me rethink it. I'll leave it C++ for now and see how cppfront develops.
The cppfront code is surprisingly small, considering what it can do -- Herb managed do a lot with relatively little code. I'm cautiously optimistic!
"don't pay for what you don't use" and "bounds checking by default" seem mutually exclusive
That "by default" is important... you can turn it off and then you don't pay for it.
I'm amazed. Really hope this project works out.
I love it. I can't wait to start using it.
I love rust grammar. Don't get me wrong.
However instead of transpiling, why we can't simply deprecate all those dangerous sharp edges (malloc, allocating new, union, unboundchecked accesses) that now c++ already has safer alternatives then just remove or internalise/classical-mode them.
If the *actual* problem is today people still *keep* using them as before. Why won't c++ just stop them from using those?
I worked for a company that built a front for a second language, and used Prolog to write this. Prolog was very powerful for this purpose (perhaps not that fast, though).
I don't understand why people rave about this presentation. The problems described don't require new (ugly) syntax or compiler to be solved, we just need to improve current compilers. The real problem in cpp is that with every new feature it forces you to go templates which really hard to debug
Templates can be arcane, that's true. But a lot of the problems with C++ are around things like defaults, where we have to teach people to overcome language defaults that are often wrong, and it's not possible to change defaults because any change would be a massive break. For example, we teach people to be careful about the compiler-generated special class functions that are generated silently by default and that are dangerous for many classes, and to remember to suppress those when they're often wrong... but we can't change the language to not generate them because that would break all the classes that rely on them, we can only do that if we have a second syntax that is not in use today. Another set of problem is around where the language just has multiple divergent ways to do the same thing in different places, and we can't really fix that without unifying those ways. I have one suggestion: Would you please check out slide 95 at 1:39:00 and see if that list might be more persuasive regarding the amount of arcana we have to deal with in today's C++? If we can remove that 'accidental complexity' that isn't core to the language's value, I think we should try. $0.02!
@@herbsutter4340 You don't need another compiler or syntaxes. You just need additional flags and checks for current compilers. Then it is the same: if you want it - you use it.
@@fareloz I'd love that to be true. It needs more than assertion that it's possible though... a lot of smart language experts and tool developers have been trying that path for years. But perhaps you're right that there's something they've missed -- I welcome the detailed proposal and the working tool or prototype to try out, that demonstrates how it can be achieved in an adoptable way (tools for today's syntax that are efficient and noise-free enough for everyone to be able to turn on at build time) and also achieve the same goal (at least of reducing what we have to know/teach by 90%, and reduce CVEs by 98%... it can't make C++ 10% the cost to write tools for but I'd be happy just to get the first two if it's practically possible despite experience so far).
@@herbsutter4340 There are many caveats which compilers warning about already: usage if initialized variable or dereferencing of null pointer, usage of moved object and many other. You can always force this warnings to be an error. [[nodiscard]] can be added implicitly too by the compiler. Maybe I miss something from the talk (or just simply don't understand), but I don't why I need another layer for this.
I' m so touched by this talk, thank you Sutter!
I suggest that instead of cpp2, we call it sage. Because sage is an herb, and Herb's wisdom is sage
Herb, you have outdone yourself this time!
cpp2 -> cpp1 -> c -> assembly
Sounds like a great idea, 10 years down the line,
cpp3 -> cpp2
The problem is maintaining back compatibility and it's always going to f@ck things up. Always, rust works so well because it is not designed to interop with c, yes it can but that's additional, not the core part.
I'm not convinced a systems level language should force smart pointers or particular trendy abstractions. For example, pointer manipulation is essential. There's too much handwaving in the answer to that question that was asked at the end. Maybe this is the direction of evolution of C++, but then it won't be C++ anymore. For me, C++ is the language I go to for maximum computing efficiency.
This seems to be an example of the age-old tension in language design: Some people want a safe, productive language that is nice to use, but many want a useful language that can get out of their way when they program at a low level. Personally, I think that the safety features should be left to tools, and the language should be kept as simple and as unlimited/expressive as possible.
From a point of security, it actually makes a lot of sense for a systems language to enforce pointer safety. You gain more by having an extra indirection (which is not always used, as in the case where shared_ptr is passed as const&), than by risking a lot of security vulnerabilities. Our processors are quite a bit more powerful today than they were 20 years ago, and this question is less important today. The only place where this has some merit is in strict realtime applications, and even there we don't always want to manage everything.
In my own opinion, safety is more important than speed. But we can test for safety and then disable those tests later with some compiler optimizations and flags.
Besides, we also need to educate programmers as better programming practices evolve. Just as we did with goto, now it is happening with the preprocessor.
Amazing work! Hope this will get a future!
It's called learning to code, which is quite a bit different from building programs with copy/paste.
I read an article recently encouraging people to leave C++ for "safer" languages like Rust or C# but this talk shows C++ has the potential to reinvent itself to be a safe language. I'm excited for the eventual reincarnation of CPP2 to become a part of standard C++ in the future.
Reminds me on the notorious xkcd picture on several standards.😏
I wonder what’s left for memory safety after getting rid of nulls and pointer arithmetic? Ie, with those out of the way, why isn’t it 100% memory-safe?
@@russianbotfarm3036 References lifetime i.e. dangling references due to lack of lifetime annotations in C++.
36:30 Calling free functions with object syntax is very good, too. C# extension methods. This is very good not only from the toolability perspective, this is also good to better follow single responsibility principle: we shouldn't define draw and save functions inside the classes, but ability to call object.draw() is very nice.
44:38 The problem is simple to solve. Refrigerator, vacuum cleaner, iron, coffee machine and TV have no place in the Internet, and any network at all. Maybe TV, when user explicitely allows it to do so.
C *has* abstraction. It abstracts the hardware in a way no other language did up to that point.
Herb has one of those beautiful brains that thinks incredible things and also has enough horsepower left over to explain it in a digestible way. I loved this idea so much. The semantics looks very simiar to object pascal, without the ugly verbosity. I wonder what anders hejlsberg would think about it.
This is great! Shouldn't be unlisted.
TLDW: The answer is yes... if you write a new language and pretend it's still C++ by importing some of its baggage (the standard library, external build systems, exceptions, etc.) It's a lot like trying to keep a band name when the lead singer leaves. I'm not against this though, since it's about time C++ apologizes to its users by taking some time to help migrate and improve existing codebases that aren't getting ported to a new language for some time (if ever), even if a compelling replacement comes out.
I have done some research on C++20 modules, and it's so good to see them being incorporated in the standard now.
However, there are some very fundamental problems that need to be addressed:
Each time we compile a project, we need to scan all project files and construct a DAG dependency structure and compile the source files in order. EVERY TIME!
I really want to see Cpp2 address this. Because it's a pain for tool developers and the main reason why module support is coming so slowly.
A good paper "Remember the Fortran" (p1300) describes in detail what the problems are. Because of the precompiler Cpp cannot easily overcome this problem.
But maybe Cpp2 can?
I've always wanted to see this, leading C++ people stop patching, draw conclusions and start over from scratch.
I bet the majority of C++ programmers already had this kind of dream for so long already. Yes, carbon seems to be promising, but imagine C++ moving towards the direction of this talk!
I see the value of this for C++ programmers, but I wonder what the experience (say 5 years from now if this is stable) for people who don't understand the generated code? Will the semantics stand on their own without contextualization with existing cpp jargon? Very interesting indeed.
Well, maybe - hopefully! - it’ll be fully implemented into compilers and won’t _be_ a ‘-front’ anymore.
I haven't programmed in C++ in nearly 20 years and can't really read the modern version.
@@BryonLape That is probably one of H.S.'s largest motivators? C++ should be a syntactically and semantically simple language that is easier to teach and learn. Bjarne Stroustrup seems to share this sentiment.
Hits so hard. Imho this seems to be the path forward to keep our hands on the full power of C++ while getting more compiler-driven safety with least friction.
The way I solved this problem with Script2 (Serial Chinese Room Interprocess and Telemetry Script) was I didn't use the std library and I instead wrote everything by hand using contiguous Automaton SCII data types that auto-grow from stack to heap. I use a single translation unit that can compile all the code in seconds. You really don't need to use multiple translation units until you're trying to complete many huge libraries in parallel using one translation unit per library.
Only c++ devs could look you in the face and say they like the status of c++ package management
imho, C++20 syntax is near-perfect. Just deprecate the ridiculous standard library and build a new one from scratch. Learning from libraries in newer languages might be a good idea.
All this work is - if looking at it from a birds eye point of view - still follow up cost of the fact, that C was/is used.
C++ needed to be C compatible and hence inherited C quirks. Now someone tries to improve on that by creating another evolution of the "We want a better C".
In the meantime, the people creating Zig do literally the same, but on a C level. "We want C without its mine fields".
And in the next room, the Rust people try to "solve the problem" with some clean room approach, starting from scratch.
Now I am not a fan of many aspects of Rust, and I used C++ for a few decades. But the whole ecosystem is toxic. "Dumbed down standards" of C++ and C show that (MISRA).
Add to all that the costs incurred by the necessity to do "language xy bindings for some C/C++ library" and you see how insane the whole thing is and has been for nearly 30 years.
The problem is IMHO not a language problem in the first place. It is an ABI problem. If someone were to define a "modern ABI", all languages (and OS) could easily support, all that backwards compatibility to C jazz would become obsolete.
C would have to innovate (and support the standard ABI) in order to play nicely with others and in the long run, the whole community would no longer be held hostage to that terrible heritage of C.
Oh yes - the "There is no C++ ABI" adds to the problem further. And adds costs, spent for people writing C facades for C++ libraries, so they can be used by the foreign function interface of other languages.
The whole thing is madness. And we are just too neck deep into it all for way too long to see it.
I see Rust as an honorable attempt to break out of that vicious cycle. But I think it is but a stepping stone and the future will bring a systems programming language, which is not such a diva as rust, but actually fun to use and equally safe.
Cpp2, in contrast is a workaround of a workaround and as such, maybe practical but not really solving the root problem.
What Herb is proposing here is not making C++ more user-friendly, nor faster or simpler - this is proposing a new language and claiming it to be C++.
and that with some of the worse things we have seen from other languages like more abstract syntax, more strange use of symbols ( I could understand using '_' as a placeholder 30 years ago but we are no longer limited to teletypers), 1 syntax but with 2 styles (so yes - 2 different syntax).
Many developers have complaints about C++ but this is like saying Rust is C++ just cause it could be translated to C++.
9:57 Yes, a round of applause for General Zod, in the bottom left there, who managed to escape the Phantom Zone to come help fix C++.
I don't think it's a matter of improvement, it's a matter of survival. When there is a guideline telling you to stop using C++ then it's not up to you anymore. When your company says that we have to change language because otherwise our software will be labelled as 'unsafe' because C++ is in a list of unsafe languages what will you do?
Another amazing talk by Herb!
I really liked this talk and the direction it's going in, I want to see C/C++ become a more secure programming language.
First time watching one of his talks. Didn't know John Cena gave C++ talks!
re: around 1:04:00, if the bounds checking assert_in_bounds is applied to on any stl container with integral subscripts and a .size function, how does it behave with something like map? If I have a map mymap with 3 ints 5, 7, 143 as keys, then mymap[143] is fine, but way beyond the size of the map.
(Also, I really like the cpp2 idea. This could be just what we need to clean up the language)
18:55 I was thinking the same, Herb. The *void f(int i) {* syntax is usable, I don't like the *auto f(int i) -> string {* syntax, because it's more text and you have return type written in 2 places. The *f: (i: int) -> string = {* is alright.
What I'd also add is the ability to declare a variable of that type to return it: *f: (i: int) -> ComputedText: string{""} = { return Text; };* Why? Because it makes the code clearer: the code explains what it does. Right now you only see the type, like a string, but you don't actually see what exactly the string returns. Like, for example, sometimes it returns an int. Now I have to go and look up the documentation or read the source: does it return an error code, number of bytes processed, or something else?
Thanks! Belated answer: Yes, Cpp2 also has multiple/named return values. You can write your example like this:
f: (i: int) -> (computed_text: std::string = "") = { computed_text = Text; }
or better still, avoid the extra step of initializing the return value to "" only to overwrite it, like the following where the string is constructed directly from Text:
f: (i: int) -> (computed_text: std::string) = { computed_text = Text; /*now a constructor call*/ }
Finally, note that there is an implicit "return;" at the end of the function body, and if you want an early return you write just "return;". It's not "return computed_text;" because we already know what the return values' names are, and they were already set, so all you need is "okay function, now 'return;;".
@@herbsutter4340 Thank you for the answer. I'm thinking of trying it out for one of my personal CMake projects: it's a DLL mod for a game in C++ on Windows.
I'd like to add to the "this is just an experiment, it might fall" idea - even if it fails, it can generate value, bring something new or expand our knowledge - I think this is valuable either way. Then it would be probably of even more value if the decisions that were made were documented, so that someone could build on top of it. But that would probably pile up the work required
I love programming in straight C. Maybe this is what I needed to jump into C++.
I think what wasn't clear in the talk about nullptr is that it's better to have compiler support for knowing a variable is uninitialized then to initialize it to something utterly useless.
I'd like to see that generalized to any type, marking whether I want the default constructor or leave it uninitialized, and give the compiler freedom to elide the default constructor when it's capable of tracking definite first use.
I'm not sure if there's much meaning to the fact, but with Cpp2 you can (or should be able to?) do
main: () -> int = { std::println("Hello, World!"); }
which is the first time we've had the ability to write that on one line to the best of my knowledge. No #include needed, not even an import, just code.
you need to return an exit code
finally a somewhat realistic approach to this, instead of "let's just dump existing codebases and create a new *perfect* language"
been playing with this, most promising thing I have seen in a while, Carbon is ugly and not C++, but cpp2 is C++ and is beautiful so far
Personally hate the use of underscore as a type placeholder. Would much prefer a keywork like auto or even var. Also dislike much of the departure from C syntax for control flow statements. Obviously C can be improved but everyone already knows and understands C so every difference is just one more thing someone has to learn, so why not minimize that rather than indulging yourself with your personal preferences.
This is a revolutionary approach and I loved it :)
It's almost adorable to hear Herb talk about context-free grammar. The JS language community has been using transpilers to prototype language evolutions for 10+ years now. And while the result isn't throwing out context-free grammar let's just say a certain amount of hacking happens at the lexical stage, and we don't always fully validate the AST when building it at initial parse time. Everyone loves context-free grammar until their favorite time-saving syntax extension violates it, then it becomes a tedious game of how can I hack the lexical scanner to look forward and insert special tokens, can I move some syntactic validation to after parsing ends, etc.
People teach C in universities and not C++ because fprintf() is just a function call, it is easy to explain to new students. When cout
fprintf looks more complex than piping data like in your favorite shell.
@@CTimmerman from a pure syntax standpoint no,
This really reminds me of how refreshing it is using the Burst compiler in Unity. Small bubble of "new c#" that is isolated and allows you to really claw back the performance where it matters.
This looks great.
How about local variables being const by default?
So if we really do need a successor, having looked at all the contenders, I can get behind Herbs cpp2.
I really want this to work as intended, but I start to have a sinking feeling right around 1:45:30 when Herb tries to reassure me that I can still use union with it if I want. Am I misinterpreting this? Because to me it sounds like Herb is trying to say you could always just mix and mash cpp1 and cpp2, just like you could always mix and mash c with cpp1, without any barriers or demarcation. I get that the prototype uses a transpiler, that's great that it makes it easy to prototype, and backwards compatibility with cpp1 is a side effect that is supported by that transpiler, but I'm thinking about how cpp2 would be implemented long term. Maybe it was a mistake to implement c++ using cfront - it just led to to the mindset that the language was an extension, when perhaps it would have served better as a clean break. Maybe now that mistake has reached a tipping point, only now we are repeating the same mistake by implementing another transpiler? Consider a dystopia: the year is 2050, Rust and Go are long dead - cpp2 stole all their market share since everyone thought that was the quick fix. However everyone still predominantly works with a bunch of broken legacy cpp1 code. The only difference now is that the resulting hybrid cpp1/cpp2 language is even more complicated than it was before, since alongside all the C++ sublanguages that existed circa 2022 (legacy C, macros, stl, template metaprogramming), there is now also the cpp2 sublanguage, which is so complex that it was designed to subsume all functionality from every other sublanguage. The language developers only served as the enablers to a stunted userbase. It's 2050 and no one ever bothered to implement any clean keyword demarcation or file type extension that could have helped tooling developers to make out what code is cpp1 vs cpp2. No one ever bothered to implement constraints that would have helped to coalesce the ecosystem towards cpp2 to the point where compilers could drop support for cpp1 and relegate it to special purpose compilers. No one ever even bothered to make the "-p" flag a default, and as far as that goes, the language still manages to get the default wrong by default. Backwards compatibility is so entrenched an idea that even when people want desperately to break from it they still find themselves clawing their way back to it. It's 2050 and all the compilers still have to support cpp1, and all the tooling has to work around a minefield of cpp1 code whose grammar is so complex they could never hope to support it without the backing of a major software company. I know we really want to avoid another Python 2->3 debacle, but the fact remains that Python made it through that migration no less popular for it and something was gained from it. And that isn't the only example. Fortran 77->90 comes readily to mind here - just as with pointer-arithmetic and memory-leaks-by-default, you have to admit it is a pretty stupid thing to say that type is assigned based on the first character of your variable names, and sometimes you just have to have the courage to admit that it was a stupid idea and make a clean break from it. Other times, just as when C made a clean break from Fortran, the resulting language is less performant. You just have to accept that some people will never change, they will always want their unions simply because that's faster, and to them you have to ask, "why aren't you using Fortran?"
Any sufficiently complicated C program contains an _ad hoc_ informally-specified bug-ridden slow implementation of half of Common Lisp.
This is nicely written! But I think it's still better than the alternative where everyone switches to Rust, and there will be no developers left to maintain the billions of lines of C++ that makes the entire world work. Dijkstra taught us to avoid goto, and so we don't use it even though our languages still allow it. If we adopt a rule of using Cpp1 to maintain legacy code and Cpp2 to extend it (open/closed principle), then we should see a gradual transition away from Cpp1 coding, resulting in a better world.
Even though I understand (and actually appreciate) your sentiment, I think it's important to stay hopeful and optimistic - because that inspires people to solve problems. As long as there exists a healthy scepticism, which is abundantly present in the C++ community.
When you mentioned the intellisense, I know this is destined to succeed.
Cpp is so special that cpp programmers are not physically possible to remember all the tools they have to use, simply because the tools are too many. The only possible way for cpp or any high performance container language to work is to utilize the auto completion to the extreme.
Also, 2 details I would like to mention. I think I mentioned them in carbon's discussion page.
1, since you already made the rich ast to iso cpp code translation, I think it should not be too hard for you to make rich ast to cpp2 translation. When a break update happens, people can use this feature to get code on new version. Then, no tech debt any more.
2, macro is still something necessary in even cpp23. If a tool needs some init function for all the classes even for user defined classes, the only way maybe a customized parse tool, and the dev have to tell people to include some weird header in their cpp file. The parser generates the placeholder header. After all these work, it's time to compile.
say,
class A{...}
initializes with a init(...) function. But if you don't want the users to write this for all the new classes, this trick kicks in.
The result looks like:
#include "some auto generated header.h"
class A{...}
I don't how to solve this, maybe meta programming.