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
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.
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++.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 would have liked to see mention of the Circle compiler in this. The panel discussion two weeks ago mentioned it once: ua-cam.com/video/jFi5cILjbA4/v-deo.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.
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 😉
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 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'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 &`?
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?
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
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.
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.
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.
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++"
@@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
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!
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.
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.
Bravo Herb, bravo. Excellent talk, hope it continues to gain momentum.
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.
Best talk.
Thank you Herb. ❤
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
I saw the title and I have never clicked on a UA-cam talk this quickly.
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.
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.
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:23:58 Another language which falls into (B) for C++ is Carbon.
Although they go a slightly different route compared to CppFront.
great talk 🚀🚀
At 17:12 perhaps args could be of type initializer_list or array to avoid the allocation?
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.
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.
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.
"In tension" and "intention" was a bit confusing! :) Might explain the lack of hands that were raised.
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.
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.
I think variadic using and empty base class optimisation are the two reasons I’ve had to use private inheritance.
great speech! I choose Rust
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.
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.
I'm looking forward to seeing what the new Carbon language becomes.
Its funny I always have considered python as the sister language to c++. They are just so complimentary in so many way.
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 would have liked to see mention of the Circle compiler in this. The panel discussion two weeks ago mentioned it once:
ua-cam.com/video/jFi5cILjbA4/v-deo.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
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 😉
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 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 suggest to keep C++ syntax as it is, but include a switch to turn off all the legacy C semantics that drags C++ down.
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
cool
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?
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.
Why do I have sudden urge to descend back to C?
10:00
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.
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.
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.
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.
😮😮😮
As time goes by Cpp2 looks less and less like C++.
This is very much a good thing. :)
interesting
how about following through with all the stuff from your previous talks first.
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++"
Hype
Only about five people on Earth with the juice to get this done, Herb is one of them.
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
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!
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.
Poor man...