That there is a chance of undefined behavior is a statement without worth or meaning. It's like having an estimation method without an error bound. In my exper

That there is a chance of undefined behavior is a statement without worth or meaning. It's like having an estimation method without an error bound. In my experience, I run into "undefined behavior" in C-land extremely rarely. I can't remember a single instance in 15 years of embedded programming (unsigned/type promotion sure everybody does that at least once sometime, some weird architecture defined thing, nope). Maybe that's because I'm some super amazing C programmer, or that I read the docs, or maybe it's because the chance is low? Regardless, people very often become hyper-focused in this types of debates to be point of being completely unbraced by reality. The valid way to do these sorts of language comparisons is to look at the the pros and cons and give them a weight. Something like this pro is (very good), but (rarely comes up in practical programming), or (This con is very bad) but basically only shows up in (interview questions), etc. Then take the sum of the weight of each side, rather than making statements like, "language has/doesn't have x feature/drawbrack thus I'm right about every thing yay!". I.e. if you are looking at a 10d problem in 1d, you're going to be wrong.