If some big entity actually sponsored Sean Baxter to formalize his Circle C explorations, I think you'd be in a much better state. He's one of the few guys in the community that actually cares to make C++ safe and ergonomic
"Too many chefs spoil the broth" is true when it comes to adding features but there are many proposals which are geared towards solving inconsistencies in the language and making it more flexible and we need these proposals. An example would be the ongoing "universal template parameter" along with adding "concept" template arguments and "variable template" template arguments. As a library developer, I can totally see this being useful. Although they are "additions" to the language, they do not introduce radical or unfamiliar ideas or mechanisms.
This is a very necessary and important conversation. I think the comitee structure worked well enough at the time C++11 was released, but with the current size it seems to get problematic. More and more features without any overarching leadership and vision in one or a few people already seems challenging. But then add to that people joining the comittee, fighting tooth and nail, getting their feature and then leaving seems to be an increasing trend. A couple month later you see them changing positions into C#, Python or Rust role never to have to live the decision. I understand being frustrated with the process and getting burned out by it, fundamentally just trying to help. But this structure seems to not make C++ sustainably better.
I don't particularly like Sutter's CPP2 syntax but I do like the idea of replacing C++ with a new C++-like language where we dump the old bad stuff and take only the good new stuff. Eventually, CPP2 might replace C++ but that's a long time from now. A CPP2 programmer will also have to know C++ for years. Still, it seems like a better path than switching to a whole different language.
A new language that is basically just cleaned up C++ with coherent and consistent interfaces and semantics with essentially the same syntax structure as C++, would be good. (Including the standard library.) The problem I see accross the board is the replacements are all taking so many liberties with the clean sheet opportunity that they are really just creating completely new languages rather than improved C++.
About optional and maybe_view, it just baffles me why we can't just instantiate optional with reference types. It feels like an obvious solution to that problem.
1:07:09 I think the speaker misunderstands Herb Sutter's Cppfront if he thinks it "adds more stuff to C++" and makes the language "more complex". Cppfront is all about simplifying C++ and making its rules more consistent. It's not just the addition of yet another opt-in syntax built on top of the existing syntax - it instead completely replaces the existing syntax with a simpler one. Whether it will catch on and people will want to learn the Cpp2 syntax is one thing, and whether it succeeds in simplifying C++ is another.
But cppfront would be completely source-compatible with c++ right? In fact I remember one of the selling points to be we can still use the resulting generated c++ so that we don't loose the "investment" when cppfront is discontinued/not developed further So it would mean that cppfront would be built "on top of c++", hence it "adds more stuff to c++". It would only be a simplification if it breaks c++ source compatibility, but in that case it might as well be another language
@@notruff If you only ever use Cpp2 mode, it is a simplification because Cpp1 and its syntax largely becomes an implementation detail that you do not have to worry about. In the future, a Cpp2 compiler could be created that skips the Cpp2 --> Cpp1 translation step entirely.
If you add another syntax to the language the language goes from having 1 syntax to 2. That means everyone working on this language in a corporate environment will need to be at least passingly familiar with BOTH syntaxes. That makes the language more complex, period.
Go(lang) has evolved since Go 1.0 in 2012, but the changes have been tiny except for generics in Go 1.18 two years ago. It IS possible to keep a language small and simple over time, but it takes strong dedication and the courage to say “no!” even to nice and useful additions that would make the language just a little bit more complex.
Go is good for simple cases. You do not have Sum type in Go. So it's a pain to use the language when you need one, and you write "workarounds" to simulate a sum type and even then, in a type unsafe manner.
@@sirnawaz go to me isn't mature with many design choices that are insufferable such as the absence of warnings, includes from remote repos, list manipulation, and the case, upercase and lowercase as a private or public variable exposure classifier -- finally to finish off, it advertises some relative simplicity through explicitness, yet it didn't address nullpointer exceptions :> It better move and improve!
It sounds like "Let's freeze C++ as it is now, and let it slowly die out. It's just a tool, after all." After watching both Sean Parent -- CppNow 2023, and David Sankel -- CppNow 2024, I can't help but getting the impression that Adobe internally decided to move on to Rust or whatever "memory safe" language while putting their existing C++ code base on a maintenance mode. If that is the case, I do respect your company's business decision. I, however, still want to see how C++ evolves with Bjarne&Gabriel's profile as well as Herb's Cpp2, and I genuinely hope for them to succeed to turn the tide in favor of C++. edit: typo in names
Yeah, I'd like to see Sean Parent and Chris Lattner have a long format discussion. That'd be a nice incarnation of what Sean alluded to in last year's talk about how C++ can start to participate in the 98% of machine performance in GPU and TPU units. For example, I couldn't get the Halide team to talk about Halide futures vis-a-vis Mojo and the state of the art in auto-tuning for hardware (and vice versa from the Mojo team). The machine-level technical overlap between generic image handling code (say boost::gil), optimized image processing code (say Halide) and optimized AI code is very large. User's and algorithms really want to use domain specific languages expressed in C++ or Python, but the dynamism of hardware evolution these days requires addressing this question starting at the compiler level, not just more and more gymnastics with template metaprogramming.
i don't know how much this talk differs from all the mantra people singing nowadays 'stop using c++ for new project, use rust instead'. i have high hope on circle.
Hmm, maybe it's just me, but I don't see a language being "freezed" as something equated as "dying". I mean C is still widely used & it's not a language that constantly adds new stuff (the latest one IIRC is just a "_Generic" keyword which itself is added only on C11 I think? so yeah)
Man, this man is officially saying what everybody thinks. It's really not easy anymore to find (good) C++ developers. It's an incredible complex language with many foot guns!
If the standards committee tries to remove pointer arithmetic or add mandatory bounds checking (that cannot be disabled at compile time), I'm dumping C++ and moving to C.
I like the intellectual honesty of these C++ people. They are a nice bunch 🥰. Edit. Seems like C++23 will be my last version 😂. Edit2. Bjarne Stroustrup wrote that paper about ship Vasa, seems like that's been totally forgotten...😢
You basically attribute to C++ committee what your company do to its customers. And adobe customers are doing the same as most programmers with the language. Isn't it ironic? (Without the monthly fee)
About C after K&R (that I recall you saying that you didn't care about), I would say that C99 is actually another cautionary tale - it added lots of "cool" features (instead of being letting C be C) - but many were sort of rolled back in C11 due to a lack of adoption.
I relate to 57:00 a lot. When I use C++ it looks like someone writing python with different syntax. When I see people who complain about C++ being complicated write C++, it looks like completely unreadable code that I could not understand in a million years because it is 90% abstractions and unintuitive ways of doing things.
David is spot on with this. The direction of C++ has been concerning to me for a while now. I have complained about it at my job multiple times. It makes me worried for things like job security, because I really like C++ and enjoy working towards expert knowledge in the language, but the choices that have been made make me feel like its a dying language. We will see where it goes, I have little faith that this talk will actually change anything with the direction.
This is a great talk. Although I'm not an expert in C++ , I do enjoy it greatly and I do fear for it's future. I will probably have to look into some Rust for work at some point and I'm already working on Kotlin projects. To say I'm not a fan of the Rust syntax is probably an understatement but a lot of languages, including the C++ replacements all seen to be using a similar syntax style. I've seen several videos that demonstrate unsafe features of Rust so I wonder if it should be described as a memory 'Safer' language instead.
Trying to give a presentation to a group of c++ devs is akin to herding cats. Just shut up and listen to what the guy has to say for a bit, and then have your discussion after the talk.
First Half: C++ is getting a lot of pressure because it's not memory safe. Second Half: Just let C++ be C++ and there's no need to change it too drastically. Hmmm? But actually, I like and agree with everything up until the part about Herb Sutter's cppfront. Because I really like cppfront. I'm not sure how familiar David is with cppfront but it's actually intended to make C++ simpler. I think the way to declare things is much more elegant, consistent and easier to teach. Isn't that the intention? OK, so it doesn't look exactly like the old C++ but then the old C++ kind of sucks and most people agree that it does. And I don't think cppfront changes that much about C++ anyway. There's not that much new in "Herb's C++" as you call it. It's only a few things that make C++ safer and simpler. You wouldn't hire people who know _only_ cppfront. You would hire people who know C++ as usual and who could maintain old code but when writing _new_ code would write it in "Herb's C++". It's just like when they write a for loop they might write it now as a range for loop instead of the traditional style. They still know the traditional style. It's a long process just like the process to transition to Rust. If you don't do this I believe C++ will eventually die although very gradually. Yes, people now who try to write games in Rust might return to C++. But it's not because they think C++ is good (or else they never would have gone to Rust in the first place). But only because C++ is the only other choice for them now. Because there is a need, something WILL eventually come along to replace C++ for games, too, unless C++ itself evolves to fulfill that need.
I think the first half isn't about it getting pressure, its about saying that its ok to give up some territory to that pressure. That leads into arguing for C++ to hold on to the rest by not changing too much to try to compete for markets its ill suited for.
I think the argument agains "Herb's C++" was it adds another layer to already existing thing, therefore it complicates the language. People can't just throw away their existing codebases so it's not a choice to "not learn the old C++", therefore "the new C++" adds more stuff to learn. Herb was aware of that. Whenever he talks about cppfront, he says it's an opportunity, because we don't have code written in this new thing, so we can change/break it as much as we want. I don't think he have some strategy on "transition" tho (from old codebases)
@15:04 "18.7% of C++ engineers said Rust is another tool they use" ={combine this with a total number of Rust and C++ users}=> "99% of Rust users are also C++ engineers"
Great talk, and good luck with writting anti papers, because c++ after '11 is really moving into 'academic' space with complex and not really usable/complicated stuff even for simple subjects.
I completely agree, C++ Is becoming a complicated mess, I miss not having clear arguments to a function, to just have a function and not a template, things need to get simpler, easier. I use C++11 and some of the new stuff, but if a thing is too complicated to learn I just don't even bother, if it's a template with ...args or something similar I just don't. I want to write speedy code and have some control of what is going on, not to make my life to learn all the nooks and cranny's to be able to use this things
They should make a new language format with completely new syntax (like C++2 or idk). That way it is compatible with all old code, still is C++, but the compiler speed will improve 10x if done correctly from the beginning. Especially with modules this should be possible!
Awesome talk! 26:40 Not only animal names ... around 50-60 percent of the words that you used in this talk have Latin origins. C is truly the Latin of programming languages [and Fortran is kind like ancient Greek :) ]
1:03:30 Experts-vs-nonexperts is a false dichotomy. Someone who approves of an idea as "really clever" is either right or wrong, regardless of the level of expertise of that person. An expert's opinion is not made irrelevant simply by her being an expert. If introducing something into the language is more complicated than it's worth, then anyone who thought otherwise was simply wrong, regardless of expertise. Language features do not pick a side between being expert-friendly or beginner-friendly, they pick a side between being well-designed or poorly-designed.
Perhaps it's my bias working in languages that do not support method overloading, but the examples of interfaces where the action of the method is distinguished only by the types of the arguments passed in often make for very difficult to read documentation and more difficult to read code.
Well, he's right... when I need a memory-safe language, I just use Rust. When I need less constraint overhead, I use C++. I don't need C++ to become an unmaintainable lame copy of Rust.
I feel like language features are way more important in such talks than library ones. I'm glad that std::optional with ranges support comes in C++26 and we'll have some pretty cool functional-programming with it's monadic functions and ranges pipe operator, but I would be fine with whatever version of that even views::maybe kinda seemed reasonable to not introduce weird interface to optional, but that all just library meddling. If talk starts with Rust then we should focus attention on safety of language features itself and not library ones, like for example the thing that C++ for most stuff got worst possible defaults that make your code very error prone and/or ugly afterwards after you fixed that by specifying all function signature stuff like [[nodiscard]] constexpr blah-blah-blah. The syntax where we would specify other way around that something is in fact mutable (not constant) would be less error prone. And I understand that we can't just switch all default because we have legacy code that should be somehow supported, but still I think any thought in that direction should be encouraged just like cppfront, but as a cpp standard feature.
Given that the language is so complex nowadays, and that one of its main focuses is backwards compatibility, wouldn't be a better idea to literally "freeze it" so nothing else can be added to it?
A really interesting discussion. I haven't tried Rust yet but avoiding memory problems does sound good. My gut feel, though, is that if Rust forces a programmer away from describing their solution as they visualize it, other kinds of bugs and productivity problems will rise to take the place of memory problems.
It's not even about syntax for me - I could live with that. My biggest gripe with Rust is that it forces huge dependency trees on your project. The language itself and its STD library have lots of features missing (compared to C++) and you end up depending on hundreds of 3rd party "crates", full npm-like style,. even on a rather small project. I just don't see any project surviving for years in such environment. Unless you're Mozilla, Adobe or some other large entity who can afford having their own standard library. I have a growing suspicion that Rust is an attempt to make small/mid sized software companies to go extinct. Thus all the push in that direction. Having them creating enough Rust code to train AI on it before they go away would be a plus.
The whole premise of his talk is that C++ is getting too complicated because it is increasingly difficult to learn the whole language. Not only is it too large but also contradictory in many ways. But the whole idea that a language needs to be learned in its entirety is a misguided viewpoint that is all too common amongst programmers. Even Bjarne Stroustrup claims to not know all of C++ What really matters is how well you know how to use a language for any given purpose. If you know how to use a subset of the language well enough to accomplish your goals, then that should be all that is necessary. That's why C++ continues to be so widely used, because so many programmers find it to not only be useful, but the only language that allows them to accomplish what they are trying to do.
The expectation is not memorizing the whole thing, the expectation is coherent and consistant interface, syntax, and semantics so their is minimal learning curve and surprise when choosing to utilize a new component.
Not knowing parts of the language becomes an issue when reading - really, reviewing - other developers’ changes. Just to pick on another language, I’ve been using Swift a lot more frequently recently, and the speed at which the language has grown has led to a lot of inconsistencies in the language. I can control what I write, but i still have to review others’ changes. And reading those changes? It’s become a chore, because it’s hard to infer what a new feature does due to those inconsistencies.
For example, writing something as basic as a vector suddenly requires expert-level knowledge in the language. Meanwhile, I can trivially write a vector in C/Zig/Odin etc in less than 100 lines of code.
Very interesting, talk. Seems the flip side of this perspective, which I think has a lot of merit, is the one put forward by those asking for the C++ standard to not be ISO anymore? Some of those have said they don't want to contribute anymore in the current structure because because it is too difficult to get new things in. So the fact that these types of "prolific contributors" are being repelled by the "stewardship" function perhaps shows that the structure is perhaps beginning to self heal? Is there "hope" in that?
Horses didn’t become worse when cars were invented, but cars don’t require fuel when they are not used. Cars can take you from A to B much faster and if everyone starts using cars and you still rely on horses you can’t compete in the marketplace.
Fascinating to hear an honest self-critical talk about the existential crisis in C++. I ported one (pet) project to Rust. I'm hesitant to start a Skia project in Rust...but I'm contemplating it.
1:08:02 This, exactly. The trend is horrifying. Hopefully, it won't become kotlin, where there is a thousand ways to do anything and you got to know all of it. Or god forbid android api.
Do the TRACTOR-people not see a problem with the fact that Rust relies on ecosystem, i.e. code that is arbitrarily/accidentally, and temporarily, verified as safe with much less standard modules backed by the actual core language maintainer?
I was in the room when David Sankel claimed pretty much the opposite: ua-cam.com/video/ady2mUIQpt4/v-deo.html . I approached him afterwards and expressed the fear of what pulling even more people into an already inflated committee might do. 2Y later, I think he agrees.
ua-cam.com/video/qTw0q3WfdNs/v-deo.html I really enjoyed the lecture and I would really encourage shrinking this committee down and stop messing with the utility of C++. I'm sticking with C++17 personally, the changes to make it more javascript like are annoying.
Was memory safety actually invented to reflect back to the author that they have unsafe memories? Exaggerated memories? Deceptive memories? Therefore to inspire meditation asking “Have I deceived someone? Was the earliest reflection through my code deceiving me? If it wasn’t for C++ where else would I receive this reflection?”
Every time I watch a David Sankel talk I feel like this guy has won life. He loves to talk about his kids every chance he gets being genuinely proud of them.
No offence, but I've been watching for 40 minutes and I don't think this talk has gone anywhere useful yet. Maybe it was fun for people to just shoot the breeze in the room?
He’s shockingly accepting of questions and hears everyone out, which really slowed down the first half. It really picked up at around the hour mark, and there are some good points.
Is it just a matter of creating code checkers for cpp that find memory issues and other problems and then aborting the final compile? Certain kind of unsafe old c operations , stupid memory tricks , could be disallowed. It seems like switching to a whole new language is a 1000 ton solution for a 10 pound problem.
at 44:16 C++ is certainly not great for messing with frame buffer. Maybe in distant past yes(DOS times), but in age of GPUs C++ simply suck. You are not able to make anything for GPU in C++. Maybe in CUDA or Metal, but those are not really c++, right?
The C++ community, especially the standards committee, are clearly high on copium, when it comes to competition with Rust. New projects choose Rust over C++. C++ is too complex. The new standards introduce super complex stuff, and the average developer doesn't understand it. A hello world with std::println takes 4 seconds to compile. The thread attribute interface is way too complex for most developers, and the template magic slows down compilation for everyone. I can write this stuff, but I don't want to impose this complexity on my colleagues, unless there are very clear and significant upsides. The writing is on the wall, Rust is slowly replacing C++ and C. Fighting too hard against it will just make the language more complex and accelerate the transition. Don't ruin C++26. Let it fade with grace. It will not disappear, but it will be less relevant. Great talk!
"I've stopped writing papers, I only write anti papers" ... As I grow up / old I get the feeling these kinds of people are the true generous protectors of humanity... Even willing to be seen as jerks to protect the people they love so much, maybe even too much for their own good... Frank Herbert comes to mind
Loved your talk but you missed a couple of things like rust has cargo, one tool to manage dependencies in a semantic version ing way with locks. Rust projects are usually always compiled from source, hence no dynamic linking. Most IDEs are cross platform and in some areas it is not doing well because we need another 5 years of engendering for it like what qt is for cpp in the UI field, using signals and slots and a event loop. Rust was also not plagued from Microsoft's initial influence to make special traits which work only on windows. I also think that your argument that "cpp gets more completex over time" as with mingw (gcc) , clang and usage of cmake (also vcpkg, Conan and even nixpkgs) makes cpp much more approachable. Especially since we have LLMs for help as well. Love your talk, just my 2 cents ❤🎉😅😊
All this talk about artificial heart firmware is a red herring. What makes a piece of software acceptable for a safety-critical system is not the language it's written in--it's the results of formal verification and testing. Software, just as in a natural language, never deserves trust on account of the language chosen to write it.
3 місяці тому+3
The audience is so annoying on this presentation 😩
3 місяці тому+1
It's like they came to the presentation to argue instead of to listen to what the presenter had to say..
It is a dangerous way to think. When Rust can do what C++ can do better, C++ death entropy will definitely increase. Remember Rust improves at a much faster rate than C++, C++ is stuck with proposals that will take years to be approved and go through committee. For many people C++ is dead, and Rust has replaced their use case, don't be surprised more people find Rust can cater their use case better than C++ as time goes by. Just give a compiler flag to disable C++ features.
Everyone's tolerance of accidental complexity seems to be wildly different. I got off the C++ train in 2002. I will never get back on it. C++11, C++20 these are all bridges after bridges after bridges too far for m
Rust solves a stupid problem. If your program has tons of pointers to individual things floating around changing ownership all day, you are doing it wrong.
Stop adding new features to C++. I started hating the language when I had to deal with templates to write some code. It takes longer and longer to debug the code. Create JJ++ CCJ++ whatsoever. Leave c++ alone , let the optimizations to be done automatically on simple code by the compiler. I like the idea that there's some community but it just becomes something you do not want to touch other developers' code. You want to improve C++ ? Improve the compiler to optimize the code. Add libraries for general problems. Create better string parsers. Leave C++ as is , or some popular simple languafe will just be the new C++ . You are killing it by flooding it with stupid use cases like " Oh , that prevents me copy pasting".... In fact , what makes you copy paste is the strong types of C++ . And it makes you write better code. You are just trying to "workaround" it and also killing it...
Templates is just an example. I'm generally against adding new features to c++. If you ask me , we should start looking for what features to deprecate .
First of all, great talk. C++ really needs to slow down the complexity madness (which it already has and is really unfixable) and embrace more simplicity. I love C++ and it's sad to see where it's going... but I must admit it already went too far, it's already "too broken to be fixed" and even slowing down bad proposals won't change anything actually. Rob Pike, gingerBill, Andrew Kelly, Jon Blow and many others already know this since ages, and I really hope they succeed. Let's face it, C++ is already legacy (like cobol, fortran and delphi). They're still there, but that's it, just serving it's own legacy.
C++, should go back to its root. Which is MATH. Stepanov & al. were all trying to create a mathematically correct language. Because math can prove anything. Instead of creating a group of persons that decide what to accept, we should create a mathematical process to prove the effectiveness of any proposal.
I'm not sure how we can mathematically prove how an addition to c++ is going to improve it's usability, but I see your point. It should be more about looking at the problem and coming up with a solution that will improve the usability alongside the feature set, instead of finding the most clever but hard to use solution. They should ask the users what they want to use.
The title of the talk is such a C point of view. Any decent C++ programmer knows that C++ should be ++C.
Simplicity is indeed a C point of view.
Exactly! C++ creates a temporary C, which you're not even capturing, so this is an entirely pointless copy.
If some big entity actually sponsored Sean Baxter to formalize his Circle C explorations, I think you'd be in a much better state. He's one of the few guys in the community that actually cares to make C++ safe and ergonomic
I don't want a safe language
@@llothar68 I don't want a language that constantly leads me to pitfalls and the worse choices
This was a really excellent talk, arguing for simplicity is boring and yet so essential to maintaining any language in the long-term.
But for C++ the simplicity boat has sailed a time ago.
"Too many chefs spoil the broth" is true when it comes to adding features but there are many proposals which are geared towards solving inconsistencies in the language and making it more flexible and we need these proposals. An example would be the ongoing "universal template parameter" along with adding "concept" template arguments and "variable template" template arguments. As a library developer, I can totally see this being useful. Although they are "additions" to the language, they do not introduce radical or unfamiliar ideas or mechanisms.
This is a very necessary and important conversation.
I think the comitee structure worked well enough at the time C++11 was released, but with the current size it seems to get problematic. More and more features without any overarching leadership and vision in one or a few people already seems challenging.
But then add to that people joining the comittee, fighting tooth and nail, getting their feature and then leaving seems to be an increasing trend. A couple month later you see them changing positions into C#, Python or Rust role never to have to live the decision. I understand being frustrated with the process and getting burned out by it, fundamentally just trying to help. But this structure seems to not make C++ sustainably better.
Death by committee is a very old problem.
I don't particularly like Sutter's CPP2 syntax but I do like the idea of replacing C++ with a new C++-like language where we dump the old bad stuff and take only the good new stuff. Eventually, CPP2 might replace C++ but that's a long time from now. A CPP2 programmer will also have to know C++ for years. Still, it seems like a better path than switching to a whole different language.
A new language that is basically just cleaned up C++ with coherent and consistent interfaces and semantics with essentially the same syntax structure as C++, would be good. (Including the standard library.)
The problem I see accross the board is the replacements are all taking so many liberties with the clean sheet opportunity that they are really just creating completely new languages rather than improved C++.
About optional and maybe_view, it just baffles me why we can't just instantiate optional with reference types. It feels like an obvious solution to that problem.
you can use std::optional.
Optional reference is pointer.
1:07:09 I think the speaker misunderstands Herb Sutter's Cppfront if he thinks it "adds more stuff to C++" and makes the language "more complex".
Cppfront is all about simplifying C++ and making its rules more consistent. It's not just the addition of yet another opt-in syntax built on top of the existing syntax - it instead completely replaces the existing syntax with a simpler one. Whether it will catch on and people will want to learn the Cpp2 syntax is one thing, and whether it succeeds in simplifying C++ is another.
But cppfront would be completely source-compatible with c++ right? In fact I remember one of the selling points to be we can still use the resulting generated c++ so that we don't loose the "investment" when cppfront is discontinued/not developed further
So it would mean that cppfront would be built "on top of c++", hence it "adds more stuff to c++". It would only be a simplification if it breaks c++ source compatibility, but in that case it might as well be another language
@@notruff If you only ever use Cpp2 mode, it is a simplification because Cpp1 and its syntax largely becomes an implementation detail that you do not have to worry about. In the future, a Cpp2 compiler could be created that skips the Cpp2 --> Cpp1 translation step entirely.
If you add another syntax to the language the language goes from having 1 syntax to 2. That means everyone working on this language in a corporate environment will need to be at least passingly familiar with BOTH syntaxes. That makes the language more complex, period.
Go(lang) has evolved since Go 1.0 in 2012, but the changes have been tiny except for generics in Go 1.18 two years ago. It IS possible to keep a language small and simple over time, but it takes strong dedication and the courage to say “no!” even to nice and useful additions that would make the language just a little bit more complex.
Go is good for simple cases. You do not have Sum type in Go. So it's a pain to use the language when you need one, and you write "workarounds" to simulate a sum type and even then, in a type unsafe manner.
@@sirnawaz go to me isn't mature with many design choices that are insufferable such as the absence of warnings, includes from remote repos, list manipulation, and the case, upercase and lowercase as a private or public variable exposure classifier -- finally to finish off, it advertises some relative simplicity through explicitness, yet it didn't address nullpointer exceptions :>
It better move and improve!
It sounds like "Let's freeze C++ as it is now, and let it slowly die out. It's just a tool, after all."
After watching both Sean Parent -- CppNow 2023, and David Sankel -- CppNow 2024, I can't help but getting the impression that Adobe internally decided to move on to Rust or whatever "memory safe" language while putting their existing C++ code base on a maintenance mode. If that is the case, I do respect your company's business decision. I, however, still want to see how C++ evolves with Bjarne&Gabriel's profile as well as Herb's Cpp2, and I genuinely hope for them to succeed to turn the tide in favor of C++.
edit: typo in names
Yeah, I'd like to see Sean Parent and Chris Lattner have a long format discussion. That'd be a nice incarnation of what Sean alluded to in last year's talk about how C++ can start to participate in the 98% of machine performance in GPU and TPU units. For example, I couldn't get the Halide team to talk about Halide futures vis-a-vis Mojo and the state of the art in auto-tuning for hardware (and vice versa from the Mojo team). The machine-level technical overlap between generic image handling code (say boost::gil), optimized image processing code (say Halide) and optimized AI code is very large. User's and algorithms really want to use domain specific languages expressed in C++ or Python, but the dynamism of hardware evolution these days requires addressing this question starting at the compiler level, not just more and more gymnastics with template metaprogramming.
i don't know how much this talk differs from all the mantra people singing nowadays 'stop using c++ for new project, use rust instead'. i have high hope on circle.
Hmm, maybe it's just me, but I don't see a language being "freezed" as something equated as "dying". I mean C is still widely used & it's not a language that constantly adds new stuff (the latest one IIRC is just a "_Generic" keyword which itself is added only on C11 I think? so yeah)
Adobe is dying. It has been scamming users with its cloud service subscription fees.
29:35 David’s talk: “up to code” ua-cam.com/video/r_U9YFPWxEE/v-deo.html
Thank you for doing the good work of stopping the complexity creep of C++.
Man, this man is officially saying what everybody thinks. It's really not easy anymore to find (good) C++ developers. It's an incredible complex language with many foot guns!
If the standards committee tries to remove pointer arithmetic or add mandatory bounds checking (that cannot be disabled at compile time), I'm dumping C++ and moving to C.
I like the intellectual honesty of these C++ people. They are a nice bunch 🥰.
Edit. Seems like C++23 will be my last version 😂.
Edit2. Bjarne Stroustrup wrote that paper about ship Vasa, seems like that's been totally forgotten...😢
You basically attribute to C++ committee what your company do to its customers. And adobe customers are doing the same as most programmers with the language. Isn't it ironic? (Without the monthly fee)
About C after K&R (that I recall you saying that you didn't care about), I would say that C99 is actually another cautionary tale - it added lots of "cool" features (instead of being letting C be C) - but many were sort of rolled back in C11 due to a lack of adoption.
I relate to 57:00 a lot. When I use C++ it looks like someone writing python with different syntax. When I see people who complain about C++ being complicated write C++, it looks like completely unreadable code that I could not understand in a million years because it is 90% abstractions and unintuitive ways of doing things.
Outline of the talk
1:33 C++ vs Rust can coexist.
47:00 The C++ standards committee is dysfunctional.
1:12:00 Discussion
David is spot on with this. The direction of C++ has been concerning to me for a while now. I have complained about it at my job multiple times. It makes me worried for things like job security, because I really like C++ and enjoy working towards expert knowledge in the language, but the choices that have been made make me feel like its a dying language. We will see where it goes, I have little faith that this talk will actually change anything with the direction.
"How safe is C?" "...C is safer than assembly."
You leave assembly out of this.
This is a great talk. Although I'm not an expert in C++ , I do enjoy it greatly and I do fear for it's future. I will probably have to look into some Rust for work at some point and I'm already working on Kotlin projects. To say I'm not a fan of the Rust syntax is probably an understatement but a lot of languages, including the C++ replacements all seen to be using a similar syntax style. I've seen several videos that demonstrate unsafe features of Rust so I wonder if it should be described as a memory 'Safer' language instead.
I love like, how, by minute 9, it is clear that this is a soft spot and everyone in the audience has something to say about it. Great talk!
Oh man he didn't know about the "Safe C++" proposal
Trying to give a presentation to a group of c++ devs is akin to herding cats. Just shut up and listen to what the guy has to say for a bit, and then have your discussion after the talk.
First Half: C++ is getting a lot of pressure because it's not memory safe.
Second Half: Just let C++ be C++ and there's no need to change it too drastically.
Hmmm?
But actually, I like and agree with everything up until the part about Herb Sutter's cppfront. Because I really like cppfront. I'm not sure how familiar David is with cppfront but it's actually intended to make C++ simpler. I think the way to declare things is much more elegant, consistent and easier to teach. Isn't that the intention? OK, so it doesn't look exactly like the old C++ but then the old C++ kind of sucks and most people agree that it does. And I don't think cppfront changes that much about C++ anyway.
There's not that much new in "Herb's C++" as you call it. It's only a few things that make C++ safer and simpler. You wouldn't hire people who know _only_ cppfront. You would hire people who know C++ as usual and who could maintain old code but when writing _new_ code would write it in "Herb's C++". It's just like when they write a for loop they might write it now as a range for loop instead of the traditional style. They still know the traditional style. It's a long process just like the process to transition to Rust.
If you don't do this I believe C++ will eventually die although very gradually. Yes, people now who try to write games in Rust might return to C++. But it's not because they think C++ is good (or else they never would have gone to Rust in the first place). But only because C++ is the only other choice for them now. Because there is a need, something WILL eventually come along to replace C++ for games, too, unless C++ itself evolves to fulfill that need.
Herb's stuff requires too many colons and equal signs. That's a no-no.
I think the first half isn't about it getting pressure, its about saying that its ok to give up some territory to that pressure. That leads into arguing for C++ to hold on to the rest by not changing too much to try to compete for markets its ill suited for.
I think the argument agains "Herb's C++" was it adds another layer to already existing thing, therefore it complicates the language. People can't just throw away their existing codebases so it's not a choice to "not learn the old C++", therefore "the new C++" adds more stuff to learn.
Herb was aware of that. Whenever he talks about cppfront, he says it's an opportunity, because we don't have code written in this new thing, so we can change/break it as much as we want. I don't think he have some strategy on "transition" tho (from old codebases)
@15:04
"18.7% of C++ engineers said Rust is another tool they use" ={combine this with a total number of Rust and C++ users}=> "99% of Rust users are also C++ engineers"
Great talk, and good luck with writting anti papers, because c++ after '11 is really moving into 'academic' space with complex and not really usable/complicated stuff even for simple subjects.
I completely agree, C++ Is becoming a complicated mess, I miss not having clear arguments to a function, to just have a function and not a template, things need to get simpler, easier. I use C++11 and some of the new stuff, but if a thing is too complicated to learn I just don't even bother, if it's a template with ...args or something similar I just don't. I want to write speedy code and have some control of what is going on, not to make my life to learn all the nooks and cranny's to be able to use this things
They should make a new language format with completely new syntax (like C++2 or idk). That way it is compatible with all old code, still is C++, but the compiler speed will improve 10x if done correctly from the beginning. Especially with modules this should be possible!
Awesome talk! 26:40 Not only animal names ... around 50-60 percent of the words that you used in this talk have Latin origins. C is truly the Latin of programming languages [and Fortran is kind like ancient Greek :) ]
I might put Algol as Latin. 🙂
@@jimhewes7507 good point
Maybe at some point a language like "SimpleC++" might be needed, that contains only a subset of libraries and properly handles "old" code.
1:03:30 Experts-vs-nonexperts is a false dichotomy. Someone who approves of an idea as "really clever" is either right or wrong, regardless of the level of expertise of that person. An expert's opinion is not made irrelevant simply by her being an expert. If introducing something into the language is more complicated than it's worth, then anyone who thought otherwise was simply wrong, regardless of expertise. Language features do not pick a side between being expert-friendly or beginner-friendly, they pick a side between being well-designed or poorly-designed.
Perhaps it's my bias working in languages that do not support method overloading, but the examples of interfaces where the action of the method is distinguished only by the types of the arguments passed in often make for very difficult to read documentation and more difficult to read code.
That was very informative overall!
Well, he's right... when I need a memory-safe language, I just use Rust. When I need less constraint overhead, I use C++. I don't need C++ to become an unmaintainable lame copy of Rust.
I feel like language features are way more important in such talks than library ones.
I'm glad that std::optional with ranges support comes in C++26 and we'll have some pretty cool functional-programming with it's monadic functions and ranges pipe operator, but I would be fine with whatever version of that even views::maybe kinda seemed reasonable to not introduce weird interface to optional, but that all just library meddling.
If talk starts with Rust then we should focus attention on safety of language features itself and not library ones, like for example the thing that C++ for most stuff got worst possible defaults that make your code very error prone and/or ugly afterwards after you fixed that by specifying all function signature stuff like [[nodiscard]] constexpr blah-blah-blah. The syntax where we would specify other way around that something is in fact mutable (not constant) would be less error prone. And I understand that we can't just switch all default because we have legacy code that should be somehow supported, but still I think any thought in that direction should be encouraged just like cppfront, but as a cpp standard feature.
Given that the language is so complex nowadays, and that one of its main focuses is backwards compatibility, wouldn't be a better idea to literally "freeze it" so nothing else can be added to it?
A really interesting discussion. I haven't tried Rust yet but avoiding memory problems does sound good. My gut feel, though, is that if Rust forces a programmer away from describing their solution as they visualize it, other kinds of bugs and productivity problems will rise to take the place of memory problems.
Rust syntax... aaargghhh...
It's not even about syntax for me - I could live with that. My biggest gripe with Rust is that it forces huge dependency trees on your project. The language itself and its STD library have lots of features missing (compared to C++) and you end up depending on hundreds of 3rd party "crates", full npm-like style,. even on a rather small project.
I just don't see any project surviving for years in such environment. Unless you're Mozilla, Adobe or some other large entity who can afford having their own standard library.
I have a growing suspicion that Rust is an attempt to make small/mid sized software companies to go extinct. Thus all the push in that direction. Having them creating enough Rust code to train AI on it before they go away would be a plus.
This talk was probably very fun in the room, but the information density is so low. It could have been condensed to 30 minutes or less.
The whole premise of his talk is that C++ is getting too complicated because it is increasingly difficult to learn the whole language. Not only is it too large but also contradictory in many ways.
But the whole idea that a language needs to be learned in its entirety is a misguided viewpoint that is all too common amongst programmers. Even Bjarne Stroustrup claims to not know all of C++
What really matters is how well you know how to use a language for any given purpose. If you know how to use a subset of the language well enough to accomplish your goals, then that should be all that is necessary.
That's why C++ continues to be so widely used, because so many programmers find it to not only be useful, but the only language that allows them to accomplish what they are trying to do.
well because it's not design for students and beginners 🥴🥴
The expectation is not memorizing the whole thing, the expectation is coherent and consistant interface, syntax, and semantics so their is minimal learning curve and surprise when choosing to utilize a new component.
Not knowing parts of the language becomes an issue when reading - really, reviewing - other developers’ changes.
Just to pick on another language, I’ve been using Swift a lot more frequently recently, and the speed at which the language has grown has led to a lot of inconsistencies in the language. I can control what I write, but i still have to review others’ changes. And reading those changes? It’s become a chore, because it’s hard to infer what a new feature does due to those inconsistencies.
Obviously you don't need to know everything, but the set of things you do need to know is still enormous, you can't deny that.
For example, writing something as basic as a vector suddenly requires expert-level knowledge in the language.
Meanwhile, I can trivially write a vector in C/Zig/Odin etc in less than 100 lines of code.
Yes, please, the next c++ release, just fix all the features.
These days a C++ programmer is Achilles trying to overtake the tortoise of standardisation.
Very interesting, talk.
Seems the flip side of this perspective, which I think has a lot of merit, is the one put forward by those asking for the C++ standard to not be ISO anymore? Some of those have said they don't want to contribute anymore in the current structure because because it is too difficult to get new things in.
So the fact that these types of "prolific contributors" are being repelled by the "stewardship" function perhaps shows that the structure is perhaps beginning to self heal?
Is there "hope" in that?
Value of old good Fortran and C code is self-evident.
C will outlive cpp
Because it was first. But Cpp will remain as long as there is C
This talk should have been a keynote.
Horses didn’t become worse when cars were invented, but cars don’t require fuel when they are not used. Cars can take you from A to B much faster and if everyone starts using cars and you still rely on horses you can’t compete in the marketplace.
Fascinating to hear an honest self-critical talk about the existential crisis in C++.
I ported one (pet) project to Rust.
I'm hesitant to start a Skia project in Rust...but I'm contemplating it.
1:08:02 This, exactly. The trend is horrifying. Hopefully, it won't become kotlin, where there is a thousand ways to do anything and you got to know all of it. Or god forbid android api.
47:00 Loud ticking bomb sound appears .... 😶
Even garbage collected languages need a borrow checker. C++ could never make it there. They could focus instead on Dlang, the one true C++.
I didn't expect this to be this interesting. Thank you so very much ❤
Thank you for your comment. Glad to hear you enjoyed David Sankel's presentation!
Do the TRACTOR-people not see a problem with the fact that Rust relies on ecosystem, i.e. code that is arbitrarily/accidentally, and temporarily, verified as safe with much less standard modules backed by the actual core language maintainer?
There *is* a high-performance memory-safe language that isn't Rust: Pony.
i prefer the syntax showed at operator= a lot more than what we have today lmao
"What can make C++ less capable?" - The standards committee
I laughed
What an excellent talk
1:27:16 What did the guy say?
"We still wouldn't have reflection"
"We still wouldn't have reflection."
What percentage of those C++ devs that also used Rust chose to use Rust vs were told by mgmt to use Rust?
I was in the room when David Sankel claimed pretty much the opposite: ua-cam.com/video/ady2mUIQpt4/v-deo.html . I approached him afterwards and expressed the fear of what pulling even more people into an already inflated committee might do. 2Y later, I think he agrees.
ua-cam.com/video/qTw0q3WfdNs/v-deo.html I really enjoyed the lecture and I would really encourage shrinking this committee down and stop messing with the utility of C++. I'm sticking with C++17 personally, the changes to make it more javascript like are annoying.
can we have another name than std::maybe_view ? i hate pessimistic naming
Was memory safety actually invented to reflect back to the author that they have unsafe memories? Exaggerated memories? Deceptive memories? Therefore to inspire meditation asking “Have I deceived someone? Was the earliest reflection through my code deceiving me? If it wasn’t for C++ where else would I receive this reflection?”
Every time I watch a David Sankel talk I feel like this guy has won life. He loves to talk about his kids every chance he gets being genuinely proud of them.
great talk, thank you
the talk should be 5 minutes 90 is too much its 2024 god dammit
No offence, but I've been watching for 40 minutes and I don't think this talk has gone anywhere useful yet. Maybe it was fun for people to just shoot the breeze in the room?
He’s shockingly accepting of questions and hears everyone out, which really slowed down the first half. It really picked up at around the hour mark, and there are some good points.
Is it just a matter of creating code checkers for cpp that find memory issues and other problems and then aborting the final compile? Certain kind of unsafe old c operations , stupid memory tricks , could be disallowed. It seems like switching to a whole new language is a 1000 ton solution for a 10 pound problem.
okay i loved this talk.
Poor guy 😂
Everyone is grilling him 😂😂
at 44:16 C++ is certainly not great for messing with frame buffer. Maybe in distant past yes(DOS times), but in age of GPUs C++ simply suck. You are not able to make anything for GPU in C++. Maybe in CUDA or Metal, but those are not really c++, right?
The C++ community, especially the standards committee, are clearly high on copium, when it comes to competition with Rust. New projects choose Rust over C++. C++ is too complex.
The new standards introduce super complex stuff, and the average developer doesn't understand it. A hello world with std::println takes 4 seconds to compile. The thread attribute interface is way too complex for most developers, and the template magic slows down compilation for everyone. I can write this stuff, but I don't want to impose this complexity on my colleagues, unless there are very clear and significant upsides.
The writing is on the wall, Rust is slowly replacing C++ and C. Fighting too hard against it will just make the language more complex and accelerate the transition. Don't ruin C++26. Let it fade with grace. It will not disappear, but it will be less relevant.
Great talk!
Surprised he didn't bring up Carbon.
He did.
Irregular simd is correct, sorry ;)
Whatever happen to assembly 😂
I'm glad a C++ voice acknowledges that Rust is a thing, I'm still surprised by the amount of deniers
Came here to watch a video on C++ but all I heard about over and over again was "rust", "rust", and some more "rust"
You could use D
What am I watching? Is this a rust struggle session?
Denial.
works at adobe... okay... I hope the money is worth it. Probably is.
"I've stopped writing papers, I only write anti papers" ... As I grow up / old I get the feeling these kinds of people are the true generous protectors of humanity... Even willing to be seen as jerks to protect the people they love so much, maybe even too much for their own good... Frank Herbert comes to mind
Tim Peters.
Loved your talk but you missed a couple of things like rust has cargo, one tool to manage dependencies in a semantic version ing way with locks. Rust projects are usually always compiled from source, hence no dynamic linking. Most IDEs are cross platform and in some areas it is not doing well because we need another 5 years of engendering for it like what qt is for cpp in the UI field, using signals and slots and a event loop. Rust was also not plagued from Microsoft's initial influence to make special traits which work only on windows. I also think that your argument that "cpp gets more completex over time" as with mingw (gcc) , clang and usage of cmake (also vcpkg, Conan and even nixpkgs) makes cpp much more approachable. Especially since we have LLMs for help as well. Love your talk, just my 2 cents ❤🎉😅😊
All this talk about artificial heart firmware is a red herring. What makes a piece of software acceptable for a safety-critical system is not the language it's written in--it's the results of formal verification and testing. Software, just as in a natural language, never deserves trust on account of the language chosen to write it.
The audience is so annoying on this presentation 😩
It's like they came to the presentation to argue instead of to listen to what the presenter had to say..
rust trojan :P
It is a dangerous way to think. When Rust can do what C++ can do better, C++ death entropy will definitely increase. Remember Rust improves at a much faster rate than C++, C++ is stuck with proposals that will take years to be approved and go through committee. For many people C++ is dead, and Rust has replaced their use case, don't be surprised more people find Rust can cater their use case better than C++ as time goes by.
Just give a compiler flag to disable C++ features.
Why is C used so much ? Shit ton of embedded development. A huge percentage of embedded devices don't have enough resources to run C++ much less Rust.
This Rust cultism is so tiresome.
If you need a borrow checker your code is bad.
Stop catering to inexperienced and bad programmers, it's degeneracy.
You do have a point.
Everyone's tolerance of accidental complexity seems to be wildly different. I got off the C++ train in 2002. I will never get back on it. C++11, C++20 these are all bridges after bridges after bridges too far for m
Rust solves a stupid problem. If your program has tons of pointers to individual things floating around changing ownership all day, you are doing it wrong.
But people keep doing it wrong, at a huge cost to society. If forcing people to use Rust solves that...
Stop adding new features to C++. I started hating the language when I had to deal with templates to write some code. It takes longer and longer to debug the code. Create JJ++ CCJ++ whatsoever. Leave c++ alone , let the optimizations to be done automatically on simple code by the compiler. I like the idea that there's some community but it just becomes something you do not want to touch other developers' code. You want to improve C++ ? Improve the compiler to optimize the code. Add libraries for general problems. Create better string parsers. Leave C++ as is , or some popular simple languafe will just be the new C++ . You are killing it by flooding it with stupid use cases like " Oh , that prevents me copy pasting".... In fact , what makes you copy paste is the strong types of C++ . And it makes you write better code. You are just trying to "workaround" it and also killing it...
Templates is just an example. I'm generally against adding new features to c++. If you ask me , we should start looking for what features to deprecate .
First of all, great talk. C++ really needs to slow down the complexity madness (which it already has and is really unfixable) and embrace more simplicity. I love C++ and it's sad to see where it's going... but I must admit it already went too far, it's already "too broken to be fixed" and even slowing down bad proposals won't change anything actually. Rob Pike, gingerBill, Andrew Kelly, Jon Blow and many others already know this since ages, and I really hope they succeed. Let's face it, C++ is already legacy (like cobol, fortran and delphi). They're still there, but that's it, just serving it's own legacy.
C++, should go back to its root.
Which is MATH.
Stepanov & al. were all trying to create a mathematically correct language.
Because math can prove anything.
Instead of creating a group of persons that decide what to accept, we should create a mathematical process to prove the effectiveness of any proposal.
I'm not sure how we can mathematically prove how an addition to c++ is going to improve it's usability, but I see your point. It should be more about looking at the problem and coming up with a solution that will improve the usability alongside the feature set, instead of finding the most clever but hard to use solution. They should ask the users what they want to use.
If you're going to switch from c++, why not use go?