Plenary: Cooperative C++ Evolution - Toward a Typescript for C++ - Herb Sutter - CppCon 2023
Вставка
- Опубліковано 12 вер 2024
- cppcon.org/
CppCon 2023 Early Access: cppcon.org/ear...
Access All 2023 Session Videos Ahead of Their Official Release To UA-cam. At least 30 days exclusive access through the Early Access system. Videos will be released to the CppCon channel on a schedule of one video per business day, with initial releases starting in November.
---
Plenary: Cooperative C++ Evolution - Toward a Typescript for C++ - Herb Sutter - CppCon 2023
github.com/Cpp...
C++23 is done. But C++ is not! In this talk I’ll give my personal perspectives on:
- C++’s ongoing and very active evolution;
- The latest progress updates on my cppfront experimental compiler, and what I’ve learned about modern ISO C++20 and C++23 in the experiment (github.com/hsu...
- Why compatibility (and what kind, and how much) is essential; and
- Why we should aim to keep bringing C++ forward successfully by cooperating and being part of C++’s ongoing true evolution via WG 21, even though that’s more work than pursuing a new fresh-but-competing evolutionary path.
---
Herb Sutter
Herb is an author, designer of several Standard C++ features, and chair of the ISO C++ committee and the Standard C++ Foundation. His current interest is simplifying C++.
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd: events.digital...
---
Registration for CppCon: cppcon.org/reg...
#cppcon #cppfront #cpp
Greatly disappointed by the lack of a Hawaiian shirt this year.
Cppfront on the other hand is looking really promising, looking forward to further ideas implemented in it.
No C++ conference should be allowed without tropical-themed outfits.
C++ is very lucky to have people like Herb Sutter. Since he entered the scene, we've got excellent books, great research of new features, orderly standardization process, and even Microsoft compiler became one of the best. Thank you.
It's kinda breath of fresh air to listen to an expert like Herb who has experience with many languages and knows well that they have their own set of advantages and disadvantages and does not pretend that the competition does not exist, the industry does not pose new challenges for C++ and that the language doesn't need some serious rework.
On a 2nd thought, we can realize that the best language would naturally attract the best thinkers.
C++ is a huge mess and Sutter understands. That's the real refreshing part.
@@MrAbrazildo Yes. I picked up ‘Effective Java’ and it was far less smart than equivalent C++ books.
@@bobweiram6321 Huge mess?! I find it quite charming.
Bored at work yesterday, I decided to add Cppfront to my Win32 API side project, and 'it just works.'
Cppfront/Cpp2 is amazing-best practices by default, neat syntax, backward compatibility, and new, useful features. I hope Cpp2 becomes mainstream soon. (Also really need that Cpp2 syntax highlighting extension for Visual Studio to convert more code to Cpp2 syntax. :))
Can't wait to use it in production. I hope sometime.
The problem with allowing "simplification" changes like making curly braces implied and optional in some contexts, is that it actually adds complexity, it doesn't fundamentally simplify anything beyond an extremely superficial and narrow focus.
Now you have two ways of writing a thing, and one way requires the reader to recall that there could be invisible implied brackets and assume there isn't some other stange scoping thing going on, all to save only two chars which have real meaning to the logic and intent.
You're right, but that isn't new. The same has been true with "for" and "while" loops, forever.
”all to save only two chars ...". That's just not true, You can save one or two lines, since curly braces may occupy a whole line. And functions may become longer.
As someone working in the medical device industry and watching this it always feels like I can't wait for the day when this (or something like it) becomes the standard.
Having a way of transitioning into a less error prone syntax is absolutely crucial even for a smaller code base.
I seriously believe that using C++ for a safety critical application, which I guess medical devices are, is pretty much professional negligence. Especially if one is aware of the safety issues but continues anyway.
@@Heater-v1.0.0You have no idea how constrained and verified are the things we can use on medical devices, and I guarantee no negligence is happening we are very aware of every allocation, every corner case, and keep things very simple on the main program
@@Heater-v1.0.0Now why do I have a suspicion you have off-colored hair and write .unwrap() a lot? Hmmmmm
Really great to have people like this working for us all and this exceptional language ❤
The Kicker with Python was that one simple refinement could have made the whole 2 to 3 shift go orders of magnitude smoother.
If Python3 code blocks and files were forced to start with "python3" (either with the implied end at EOF, or a matching "python3 end" ) then all of the toolchain could have automatically swapped between 2 and 3, treating them as pieces of one big language and with 2 basically becoming a depricated component that could be replaced in small sections. (And yes this is easier said than implemented.)
The free debugger compatibility is still blowing my mind. I get in principle that Cppfront emits line numbers, but the fact that it works with another full C++ compile step before it gets to the debugger still _feels_ incredible (literal meaning).
However, I also know that GDB doesn't have to do much extra to support some of its explicitly-supported languages, frequently reuses components (e.g. the C++ demangler for Rust support), and can debug unsupported languages fairly well. It follows that any well-written debugger should manage this trick, but it still feels like it should require magic.
What a great talk, not just on language design, but on principles of progress. It's very hard to get the defaults right without the benefit of hindsight. But now that we might be able to change the defaults to best suit our specific needs is phenomenal.
Mr. Sutter is just a great person.
bla,bla,bla,bla,bla.
@gregandark8571 herb Sutter = GOD
1:20:06. Interestingly, none of them has my favorite, which is "require". It conveys exactly what we actually mean, when we write assert(pointer != nullptr), which can be re-written as `require(pointer != nullptr)`. The term "require" sounds more assertive, in comparison to "check" and other alternatives! Requirements => Require! Simple!
maybe because already used for C++20 concepts
@@KX36 that is "requires", not "require".
I am looking forward to use this asap
If Swift is "TypeScript plan" then Kotlin should be in the list for the same premiss
Love this.
Though it is somewhat bizarre to see elegant, futuristic code snippets that use iostreams. Please put them out of their misery. I get that it highlights compatibility but it just looks out of place.
Overly picky comment aside, I cannot wait for this to be production grade. Is there a roadmap in mind?
@TlGMASTER uhhh deep sarcasm?
Great speech, and the direction seems very promising.
I'd also like if I could switch between different C++ language versions in the same compilation unit using a compiler pragma, it would allow to migrate the code gradually and use newer features (possibly breaking) without touching older headers.
This seems like it would be pretty easy to do by having a syntax block that tells CppFront to treat it as non-pure when in pure mode. The building blocks are already there. Similar constructs have existed in other languages, like `unsafe` blocks in Rust or `asm` (assembly) blocks in C/C++.
@bloodgain This is already the case, you can write mixed old cpp code in the same file and cpp2 code. i think it's the default and you need to pass a flag to cppfront (-p for pure cpp2 iirc)
The only unanswered question I have is what it will be like for new programmers who only learn cpp2? Will they be really confused by the "underlying" language? The whole cpp2 concept seems rooted in "Oh, you remember this pattern from C++, look how easy it is in cpp2!".
From what I've seen, being loosely involved in discussions for a couple of years, the focus is to evolve the language, hence the back references, but actually if you look at cpp2 in isolation, it's just like learning any new language. You have to learn the syntax, and how idioms and patterns apply to the language. And I can confidently say, I think it would be easier than learning current c++
This guy is a beast. His design philosophy is perfect. Love it, can't wait to write cpp2 and save myself from cpp1
I've smoked so much dope I'm beginning to agree with Herb Sutter :-)
The talk starts at minute 57:00
This is really cool stuff. Gonna have to look at the repo
Herb says there are 3 ways. The thing transpilers do is let you see the generated code in the old language. I can compile .ts to .js, and inspect that, before executing it. Being able to see the before and after helps greatly with learning. That's kind of difficult if you are doing everything in the same language. You have to check the ASM or LLVM.
This is very entertaining. thanks fro sharing.
I actually want to see how auto completion works with customized type. If I write some new type, and add some weird behaviors into it, can I still get a full functional auto completion?
Mere mortals need documentation
Amazing, I can't wait to use in prod!
You can right now, its been available on github for awhile.
Amazing talk. I like the features, the syntax, the compatibility and I can't wait until we will start using it in real life... But please correct me if I am wrong or if I am missing something obvious... There seems one piece of the puzzle lacking - the ability to call from cpp1 code a piece of code written in cpp2. In other words, the there is no ability to generate cpp1 headers from cpp2 sources.
So if I am writing a library which is to be used by cpp1 or cpp2 callers, then I still need to write it in cpp1. Or if I have a large codebase that I want to migrate it to cpp2 one source file after another, I cannot start with the ones which are called from some cpp1 code. So the migration can only start at the caller side not at callee. I find this as a bit of limitation. If generating cpp1 headers from cpp2 code was possible somehow, then this would be absolutely great and delight to migrate any project...
Great talk ! I feel it would be nicer if one could write e.g. " for menu (item) { ... } ", rather than " for menu do (item) { ... } ".
there are a lot of possible syntaxes for for loops
for i : items, for i in items, for i of items, for items 8===D i etc.
i also find the do(i) to be very strange.
@@KX36 It feels like the old Basic Language in the 80
@@KX36 😂😂😂😂😂😂
In the past there already was a baked in transformation that was extended with "meta classes" and gave us much more power and usefulness - the hard coded rendering pipeline that was extended with vertex, fragment etc. shaders.
So we even have a great example of the past where standardizing an extension like that was a wise thing to do.
31:29 emitting code is nifty. I wonder about how syntax highlighting that code might work.
While I do agree that excessive use of symbols/parentheses (think LISP) can make any piece of code unreadable, removing them altogether (referring to the if ... statement) makes it harder to read, particularly for someone with slight dyslexia.
But I suppose I just have to accept the new style as it's what's fashionable nowadays.
As long as the choice is optional.
@@khatdubell yeah, but if you’re reading someone else’s code you have no control.
BTW, I hope he and Bjarne are working together on the new ideas for safety (and other) profiles.
I have the feeling that Bjarne hates this effort. Sutter is naming Bjarne a lot maybe to ease the tension between the two. But I liove this Cpp Front Effort. We need something of another order of magnitude to get out of the complexity of C++ now.
good that c++ community is learning from Golang without actually admitting it.
Someone finally talked about `this_thread::yield` for why `co_yield` is named as such
Wow I like it a lot... I must admit I am starting to get lost in the newer C++
He talks for half an hour on how to play a new language like Cpp2. I think Herb is right what he says. I am missing on how he wants to progress with Cpp2. Will Microsoft start using it for internal projects? Are users encouraged to use it?
I think the decade started last year with his presentation.
Great talk, would this make Build system and package management easier to solve and standardize?
why foo : @enum type = {}, why not lose the word "type". we don't need "type" after i : int, we know the bit after the : is a type.
You have to keep in mind, everything in this syntax has to be perfectly backwards compatible with existing C++ and C language syntax _in the same code file_
I would imagine its that way because it _has_ to be that way.
Thinking about the stringable enum makes me wonder about mixin metaclasses. It’s surprising for me for a tiny enum definition to store strings (I wrote this comment as he explained his implementation, so maybe I missed something), but I wouldn’t want a separate stringable enum class either. What about an @enum + @stringable? (Thinking about #derive[display] here or whatever that Rust syntax is….)
At 32:00, the has() method is defined incorrectly. Firstly, it shouldn't have taken this by non-const reference. Secondly, when the "that" param has more than one bits set, the naive & implementation only checks that this and that have at least 1 set bit in common. It should have been "_value & that._value == that._value".
Does anyone know how to get the visual studio debugging working in visual studio?
Here's a cheat sheet for how I did it... pretty much just add the .cpp2 file and use a custom build tool to invoke cppfront: github.com/hsutter/cppfront/wiki/Cpp2-setup:-Visual-Studio
Herb Sutter is the greatest authority in C++ and a visionary. By far the best C++ speaker. Can you imagine a man like him working on the development of OpenAI products, that would be amazing?
What does one have to do with the other? Please let him do compilers and language design, not hype topic of the day which requires completely different skill and intuition.
I have to wonder about unions, did people actually use them that way? Pretty much all uses I have seen were for type punning which is explicitly not allowed in the standard but happens to work with every modern compiler. On hardware registers, they don't even follow lifetime rules since they are mapped to memory with a cast of the raw address to the type.
I'm not sure if I would like a Typescript for C++ because I hate the JS/TS Ecosystem. Configuring webpack, vite, tsconfig, eslint and so on. And in this ecosystem there are more people working on tooling (maybe too many) and it isn't great.
1:00:50 Thank Guid 3/2 was never 2 in Python 2, it was 1.
This is pure genius.
Yes. It's true that you can simplify a language if you enable macros and allow users to extend that language for their own users. See lisp.
an extensible language like lisp was actually one thing that oop/smalltalk originally was about, almost no keywords, just objects and messages.
I wonder why we couldn't have such powerful compile time meta programming in cpp.
Instead we had macros, templates, constexpr like all the colors of the rainbow just to avoid this.
It's so sad Herb Stutter has to create a trans compiler so that his ideas are not lost.
Its not sad, its evolution.
i thought he was singing "all you need is rust - rust is all you need". that's what 2x speed gets ya.
"Bounds checking by default" is not "zero-overhead": If I can prove that bounds-checking is unnecessary, but the compiler can't, then I can do better by hand. 15:55
In such a case, an explicit option should be available to allow manual tampering with arguments (safe by default and the ability to squeeze performance when needed, but not the other way around), but considering bounds checking a problem in this particular case where they are most likely touched once for entire lifetime of the program is even worse than typical micro-optimization, is creating potential problems at your own request.
The language is currently full of defects that generate even more performance overhead than bounds-checking, such as passing an object with a non-trivial destructor through the ABI (like unique_ptr).
You didn't listen to what he said.
You don't pay for what you don't use.
The bounds checking is not going to be better than bounds checking you could do yourself.
You're using the bounds-checking by default. If you don't want bounds checking, don't opt into it, and you won't pay for it.
As much as I like Cpp2 so far, I'm afraid it's also going to take at least 10 years for adoption. Yes it has inter-operation with Cpp1. But it also has a standards committee. I don't see the committee adopting this with any kind of alacrity.
Anyone know how far Herb is from being finished with Cpp2?
By "finished" do you mean "abandoned"? Have you ever seen an actually FINISHED tool or language?
watching this makes we wonder WHY tf cpp does not have this already
15:30 C++ has trim() now? ;)
The meta function just looks like the macro pre-processor to me...
Herb is so based
60 years from now, we'll all be coding in .cpppppppp files
You've sold me on the idea since the beginning Sutter!
I wholeheartedly believe cpp2 is the future, but it's been years of you trying to convince people, when do you think cpp2 is going to be readying for mass adoption?
How about calling it C+-, C-plus-minus, instead of CPP2? The minus means without the C++ things that you do not like.
1:10. What point exactly is he trying to make by referring to Rust? I couldn't understands few words (at around 1:10:30)! Replayed it multiple times, still not understandable. Did anyone understand this Rust comparison part?
Enable subtitles/closed captions and you'll read what he said.
Adoption would have been much faster if there was seamless interoperability with c++. I think he's right and am looking forward to further development of his experiment.
He's saying if Rust coule call C++ seamlessly, they would have been where they are a decade ago; basically trying to emphasize the importance of backwards compatibility.
The transcript of what Herb says at this time is 100% what he is saying, so turn on the subtitles. What he is saying is, had Rust been compatible with C++ they would have been 10 years ahead of where they are now in terms of adoption by developers. People would have moved to Rust sooner if it had of had interoperability with C++ and could seamlessly slot into existing code bases. He is not saying that Rust should have done this, but rather that if they had done it adoption would have been sped up.
I understood something like: "... and a super compatible lifetime model; if they had had that, which they chose not to for their own reasons, which is fine. If they had had that, Rust would be where it is today..."
15:20, *C++17.
25:30, I just don't like the syntax. Why : and = ? 29:20, what's the point in := ? Why not just = ? There are too many ':' in your syntax.
50:00, A is the reality of C++ for Android. B is C++ for everything else.
in cpp2 := indicates that it is declaration and initialization and = indicates it is an assignment of a variable declared somewhere else, i.e. you are rewriting some older value. These two cases are very different and are necessary to distinguish for the compiler to perform some safety checks and also for reader of the code to understand it better.
@@vladimirkraus1438 The compiler could apply safety checks, once it realizes it's a declaration. And for us to read, I always liked the context-driven old syntax.
I thought it was odd that Herb seemed unaware of the Carbon language, which has been described by its designers as a C++ successor language which places high importance on compatibility.
He's not unaware.
Carbon is path C.
He disagrees with that approach.
Herb Sutter is of course very well aware of Carbon. He just chose a very different path. The future will tell which path is better.
At the end, goodby c++
14:54 If 'std' is available by default, why one still needs to specify it in '''std::cout''?
These symbols are available, but they are still in their namespace waiting to be used.
You don't want to import everything from std by default, it completely pollutes the global namespace, introduces name conflicts and it's kinda pointless.
I think available means you don't need to use #import to use std::cout but you still need to say which namespace the cout is from
I think it is "#include " default, not "using namespace std;" by default. Right?
std namespace has nothing to do with having std library by default. You use `std::` because you want distinction between std and your custom classes/functions/datastructures etc., and avoid any conflict with std lib. I hope you do not put `using namespace std;` on your header files...
It’s only included by default. It still needs to be scoped.
Sutter is determined to destroy C++. 😂😂😂
Finally.
Here's some very modern C++ brought to you by the power of machine learning and the C++ committee:
#auto
auto auto(auto) {
decltype(auto) auto;
auto(auto);
return auto;
}
invalid.
A more likely candidate for that, I feel like, would be something like this:
sort_numbers_by_AI : @AI ( inout v: std::vector ) -> void =
. . sort vector v in ascending order // AI instruction for what code to write here
I guess the C++ committee faught tooth and nail for that semicolon to stay 💥
`decltype(auto)` and `auto(x)` decay-copy are expert features. Most programmers will rarely if ever need them. You can skip learning those.
@@szaszm_ Then they should get an "expert c++"
is there really no vim syntax highlighting for cpp2 ?
the c++ is just getting uglier and uglier and unreadable as time goes on.
it really needs a remake of some kind! like RE2 remake! and not in a SH2 remake one which sucks!
Literally what this is.
i might be alone with this opinion but this feels like a waste of time, just make a new language at that point. the cpp2 syntax looks horrid
PLEASE dont take away my Objective-C++. If you make @ a keyword in Typescript it will be impossible to continue Objective-C++ or improve the Swift-C++ interoperability
The people had set up their stone idol as god, but the storm came and blew it down. The idol could not save itself. The people should have seen the idol was powerless, but no, they prop it up again.
For all the problems of C++, Herb Sutter still loves it. He is making a great living out of explaining it and writing books. That is what he has to love about it. The language itself is a horror. But no, let's just keep propping it up again.
I think Cpp2 is really a misguided effort. If you want to make a new language, go ahead, but do not call it C++. It will just confuse people. Already many people have a bad image of C++ because they do not know what the language is now and speak based on past experience where they would have written C-style C++. Plus a new language isn't really required nor wanted; I do not want to learn how to do the same things with different syntax again. Instead, continue to focus on the existing C++ language.
If you do not like then do not use it... but do not tell other people what they should do.
better just create a new language
This is a new language.
Adoption of new languages is very slow. He gives examples in another talk.
Holy ****, that's anything but TypeScript. Start with ES6 arrow function expression syntax.
No.
We don't want literal typescript.
The entire point of the talk was to suggest that C++ needs an _analogue_ to typescript. Not typescript itself.
Give it a rest. You already have a mind bindingly complicated language. Which whilst being very performant, sophisticated and useful is collapsing under the weight of the impossibility of any single person understanding all its features and how they interact with each other. A bunch band aid features strapped on to improve safety or simplicity is only going to twist more complexity into the behemoth and make it worse. Let it C++ be what it is. Let a new generation learn from the disaster and try to do better.
Don’t throw out the baby with the bathwater. There are billions of lines of C++ that are supporting many critical systems. It is intractable and undesirable to redo it all - but we can continue on to a brighter future with a much simpler, better user interface that still supports the old world.
And don’t keep reinventing the wheel over and over, either!
That is exactly what he's solving with this approach. You want to only use the more streamlined cpp2, you can. You need 'legacy' code, you have it. This is the way. You choose the dart path you get an adoption gap of at least a decade like he showed with the languages that fell for it.
Anything they do after C++17 and even partially before is just mental masturbation primarily for the sake of the ego trip and the thrill of working on something new. If you have to churn out new language features every three years on top of this complex monstrosity you are bound to produce shit. What the committee is missing is a less is more mentality.
That's right, who needs language improvements anyways. There's a js framework for everything nowadays so let's abandon all other languages and write everything in js, why not?
@@kodirovsshik Who said anything about JS? I was thinking of building systems that have to work, that should be reliable, secure , that can be safety critical. C++ is not suitable for that, no more than C (Or JS)
C++ has many language "improvements" but it is still C at root, with a pile of complexity on top. It cannot escape its roots unless it breaks a lot of historical code.
Professional software engineers now have better alternatives and I would say it is professional negligence not to adopt them.
This is so wrong. I hope this will never evolve into standard. std library is unreadable.