The definition of CVE stated by the audience member is incorrect at 34:11. It is incorrectly stated as 'Common Vulnerablity Enumeration', but the correct definition is 'Common Vulnerabilities and Exposures'.
I think C++ needs to ditch the idea of backwards compatibility if it is going to move forward. The type system of C++ needs to adopt some ideas that have been around for something like 40 years at least, such as dependent types, which I think, afaiu, is kind of what "contracts" would try to mimic. As an example, look at lean4, you can have dependent types in which the "pre/post conditions" are proven at compile time to achieve correctness, and make safety and security much more achievable given sound specifications. What I've been curious about recently is if one could implement a type system like lean4's which includes pointer types, l/r values, and understands memory, while being able to prove at compile time that implementations are memory safe and correct. I've seen so many C++ conference talks about how to implement this or that neat trick to solve specific problems, and ime, this ends up becoming a task of boilerplate if these tricks become standard. Type erasure for example, I think the compiler ought to be able to automate these implementations when needed. If we had typed generics, and typeclasses, I don't see any reason the compiler couldn't automatically generate type-earsed wrappers for types that have been existentially quantified, I mean, the "affordances" are specified by the constraints of the typeclasses, the compiler would have all the information it needs to generate the t/e wrapper, and this isn't a new idea, it's been quite common in functional programming for decades. This isn't something that can be done with concepts though, and I think that's a hint that points at what is wrong with C++'s type system, and why it's so important to stick with formal methods as much as possible.
On a related note, Herb Sutter gives his pitch why compatibility is important in a talk released today. th-cam.com/video/fJvPBHErF2U/w-d-xo.html Basically saying that you can ditch compatibility but it will take at least 10 years to adopt if it gets adopted at all. So by keeping compatibility it can save you 10 years.
@@SolidAir54321 Right... Imagine people in the early 20th century saying "I want to put an engine into this car thing but I want it to be compatible with horse-drawn carriages. It's going to take 10 years to get adopted anyway, so I'll just keep the horses and save 10 years."
Going to offer an outsider perspective. Software developers don't think of themselves as an engineering discipline, they think of themselves as artists. And as artists any responsibility for correctness, budget or time is not-cool-man. Just watch any CI or Agile influencer or quote-unquote thought leader, and then more importantly read the comments on their youtube channels. The childish seething resentment for responsibility is the #1 issue facing the software industry as a whole. Every other engineering discipline in the world takes its responsibilities seriously. Languages like rust let the children fingerpaint without burning the house down. If I as a parent am not willing to give my son a pocket knife due to his demonstrated irresponsibility, why would we as the public allow this industry of people who aren't just irresponsible, but openly and transparently hostile to the idea that they should be responsible, play with matches. Maybe that's the reason Sean Parent isn't going to change any minds.
This is a very interesting discussion. But it does not give much hope. the panel seems mostly indifferent or resigned with respect to safety, and to by and large side step the actual issue (imho) which is non technical. A super power has set the standard, well defined or not, and that is reality. Exploits are reality. So, the job is to satisfy them, like it or not.
Love how most people on the panel (with exception of Chanlder, only one who actually worked on a compiler a lot) are delusional about maturity of competing platforms. Swift is backing the entire apple platform now, it's not going away. Rust isn't going away either - both languages are mature with quickly growing ecosystems. And so much more pleasant to use than C++.
I don't think anybody said they're going away, though... but perhaps they do underestimate the effect of having powerful companies like Apple really pushing a programming language. But I think C++ can cope with competition. The main danger is governmental institutions telling the industry not to use C++, IMO.
For some reason I find frequently random people trolling under many C++ talks and praising is better. If anything it shows a common toxic trait among their community. As for the credibility, why anyone would believe in an anonymous, random person when there are several, proven specialists on the video?
1:09:24 The industry doesn't learn anything. Its the regulators that must force industry to do better. Business must be forced, by law/regulation, not to produce defective software just like business has to be forced not to produce defective buildings.
It was the same thing with leaded gasoline, industry refused to change for almost a century and it led to highly elevated levels of lead in humans, widespread reduction of average iq, linked to increases in crime rates, and worse. But, leaded fuel was very profitable. Alot of the languages people are still taught are totally inadequate for writing even moderately safe code, but many are backed by big corps like google, microsoft, and oracle or tied to their other products. Idk, hard to believe the web is still powered by javascript for example. Look at a lang called ATS if you get a chance, makes Rust look like a child's toy, and C++ like smoking tar.
38:00 the fact that video game developers think they don't need to care about security should terrify anyone who has installed a game that talks to the internet
I think blaming safety problems on computer languages is bit misguided. It's like blaming airplane crashes on the English language. Imagine if the government decided English is not safe for use by the airline industry because it has too many problems that could lead to miscommunication amongst pilots and controllers. For instance, the letter B sounds too much like the letter P, or the letter M sounds too much like the letter N and that could lead to confusion during flight operations leading to fatal accidents. That is all completely true of the English language but no one in their right mind would suggest mandating an overhaul of the language or banning it from the airline industry. Instead we come up with solutions like using the Alpha Bravo Charlie alphabet to communicate, or creating certain approved communication protocols that all pilots and controllers have to trained on and required to use. In other words you regulate the usage of the language, not the language itself. The same goes for computer languages. Safety and security are not the responsibility of the language, necessarily. Most of the time it is more the responsibility of the community and ecosystem around the language. If its' possible to make the usage or application of a language completely safe then there should be no reason to change the language itself. This can be done in C++ with type-oriented programming, static analysis, core guidelines, best practices, etc. The language can be completely safe without making any fundamental changes to it that move it away from it's core principles and goals.
I agree that c++ *can* be safe, but it is *extremely* hard to do so. Languages that are designed with safety in mind from the start (like Rust/swift) make it much easier to write safe programs by construction. So I do think that language design and safety are tightly coupled. I don’t think that comparing this to a human/human language like English is a good comparison here. Because the execution substrate (another human brain) is extremely tolerant to language ambiguity and context awareness. In a machine language any margin of language ambiguity almost always results in programming errors, undefined behavior, and therefore security vulnerabilities.
No, you trying to argue with bad analogy. Correct analogy is '20% of pilots using bad English language, but 80% pilots using Esperanto or something which has no ambiguity and completely safe'. We should force those 20% pilots to change habits and just safe language like Esperanto with real memory safety without Latin compatibility burden. (C=Latin)
If you want a better analogy, then try to imagine building a pointy nuclear missile with all instructions being written in Wadiyan language where half of the words are Aladeen. That's not a safe business, I tell you. If you are lucky, the missile will not work. If you are unlucky... bad things will happen to you such that shooting your own foot off sounds like fun compared to them. And that is basically C++.
Why isn't the possibility of C++ becoming an officially deprecated language discussed? Perhaps the committee should work on features that allow other languages to be the successor of C++? One might retort by saying that there's a lot of existing C++ code and the training programmers this new tool is going to take work. There's a lot of existing C++ code, so let's consider some choices: keep using the older C++, upgrade to newer C++, or have tools to allow more modern languages to be patched unto it. The answer that the C++ folks have chosen is obviously the 2nd one but is that a good choice? How many better can a fully backward compatible language be? How long did it take to develop ranges? It came out as complete ass and the people that likes it probably have never seen how it's done in other languages so they don't know better.
The last C++ segfault I had was due to an invalid pointer in a smart pointer. I wouldn't even know how to write that bug in safe Rust. There is real value in making classes of bugs not be expressible in a programming language.
If i do not know how to do "safe" code, don't care about performance, then I should not use C++. C++ is writing machine code without writing assembler. This opens up a lot of possibilities and you can design your own "safety". This is what C++ is all about, you are able to create your own solutions, you are not tied to some specific solutions that the language supports. C++ should focus on adding more possibilities to create flexible code, improve compiler functionality but without adding constraints in the language.
tbf I never understood the "safety" everyone is talking about they either be making turns left and right about how bad C++ is but never give a real world example or brings an old already easy to fix code
The definition of CVE stated by the audience member is incorrect at 34:11. It is incorrectly stated as 'Common Vulnerablity Enumeration', but the correct definition is 'Common Vulnerabilities and Exposures'.
Good summary by JF of why computer science is not yet an engineering discipline.
16:14 Chandler's scathing assessment.
20:40 Herb encounters a bug live.
@1:01:25 Chandler's actually remove his covid-mask to drink from the cup
I think C++ needs to ditch the idea of backwards compatibility if it is going to move forward. The type system of C++ needs to adopt some ideas that have been around for something like 40 years at least, such as dependent types, which I think, afaiu, is kind of what "contracts" would try to mimic. As an example, look at lean4, you can have dependent types in which the "pre/post conditions" are proven at compile time to achieve correctness, and make safety and security much more achievable given sound specifications. What I've been curious about recently is if one could implement a type system like lean4's which includes pointer types, l/r values, and understands memory, while being able to prove at compile time that implementations are memory safe and correct.
I've seen so many C++ conference talks about how to implement this or that neat trick to solve specific problems, and ime, this ends up becoming a task of boilerplate if these tricks become standard. Type erasure for example, I think the compiler ought to be able to automate these implementations when needed. If we had typed generics, and typeclasses, I don't see any reason the compiler couldn't automatically generate type-earsed wrappers for types that have been existentially quantified, I mean, the "affordances" are specified by the constraints of the typeclasses, the compiler would have all the information it needs to generate the t/e wrapper, and this isn't a new idea, it's been quite common in functional programming for decades. This isn't something that can be done with concepts though, and I think that's a hint that points at what is wrong with C++'s type system, and why it's so important to stick with formal methods as much as possible.
On a related note, Herb Sutter gives his pitch why compatibility is important in a talk released today. th-cam.com/video/fJvPBHErF2U/w-d-xo.html
Basically saying that you can ditch compatibility but it will take at least 10 years to adopt if it gets adopted at all. So by keeping compatibility it can save you 10 years.
@@SolidAir54321 Right... Imagine people in the early 20th century saying "I want to put an engine into this car thing but I want it to be compatible with horse-drawn carriages. It's going to take 10 years to get adopted anyway, so I'll just keep the horses and save 10 years."
Were the mics in short supply? :D
Going to offer an outsider perspective. Software developers don't think of themselves as an engineering discipline, they think of themselves as artists. And as artists any responsibility for correctness, budget or time is not-cool-man. Just watch any CI or Agile influencer or quote-unquote thought leader, and then more importantly read the comments on their youtube channels. The childish seething resentment for responsibility is the #1 issue facing the software industry as a whole. Every other engineering discipline in the world takes its responsibilities seriously. Languages like rust let the children fingerpaint without burning the house down. If I as a parent am not willing to give my son a pocket knife due to his demonstrated irresponsibility, why would we as the public allow this industry of people who aren't just irresponsible, but openly and transparently hostile to the idea that they should be responsible, play with matches. Maybe that's the reason Sean Parent isn't going to change any minds.
This is a very interesting discussion. But it does not give much hope. the panel seems mostly indifferent or resigned with respect to safety, and to by and large side step the actual issue (imho) which is non technical. A super power has set the standard, well defined or not, and that is reality. Exploits are reality. So, the job is to satisfy them, like it or not.
Love how most people on the panel (with exception of Chanlder, only one who actually worked on a compiler a lot) are delusional about maturity of competing platforms. Swift is backing the entire apple platform now, it's not going away. Rust isn't going away either - both languages are mature with quickly growing ecosystems. And so much more pleasant to use than C++.
I don't think anybody said they're going away, though... but perhaps they do underestimate the effect of having powerful companies like Apple really pushing a programming language.
But I think C++ can cope with competition. The main danger is governmental institutions telling the industry not to use C++, IMO.
But Swift and Rust do not offer smooth two-way interop on code level with existing large C++ codebases... And that is what is being discussed here.
For some reason I find frequently random people trolling under many C++ talks and praising is better. If anything it shows a common toxic trait among their community.
As for the credibility, why anyone would believe in an anonymous, random person when there are several, proven specialists on the video?
RIIR this conference
BRAVO Chandler!
Genuine question: how hard is it to mix 6 microphones ?
1:09:24
The industry doesn't learn anything. Its the regulators that must force industry to do better.
Business must be forced, by law/regulation, not to produce defective software just like business has to be forced not to produce defective buildings.
It was the same thing with leaded gasoline, industry refused to change for almost a century and it led to highly elevated levels of lead in humans, widespread reduction of average iq, linked to increases in crime rates, and worse. But, leaded fuel was very profitable. Alot of the languages people are still taught are totally inadequate for writing even moderately safe code, but many are backed by big corps like google, microsoft, and oracle or tied to their other products. Idk, hard to believe the web is still powered by javascript for example. Look at a lang called ATS if you get a chance, makes Rust look like a child's toy, and C++ like smoking tar.
I totally agree that governments must force to bad C++ from industry, no one willingly will move from it.
38:00 the fact that video game developers think they don't need to care about security should terrify anyone who has installed a game that talks to the internet
Government regulation makes modern life possible.
I think blaming safety problems on computer languages is bit misguided. It's like blaming airplane crashes on the English language. Imagine if the government decided English is not safe for use by the airline industry because it has too many problems that could lead to miscommunication amongst pilots and controllers. For instance, the letter B sounds too much like the letter P, or the letter M sounds too much like the letter N and that could lead to confusion during flight operations leading to fatal accidents.
That is all completely true of the English language but no one in their right mind would suggest mandating an overhaul of the language or banning it from the airline industry. Instead we come up with solutions like using the Alpha Bravo Charlie alphabet to communicate, or creating certain approved communication protocols that all pilots and controllers have to trained on and required to use.
In other words you regulate the usage of the language, not the language itself.
The same goes for computer languages. Safety and security are not the responsibility of the language, necessarily. Most of the time it is more the responsibility of the community and ecosystem around the language. If its' possible to make the usage or application of a language completely safe then there should be no reason to change the language itself. This can be done in C++ with type-oriented programming, static analysis, core guidelines, best practices, etc. The language can be completely safe without making any fundamental changes to it that move it away from it's core principles and goals.
I agree that c++ *can* be safe, but it is *extremely* hard to do so. Languages that are designed with safety in mind from the start (like Rust/swift) make it much easier to write safe programs by construction. So I do think that language design and safety are tightly coupled.
I don’t think that comparing this to a human/human language like English is a good comparison here. Because the execution substrate (another human brain) is extremely tolerant to language ambiguity and context awareness. In a machine language any margin of language ambiguity almost always results in programming errors, undefined behavior, and therefore security vulnerabilities.
No, you trying to argue with bad analogy. Correct analogy is '20% of pilots using bad English language, but 80% pilots using Esperanto or something which has no ambiguity and completely safe'. We should force those 20% pilots to change habits and just safe language like Esperanto with real memory safety without Latin compatibility burden. (C=Latin)
"This can be done in C++" - no, it can not. Safe language will be incompatible with C++, you need to move on from dead horse.
It's so cute argument in the presence of fast and safe languages already solving C++ safety issues.
If you want a better analogy, then try to imagine building a pointy nuclear missile with all instructions being written in Wadiyan language where half of the words are Aladeen. That's not a safe business, I tell you. If you are lucky, the missile will not work. If you are unlucky... bad things will happen to you such that shooting your own foot off sounds like fun compared to them. And that is basically C++.
Why isn't the possibility of C++ becoming an officially deprecated language discussed? Perhaps the committee should work on features that allow other languages to be the successor of C++? One might retort by saying that there's a lot of existing C++ code and the training programmers this new tool is going to take work.
There's a lot of existing C++ code, so let's consider some choices: keep using the older C++, upgrade to newer C++, or have tools to allow more modern languages to be patched unto it. The answer that the C++ folks have chosen is obviously the 2nd one but is that a good choice? How many better can a fully backward compatible language be?
How long did it take to develop ranges? It came out as complete ass and the people that likes it probably have never seen how it's done in other languages so they don't know better.
Rust marketing/propaganda has reached peak hype.
The last C++ segfault I had was due to an invalid pointer in a smart pointer. I wouldn't even know how to write that bug in safe Rust.
There is real value in making classes of bugs not be expressible in a programming language.
If i do not know how to do "safe" code, don't care about performance, then I should not use C++. C++ is writing machine code without writing assembler. This opens up a lot of possibilities and you can design your own "safety". This is what C++ is all about, you are able to create your own solutions, you are not tied to some specific solutions that the language supports.
C++ should focus on adding more possibilities to create flexible code, improve compiler functionality but without adding constraints in the language.
To resume what you said : "C++ is on an ejection seat, it's so fine, let's keep it that way"
tbf I never understood the "safety" everyone is talking about they either be making turns left and right about how bad C++ is but never give a real world example or brings an old already easy to fix code