also, the Rust compiler knows that things do not overlap, where in C you can only promise that with restrict, and it is the basis for a few optimizations
I haven't found any evidence that this was true. In the interview with Bryan Cantrill in ACM Queue he talks about age 11 and that was really only a demonstration. That would be much more realistic and really would be still a very early age considering that was still in the late 1960s.
This really struck a chord with me, when at 4:35 he says "you can't have it all"... and this is at the core of what's wrong with JavaScript, because JavaScript insists that it CAN have it all. I think Bryan might come to that conclusion at some point in this talk too (if not then, within the next couple'a years of this talk) . ... oh yeah, quick note to the JS community: you CAN'T have it all!
I disagree with the assessment of OpenBSD. I feel they also choose simplicity, stability, and portability. The number of platforms they still support is astonishing.
Yeah, but if they had to throw any of those values out the window to stay secure they wouldn't even hesitate to immediately do so. If supporting a platform, maintaining the API/ABI, or keeping the system simple meant loss of security, then they wouldn't.
it's just the status quo that you have to choose randomly between these values. there's nothing contradictory about a possible future language to have them all because they're not fundamentally conflicting values. it's just that all our current languages suck.
I highly doubt that this is true. As a trivial counterexample, once you have a language that values performance, and robustness, and security, you can't also value simplicity and approachability.
Paul Anderson this is not really a counterexample, is just a restatement of that belief... you still haven't said _why_ you couldn't have all those things together in one language
Quick reply to a 4-month-old comment! I'm impressed. 🙂 Fair enough, but my response is going to be to throw it back on you. Can't prove a negative; extraordinary claims require extraordinary evidence; etc etc yada yada. Are there systems created to date that make absolutely no trade-offs among those values? I'm not the collector of systems that Bryan is, but I don't know of one and I imagine he doesn't either. And I find it hard to imagine that the engineers building secure, robust, and performant systems so far did not stop to consider whether their solutions could be simpler and more approachable; and vice versa. If none exist, then that failure of many smart engineers and teams to find the solution is not a proof of impossibility, but it means that the person asserting that it is possible should expect to be challenged until they can provide evidence.
@Paul Anderson I'm not sure this is how it works. Someone asserts "you can't have X Y Z in the same language", provides no reasoning for why that's impossible except for the observation that this is how things are at the moment by surveying the current alternatives, and you think it's on me to demonstrate the contrary, eventually by making a new language myself just to prove a point in a youtube comment? Hmm... I'll get started right away :)
@@UGPepe I should probably clarify in case it's in doubt, I'm not ruling out the possibility of making improvements in all of the listed metrics. We can, and probably will, gain *more* security and simplicity for example, even within the same language, as time goes on. But that doesn't mean they never require trade-offs. What I think you're saying is that the trade-offs are always only illusory, and there exists a hypothetical god-language that never decreases one at the expense of the other. I do think such a language is impossible, and my reasoning is that the history of computing (not to mention government and philosophy), has produced zero examples of times where a perceived trade-off in values was resolved forever and never came back. If there was such an example, that would be perfect evidence to support your claim, and I would likely have to admit that over a long enough time period, the development of something like a god-language would seem inevitable.
Watch the talk again, because that's not what he said. What he said is that use-after-free bugs don't happen because someone forgot about free. They happen because of misunderstandings at API boundaries and in the composition of large systems. Which is true. JohnC is an excellent C programmer. He doesn't ever just "forget to call free."
@@TheMrKeksLp Yeah, but the problem with C is that so many vulnerabilities do not come from obvious sources, and what Bryan talks about in the video, has to do with collaboration, API boundaries, etc, where the obvious mistakes, becomes blurred behind layers upon layers of complexity. Rust can guard against those kinds of errors, due to their borrowing model.
The man is an excellent speaker.
I've watched a whole bunch of his talks ,always curious if those jokes are written."Let the wookie win" ahahha
also, the Rust compiler knows that things do not overlap, where in C you can only promise that with restrict, and it is the basis for a few optimizations
"Learned APL at the age of 4."
Well, I'll never get close to that.
Yup, a true geek! In a different presentation (at Stanford) he said Bill Gates robbed him of his childhood!!
I haven't found any evidence that this was true. In the interview with Bryan Cantrill in ACM Queue he talks about age 11 and that was really only a demonstration. That would be much more realistic and really would be still a very early age considering that was still in the late 1960s.
This really struck a chord with me, when at 4:35 he says "you can't have it all"... and this is at the core of what's wrong with JavaScript, because JavaScript insists that it CAN have it all.
I think Bryan might come to that conclusion at some point in this talk too (if not then, within the next couple'a years of this talk) . ... oh yeah, quick note to the JS community: you CAN'T have it all!
JS dev here. Not all, but a LOT :d
A true geek! In a different presentation (at Stanford, I think in 2020) he said Bill Gates robbed him of his childhood!!
I disagree with the assessment of OpenBSD. I feel they also choose simplicity, stability, and portability. The number of platforms they still support is astonishing.
Yeah, but if they had to throw any of those values out the window to stay secure they wouldn't even hesitate to immediately do so. If supporting a platform, maintaining the API/ABI, or keeping the system simple meant loss of security, then they wouldn't.
27:35 "Let the wookie win" - Yeah that's Rust, IMO.
4:17 Why does "interoperability" come before "integrity" in this "alphabetical" list? 🤔
Off by one error
He didn't unit test his search algorithm????
@@edgeeffect 😂😂😂
He can't spell!
it's just the status quo that you have to choose randomly between these values. there's nothing contradictory about a possible future language to have them all because they're not fundamentally conflicting values. it's just that all our current languages suck.
I highly doubt that this is true. As a trivial counterexample, once you have a language that values performance, and robustness, and security, you can't also value simplicity and approachability.
Paul Anderson this is not really a counterexample, is just a restatement of that belief... you still haven't said _why_ you couldn't have all those things together in one language
Quick reply to a 4-month-old comment! I'm impressed. 🙂 Fair enough, but my response is going to be to throw it back on you. Can't prove a negative; extraordinary claims require extraordinary evidence; etc etc yada yada.
Are there systems created to date that make absolutely no trade-offs among those values? I'm not the collector of systems that Bryan is, but I don't know of one and I imagine he doesn't either. And I find it hard to imagine that the engineers building secure, robust, and performant systems so far did not stop to consider whether their solutions could be simpler and more approachable; and vice versa.
If none exist, then that failure of many smart engineers and teams to find the solution is not a proof of impossibility, but it means that the person asserting that it is possible should expect to be challenged until they can provide evidence.
@Paul Anderson I'm not sure this is how it works. Someone asserts "you can't have X Y Z in the same language", provides no reasoning for why that's impossible except for the observation that this is how things are at the moment by surveying the current alternatives, and you think it's on me to demonstrate the contrary, eventually by making a new language myself just to prove a point in a youtube comment? Hmm... I'll get started right away :)
@@UGPepe I should probably clarify in case it's in doubt, I'm not ruling out the possibility of making improvements in all of the listed metrics. We can, and probably will, gain *more* security and simplicity for example, even within the same language, as time goes on. But that doesn't mean they never require trade-offs. What I think you're saying is that the trade-offs are always only illusory, and there exists a hypothetical god-language that never decreases one at the expense of the other.
I do think such a language is impossible, and my reasoning is that the history of computing (not to mention government and philosophy), has produced zero examples of times where a perceived trade-off in values was resolved forever and never came back. If there was such an example, that would be perfect evidence to support your claim, and I would likely have to admit that over a long enough time period, the development of something like a god-language would seem inevitable.
That APL line-noise makes sense when you consider it used to be typed on paper ruclips.net/video/_DTpQ4Kk2wA/видео.html
The speaker needs to switch to decaff
Oh no! An alternative universe where Bryan Cantrill is "on decaff" is a sad place indeed.
so he asserts that he is better than say John Carmack, who admittedly had invalid pointer dereference bugs somewhat recently
Watch the talk again, because that's not what he said. What he said is that use-after-free bugs don't happen because someone forgot about free. They happen because of misunderstandings at API boundaries and in the composition of large systems. Which is true.
JohnC is an excellent C programmer. He doesn't ever just "forget to call free."
He wrote DTrace and ZFS. He can big dog Carmack if he wants.
@@THB192 Don't ever assume that great C programmers don't make (sometimes very obvious) mistakes. They all do, that's why we have vulnerabilites
@@TheMrKeksLp Obviously. But "oops, I forgot to call free" is usually not the failure mode. There are like a billion other failure modes.
@@TheMrKeksLp Yeah, but the problem with C is that so many vulnerabilities do not come from obvious sources, and what Bryan talks about in the video, has to do with collaboration, API boundaries, etc, where the obvious mistakes, becomes blurred behind layers upon layers of complexity. Rust can guard against those kinds of errors, due to their borrowing model.
No! Another victim of rust!
One of us… one of us…