Keynote: The Evolution of C++ - A Typescript for C++ - Herb Sutter - CppNow 2023
Vložit
- čas přidán 9. 06. 2024
- www.cppnow.org
/ cppnow
---
Keynote: The Evolution of C++ - A Typescript for Cpp - Herb Sutter - CppNow 2023
Slides: github.com/boostcon
---
C++23 is done. But C++ is not! In this talk Herb will give his personal perspectives on C++’s ongoing and very active evolution, updates on his cppfront experimental compiler, and why compatibility (and what kind, and how much) is essential to continuing to bring C++ forward successfully.
CHAPTERS
00:00:00 - Intro and roadmap for the talk
00:02:28 - 1. cppfront recap
00:10:00 - 2. cppfront: what’s new
00:10:10 - (a) 3 smaller new features showing simplicity+safety+efficiency
00:11:05 - simplicity, safety and efficiency rarely in tension, with the right abstractions
00:12:55 - chained comparisons
00:15:08 - named loops/break/continue
00:16:51 - main’s arguments
00:18:30 - (b) user-defined types
00:19:20 - explicit `this`
00:23:50 - unified `operator=`: {construct,assign}x{copy,move} is a single function (by default)
00:31:35 - virtual/override/final are qualifiers on `this`
00:35:05 - DEMO: inheritance
00:43:10 - (c) reflection and type metafunctions
00:54:23 - DEMO: applying type metafunctions
00:56:10 - 3. compatibility for C++
00:56:35 - John Carmack on compatibility in the real world
01:04:25 - C++ from C, TypeScript from JavaScript, Swift from Objective-C, Roslyn from prior compiler
01:05:45 - emphasizing and dissecting TypeScript’s compatibility story
01:07:55 - Dart: similar goal, but not designed to be compatible
01:19:25 - the “lost decade” pattern: lack of seamless compatibility will cost you a decade in adoption
01:20:45 - three “plans”: the “10% plan”, the “Dart plan”, and the “TypeScript plan”
01:21:00 - “10% plan”: incremental evolution-as-usual
01:21:50 - “Dart plan”: designing something new, not worry about compatible interop, competitive
01:23:20 - “TypeScript plan”: designing for something compatible, cooperative
01:28:50 - filling in the blank: A TypeScript for C++
---
Herb Sutter
Herb Sutter is an author and speaker, chair of the ISO C++ standards committee, and a programming language architect at Microsoft.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
CZcams Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org
/ cppnow
---
#boost #cpp #programminglanguage #microsoft - Věda a technologie
Honestly, I'm all for a TypeScript for C++
It's really not unless they have an amazing LSP, but I'm here for it! Typescript is frusteratingly unique and I wish more languages took IDEs more seriously
I absolutely positively agree 💯
At 50:32 - I've waited for this for so many years! Thank you, Herb Sutter. You are my hero! Honestly, I love what is happening with the language right now.
Anyone claiming they prefer old-style C++ over what cpp2 offers (so far) are suffering from Stockholm syndrome.
This is legitimately making me want to start using C++ again.
You must be easily impressed.
Bravo Herb, bravo. Excellent talk, hope it continues to gain momentum.
Best talk.
Thank you Herb. ❤
I saw the title and I have never clicked on a CZcams talk this quickly.
great talk 🚀🚀
This addresses one of my pet peeves with C++. Namely that a C++ class is a over-generalization. A good abstraction lets you state precisely what you mean instead of forcing you to be more specific or more vague than you need to be. C forces you to be too specific. C++ overshoots in the opposite direction and forces you to be too vague by default.
Good narrowed-down default class flavors is a big step forward IMHO. A good language shouldn't need guidelines - the best practice should simply be the path of least resistance.
Amen! I love the @value type or @interface type approach. Just use the straight forward 'type' in combination with modifiers to achieve the appropriate type semantics. The 'class' keyword has long grated on my nerves. Type with modifiers enables being bullseye precision specific to exactly what is needed/intended, and is concisely self documenting at the same time.
Here's hoping that cpp2 eventually becomes the standard. For the last couple of decades, C++ has been moving towards programming at a higher level of abstraction and more directly expressing intent without sacrificing efficiency. It's rare to write new or delete and std::optional has removed a lot of heap allocations in return values and delayed initialisation. I am no longer pessimistic about the future of C++.
that will depend on how the industry responds to this, it can go either way, but we can bring awareness
It will never become the standard
The Typescript way is 100% a great way to go about this. Even if you're coding javascript, you can load in typescript type annotations into your IDE and start benefitting from them when writing regular old javascript in your editor massively.
15:10 named loops: BLISS welcomes you to the future! (Seriously, as long as these things are reducible they are good! Great feature!)
My only feedback against named constructs is the philosophy against deeply nested code which is something I'm chewing on.
1:19:26 I would add C++ modules to this list. IIRC, I was playing with Clang modules around 2015 or something, hacked build systems around 2018, and the ISO C++20 raised the bar so high that all those early promising experiments were in vain. I don't expect C++ modules to become the new norm before 2030.
great speech! I choose Rust
"In tension" and "intention" was a bit confusing! :) Might explain the lack of hands that were raised.
I'm definitely in favor of this work. I'm not quite comfortable with the function call syntax yet since it seems quite a bit "busier" (or harder to parse?) than python or even existing C++. Maybe the busyness fades away once you actually use it for a while?
have you heard of Circle ? it implements a borrow checker for c++ and it actually works. The problem is that for now it's linux only and is closed source. Sean Baxter is the dev.
I do appreciate the consistency approach Herb takes - and the declarations aren't that much more odd than Go was at first and I very quickly go used to Go
I don't like extra typing. He got to make the equal sign in type definition and in function definition optional. In fact, just like C++, the equal sign in variable definition should be optional if the initialization value is in braces. The use of colon in variable declaration is just too distracting for me. I prefer the C++ way of just separating the variable and the type with a space. Some newer programming languages where the variable goes before the type also use only space as separator.
1:23:58 Another language which falls into (B) for C++ is Carbon.
Although they go a slightly different route compared to CppFront.
I'm looking forward to seeing what the new Carbon language becomes.
I would love a typescript-idea for C++. It would be so great. We can add things like compiletime reflection in a much easier way.. we can add things like the meta language Herb talked about previously. We can finally get rid of the extreme verbosity of the language. All the while maintaining full compatibility with normal real C++. I'm all for it. Also default package managers please! Please please for the love of everything please.
Few things i'd like to see: noexcept by default (and specify when you do want it), lightweight exceptions by default which are syntactic sugar for error code returns, const by default unless you specify something isn't const. Don't make me write a const and non-const version of the same function. Dont make me write a ton of overloads for copy and move.
I think variadic using and empty base class optimisation are the two reasons I’ve had to use private inheritance.
Its funny I always have considered python as the sister language to c++. They are just so complimentary in so many way.
At 17:12 perhaps args could be of type initializer_list or array to avoid the allocation?
Would it make sense to have explicit this in code (like python and rust)? A lot of methods are very tough to parse, especially combined with implicit default init.
Fantastic talk. I press my thumbs. We will see how things evolve and develop.
Given all the TS euphoria, there is some winner bias. At the beginning of TS, many purists in the JavaScript world flame wared TS. BabelJS was considered the good guy in this altercation between so-called JS purists and folks that understood the value of static-type systems. TS was simply considered by the JS oldskool folks as bringing Java to the front end and we all know how much cooler it was to simply hack JS instead of using all the back-end bulk stuff. Compilers were still quite new at the time (Grunt, Gulp).
TS would never have had this popularity without having Angular as its first and strongest supporter and flagship project. You had to use it in order to use Angular, period.
So nevertheless, good luck. 😶
I like private inheritance for wrapper types. If I am wrapping a type and I want to have a function with the same name and arguments as the type I am wrapping, then a simple using declaration is all I need to implement that function. With standard composition, I need to write a function which delegates to the wrapped object's function, which can get tedious. Plus if the wrapped type's function signature changes, then I have to make changes in my wrapper class too. That is not the case with private inheritance and using declarations.
Another thing that private inheritance is good for is simplifying registration to a global thing. Derivations can just provide a virtual function which is the hook that the global thing needs for each registering object. And no one else needs to know that my type inherits from this thing. Examples for this would be tasks that can run on a global thread scheduler. Or components of a logging system.
Cpp2 might have answers for these use-cases. In which case, fair enough get rid of private inheritance. But in standard C++, private inheritances makes sense in a lot of situations that you might not think about it.
cool
Would we have to resort to methods like extern "C" block around a #include so that C++ can use a C header? What would it look like for Cpp2 to use a C++ module/header? Would we be able to sprinkle the Cpp2 syntax in an existing C++ file?
Yes, you can interleave Cpp2 syntax and today's syntax in the same C++ file, including just #include any existing header you like, it's fully compatible because it's still C++ -- there's nothing different at the object/link level. Any Cpp2-syntax type/function/object you write is still an ordinary C++ type/function/object, just authored using a different syntax that I hope is more convenient.
Question: The statements "I don't support virtual inheritance" ( 34:17 ) is followed by an example ( 35:24 ) minutes later that employs something that looks like virtual inheritance. What have I misunderstood here. Is the virtual keyword repurposed to mean "base" here?
Virtual inheritance is a solution to what happens when two base classes inherit from the same class. Will members be duplicated or not? Virtual member functions are a different thing.
This is why I love Rust. These new language designs and paradigms aren't just "fashion", they're our literal language. To let a language stagnate is to speak Latin; worthless. Thanks for this work Herb! I hope you can make me give up on Rust one day 😉
I would have liked to see mention of the Circle compiler in this. The panel discussion two weeks ago mentioned it once:
czcams.com/video/jFi5cILjbA4/video.html
saying that nothing will come of it as long as it's closed source and controlled by one person. But what if it moves on from that in some way? As far as I know (which isn't much since I haven't spent a lot of time with it) it's also compatible.
circle's a joke fam
Google wants? Carbon as a replacement for C++. Apple intention is to use Swift everywhere. Can we call it Typescript for C++? I think we can. I am a c++ developer. IMHO C++'11 was the best (+fix for memory allocations that came in C++'17). All the crap that came to the language after that point..oh. I am happy that also some other people can see that crap and want some way out. I am not sure that cpp2 really is the way and not only moving the chairs on Titanic.
😮😮😮
I'm only half way through this talk, but I like the syntax so far. Could the default for what used to be a `const&` reference just be `&`, and what used to be `&` become `mutable &`?
I see what you did here
53:00 "Point2D is a value type, so it's totally ordered, so spaceship works" ... ?
I'm not sure how it's totally ordered in two dimensions without eg a Norm defined.
It's lexicographic ordering. Maybe makes no sense as a "natural" order in two dimensions but it's a valid one.
I assume it defaults to member wise, just like "=" does, though the meta-class could have a different policy.
Yeah, would be cleaner imo if it required equality, and then you could have ordered be more specified with the addition of ordering operations.
interesting
10:00
Why do I have sudden urge to descend back to C?
Putting snide, pessimistic remarks aside, redoing the syntax and defaults of an entire language a ridiculously ambitious understaking. Has it ever been done before in the history of programming languages?
I would like this work to succeed, I also think that the emphasis on compatibility is paramount, but I would go further and eliminate all gratuitous syntactic differences between Cpp2 and C++, to make it feel more like C++. For example, you could say "class myclass" instead of "myclass : type". This would make the language very easy to explain and adopt. I know it's Herb's baby and he likes the new syntax but there's really no need to move things around gratuitously if the same goal can be achieved without it.
Also, the language should be called C+2 (a.k.a. Cp2), not C++2 (a.k.a. Cpp2).
I'd actually like to see moving away from the redundancies that C++ has. I like the idea that anything beyond the primitive types is declared with 'type' keyword in combination to modifiers like @value or @interface. In fact, I just really love this approach.
The 'class' keyword has long grated on my nerves as it just conjures up too much OOP laden baggage for my taste (and mind you I've dealt with C++ since the days of the original cfront). These days there's just a vast amount of C++ programming where we're dealing in conjuring up user-defined types but we're not necessarily up to our chin in an overall OOP design paradigm. And user-defined types really do need to vary in semantic flavor of category such as @value and @interface, as two examples, illustrate.
There is nothing "gratuitous" about it -- it's about a consistent syntax. The reason you prefer the old way is because you're used to it. If the new syntax was meant to not change things, then it would be the same as the old syntax, and thus would be completely pointless.
Or, to put a sharper edge to it: Why would you gratuitously ruin the new nice, consistent and clean syntax just to make it more familiar to people who have already decided to switch away from the old (clunky) syntax?
If you *truly* prefer the old syntax, just stay with "cpp1".
During a cppcon presentation a few years ago, Herb described how he believed that types should go on the right.
In many situations, we already right types on the right using `auto`.
He described then that he thought this would make a better standard: "foo is a bar with value 3"
I like it well more then Rust, though I'm still not that happy with the syntax (I don't like postfix type declarations, parsing a name before a clear declaration is miserable) but otherwise I like the idea.
I suggest to keep C++ syntax as it is, but include a switch to turn off all the legacy C semantics that drags C++ down.
Certainly, it looks like Mr Sutter has done a good job in inventing a new sleak syntax. It looks very well thought out, clean and coherent. A big effort! But, since he invoked a lot of other languages, big names, and analogies. Let's consider rust. Is rust a thing, because of it's syntax? In my opinion, the good thing about rust is that it comes with a package manager and an easy way to integrate and make use of other libraries (the bad thing about rust is that, that's where the easy part ends). Why is JavaScript such a thing? Because, of course every browser understands it and because npm! Now TypeScript is used a lot in this talk, but did everyone ditch JS for TS right away? No, right? So, the "decade" that Mr Sutter invoked also applies for Typescript adoption. I fail to see the argument that full compatibility makes things faster. Smoother yes, but faster? The length of the Python 2.7 bar ist just an example of the step that you introduce with incompatbilities. But how much faster would 90% Python 3.7 achieved with full compatibility? I mean there's some cost, some big change, otherwise it would have been 2.8 and not 3.0. Even fully compatible approaches need time to find widespread adoption. But anyway, moving on, why is Python such a thing? Sure it has nice syntax, and also it's interpreted (execution is a 1-step process) and yes it's probably the fastest way since Excel to go from data to producing a visual (many aspects that C++ doesn't compete with) and of course also beause it has packages. C# has nuget to which everyone can contribute easily. And btw, C# had the same .NET Framework 4.8 to .NET Core (now .NET X with X>4) transition. And it was also very smooth, but ironically .NET Framework 4.8 is supported longer than any new .NET version that is realeased after it and I still know of .NET 4.X projects being in production. So, again, takes a decade of adoption. It cannot be expected that cppfront takes the C++ world by storm and it will also have to fight very hard to be adopted and it will take at least a decade as well, despite full compatibility. Dependency management and integration is a thing. And this comes even before the build process. And from that perspective, cppfront introduces another dependency in a system that doesn't seem to handle dependencies that well. So, I think there's still some problems waiting to be solved before cppfront can even have a future.
I think i liked his earlier iteration. this feels a bit too spartan. I've never liked the python approach to code structuring. I feel curly braces are a perfectly fine way of delimiting scope.
Not sure what you mean, it does use curly braces for scope, the syntax allows you to omit the curly braces for a single expression function bodies, which many languages have, it's not particularly a python thing
@@meowoasdgjoiagjoi Even cpp has it in if-statements and loops.
Dart failed and TypeScript is a success.
Therefore...
A TypeScript for C++ must also be a success.
how about following through with all the stuff from your previous talks first.
With changing the syntax to CPP2, C++ is both a much better language and it loses its place as a C-compatible layer (headers, etc). Both of these changes are good, C++ needs to stop pretend its a viable system api layer.
For a C compatible layer you would write header files in C and then implement them with C++. CPP2 could be similarly compatible if you write C++ header files or modules that are implemented in CPP2. But I just hope it doesn't get over complicated when adding new syntax on top of the already convoluted C++ syntax. It will be hard to get this TypeScript for C++ working with seamless backwards compatibility.
Just standardize Circle and make it work under windows... it has all your planned features and more, and it's metaprogramming model is both easy to understand and offers unlimited power to the programmer, unlike the constexpr model and its horrendous amount of gotchas.
As time goes by Cpp2 looks less and less like C++.
This is very much a good thing. :)
Hype
Only about five people on Earth with the juice to get this done, Herb is one of them.
C++ isn't already a TypeScript for C?
Well hence "Refresh C++" I guess. Makes sense to me.
The reason the compiler is called "cppfront" is a reference to the original version of C++, "C Front".
C++ was the "typescript for C", this approach would be "typescript for C++"
Honestly, I've been doing C++ for a little over a decade now, I started in 2011 during my first year in CS and I've been in love with the language for a while but I hate what it is used for and what kind of people pick C++ as there go-to language for everything. It's more of a cult than a language and TBH it is no longer suitable for 90% of the projects nowadays. My recommandation is drop it. Let it be a low level language, kind of assemblerish but more elegant even though I'd consider C and rust better candidates for this role. C++ is agonizing because people misuse it and because of it's poor interoperability with other languages.
Respectfully disagree,
“people misuse it”, that’s the beauty of the language, it not restrictive like other languages.
“poor interoperability”
C++ has great interoperability with other languages. It’s not hard to language bindings for python, or .NET, even lisp
@@Danielm103 what other languages do you use? How skilled are you with them?
I'm not looking for troubles I'm just trying to elaborate on my claims.
You can write anything faster in Python or JavaScript than in C++, these languages has pretty much the same versatility but are way easier and faster to write.
Regarding interoperability, .Net framework have a whole language family and tooling to interface with C++ that cost millions/billions to create and maintain. Python interoperability is only made easy by tools like pybind. Anything else you'd do to interop with C++ would be exposing a C API through a library and then easier use it as C or make a wrapper.
I stay on my opinion, C++ is not suitable for 90% of what it is used for RN.
why can't this be the new big thing in C++ 26?
because the committee isn't interested in that
@@kirillholt2329 Well part of the committee is interested in parts of the proposals used for cppfront, but they are also against some other parts or there is no consensus on them. So we can expect C++2X or 3X to have some of these things but definitely not as is like this
Just use rust
I don’t get the TypeScript comparison at all - cpp2 seems to make things far simpler and more declarative (assumes you’re a sane person who wants to do reasonable things) and all with far less boilerplate
TypeScript is a language for creating a lot of intermingled boiler plate for defensive programming against the unreasonable (which sounds more like cpp really…)
His point is not about the language features or syntax themselves, but about how typescript managed to offer itself as an inplace substitute for JS projects, which immensly helped in its adoption.
Poor man...
am i the only one that finds this syntax dreadful...
no, that syntax is hard to look at
Can you explain why you think that so there's a chance it could be improved?
Yes.
Sure, it's a bit odd. A bit Pythony. A bit un-C-like. But C is a huge ugly gargoyle with welds and patches and welds ON the patches. It's got knobs on, and stitches around its forehead. It's like the English language: more exceptions than rules. Overly complicated. Badly thought-out.
It's time it became more streamlined.
This syntax makes perfect sense, except for namespaces.
Language diversion. Splits and divides the community, and dilutes the impact of any and all contributions. Let's get sockets, ffs, in c++ before we split-off with all these stupid diversions. Let's have ABI break so the MS standard library timings actually work when the user changes the wall clock. What a joke!