C++ Should Be C++ - David Sankel - C++Now 2024
Вставка
- Опубліковано 12 вер 2024
- www.cppnow.org
---
C++ Should Be C++ - David Sankel - C++Now 2024
---
Between memory safety legislation, calls for C++ successors, and Rust's rising popularity, many conclude C++ is going through rough times. Are complaints of fundamental insecurity, over-complexity, and committee dysfunction overblown? Either way, what's to be done?
This talk pragmatically evaluates these developments and makes the case that a focus on improving people's lives is the ideal response. We'll see how this outlook leads to guidance on the libraries we build, the talks we give, the features we add, and how we conceptualize C++'s role in humanity.
---
Slides: github.com/boo...
Sponsored by Undo: Debug your hardest C++ bugs with time travel debugging → Learn more at bit.ly/cppnow24
---
David Sankel
David Sankel is a Principal Scientist in Adobe's Software Technology Lab and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He was the project editor of the C++ Reflection TS, is the Executive Director of the Boost Foundation, and an author of several C++ proposals including pattern matching and language variants.
---
C++Now 2025 - 28th April - 2nd May
C++Now is an annual onsite international C++ programming and coding conference held in Aspen, Colarado. For all C++ developers, C++ software engineers and those involved with the C++ language, CppNow provides an indepth and technical content provided by the best and brightest C++ experts of the C++ world.
Annual CppNow Conference - www.cppnow.org
/ cppnow
/ cppnow
/ cppnow
/ cppnow
mastodon.socia...
Video Sponsors: millennium and think-cell
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
UA-cam Channel Managed & Optimized By Digital Medium Ltd: events.digital...
---
#boost #cpp #cplusplus #cppprogramming #cplusplusprogramming
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
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.
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.
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.
"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.
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++.
29:35 David’s talk: “up to code” ua-cam.com/video/r_U9YFPWxEE/v-deo.html
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.
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?
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.
"How safe is C?" "...C is safer than assembly."
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.
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.
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)
Thank you for doing the good work of stopping the complexity creep of 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...😢
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!
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)
These days a C++ programmer is Achilles trying to overtake the tortoise of standardisation.
@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"
"What can make C++ less capable?" - The standards committee
I laughed
Value of old good Fortran and C code is self-evident.
The title of the talk is such a C point of view. Any decent C++ programmer knows that C++ should be ++C.
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.
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?
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?
That was very informative overall!
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.
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.
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. 🙂
There *is* a high-performance memory-safe language that isn't Rust: Pony.
Surprised he didn't bring up Carbon.
He did.
47:00 Loud ticking bomb sound appears .... 😶
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.
Irregular simd is correct, sorry ;)
can we have another name than std::maybe_view ? i hate pessimistic naming
This talk should have been a keynote.
Yes, please, the next c++ release, just fix all the features.
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 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!
Even garbage collected languages need a borrow checker. C++ could never make it there. They could focus instead on Dlang, the one true C++.
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.
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.
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 ❤🎉😅😊
You could use D
Poor guy 😂
Everyone is grilling him 😂😂
Tim Peters.
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.
C will outlive cpp
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!
What am I watching? Is this a rust struggle session?
"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
great talk, thank you
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.
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
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.
What an excellent talk
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.
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.
works at adobe... okay... I hope the money is worth it. Probably is.
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.
okay i loved this talk.
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 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...
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.
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.
BAHAHAHAHA GOOD ONE 😂😂😂
rust trojan :P
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 .
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"
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 talk should be 5 minutes 90 is too much its 2024 god dammit
If you're going to switch from c++, why not use go?