The frustrating thing about this type of talk is that early on, you get the point that there's a lot of confusing and counterintuitive rules about how C++ behaves, and you spend the rest of the talk waiting for the litany of point-proving gotchas to finish. I figured that at the end, there would be some insight as to a particular language feature or design principle that was behind all these gotchas, but the primary insight appears to just be "C++ is hard, D shouldn't be."
Well, I'll fess up to not making it to 43:40. I got about 20 minutes in and, wondering if the whole talk was going to consist of examples of unpredictable C++ behaviors, I came to this comment thread and saw dmunoz' summary, so I gave up.
I just loaded it up again and went to 43:40 and yes, that's a good conclusion: the thing D doesn't need is an overly-broad list of design principles. I do think he could have come to that conclusion a lot quicker and with a LOT fewer examples.
Well, the examples were the content of the talk. He didn't need the examples at all, but they demonstrate a severity of the problem. And to that point the talk needed to be slow so that one can try and answer the question, if the answer was just given it is harder to see the difficulty presented.
I also must confess, I didn't watch the video. I was there, so there is a good chance the presentation doesn't translate well to video in terms of speed of content.
