I think you're having your own conversation over there, my friend. Everyone else is talking about language features that are safer by design. You seem to be talking about people failing to understand elementary programming ideas.

The point isn't that anyone would deliberately construct a loop that iterates out of bounds. The point is that our industry has a very long and ignominious history of people writing loops with off-by-one errors and sometimes those errors have turned into serious failures of the systems that code belonged to. It is a fact that sometimes programmers do make those mistakes. It follows that alternative ways to express the intended behaviour that aren't vulnerable to those types of mistakes will be safer in this respect and will avoid some bugs that would otherwise have happened.

Also, the performance argument is shaky at best. For one thing, some of the better abstractions have essentially zero cost. They don't need extra runtime bounds checks or similar overheads because they are already correct by construction. For another thing, even in formulations that do behave as if there are runtime bounds checks before every iteration, modern code analysis techniques will recognise some patterns where the bounds can't be violated, so often compilers can elide those checks in the code they actually generate anyway.

The irony of this debate is that the people who think everyone should write perfect code and only bad developers make mistakes very often turn out to be the developers with the worst track records of making mistakes. Hubris is a dangerous thing.

Meanwhile the good developers are over there, getting their code reviewed by their peers and writing test suites and adopting languages with safer designs, so that when they do make the mistake, as they know they inevitably will sooner or later, it will probably get caught by one of the safety nets and not end up as a problem in production.

Everyone makes mistakes, no matter how good they are. Adopting defensive practices and tools that have designed out certain failure modes produces better outcomes, in software development as in many other fields. The evidence for this is overwhelming and arguing that we shouldn't need to compensate for human failings because developers should be perfect and not make mistakes in the first place is not a credible position.

But in this case it looks like the senior government people are on the right side of the debate. It's the "engineers" defending demonstrably risky languages like C++ who are trying to promote their own preferences as being safe enough despite all evidence to the contrary.

Professionals in fields like flying recognise that no-one is perfect and operate defensively to mitigate the risk. That's why we have checklists and copilots and why everyone in the cockpit shuts up at certain critical times except for very specific commentary. It's also why a lot of time and money is spent on designing very clear, very efficient controls and displays for cockpits.

It's bizarre that anyone would still argue even the best C++ programmer in the world won't pick the wrong type of smart pointer and end up with an ownership bug some time. Plenty of good programmers used to have null pointer dereferencing bugs, too, but for some reason we don't get so many of those in languages that don't have null pointers.

There is an important difference between a language where you can write safe code and a language where you can't write dangerous code. Some people in the C++ community seem to be wilfully ignorant of this distinction.

There is also an important difference between a practical language with escape hatches where the use of those escape hatches can be easily audited and one where it can't. If you can audit your entire codebase for potentially unsafe code and ensure any such code is carefully reviewed when it can't be avoided then that is very much better than having millions of lines of code where something unsafe could just be lurking anywhere. Again some in the C++ community seem to deliberately ignore this distinction.

Some people stay at good places for a few years each. That's great for gaining valuable experience and developing good judgement, but it's lousy for building a large professional network. And all of those pros and cons are amplified for roles at smaller companies.

Ah, yes. The 25-year-old cofounders, fresh from their PhDs, with some seed funding but no real industry experience. I've met a few of those over the years, too. Their ideas about how to run a successful business are often... different... aren't they?

Arguing that restricting the choice of software that can run on your platform is just another layer of defence in depth is a pretty long reach when your platform is a general purpose consumer device. I mean, you could lock your phone away, air gapped and inside a Faraday cage, and it'd also have extra layers of security. It wouldn't be very useful as a phone, though.

Here's a lesson from someone who has actually done serious security work for a very long time: there is no such thing as perfect security. Practical security is always about compromise, trying to balance the need for a system to be useful with the need to protect that system according to your threat model. If Apple are so worried about all the layers that sit within and below the OS that they don't think they can achieve a reasonable standard of security without also controlling the choice of available apps then yes, that absolutely is an open admission that they don't have confidence in the security their OS and platform.

Sorry, I'll include the /s next time. The point of my GP comment was exactly that you can't install a real privacy-friendly browser on iOS because Apple won't let you.

There is a certain irony to your argument when privacy-friendly browsers are increasingly fighting those very dangers but Apple customers can't run them on iOS because Apple won't let them.

In any case, as has been noted in other comments, if the security model works properly and potentially harmful capabilities of apps are restricted unless the user says otherwise, why is there a problem with allowing apps from non-Apple stores?

The solution to that problem is easy and well known. Just install any of the privacy-friendly browsers and any of the good blocker add-ons. So what's the real problem here?

It also amazes me that no-one calls them out every time they try that one, because it's an open admission that they don't have confidence in the security of their OS and platform. It shouldn't matter where your apps come from or how hostile they try to be if they're properly jailed and your permissions system works.

Ah, yes, the millions of developers in the world are all evil and trying to eat your babies. No-one just wants to share fun or useful programs any more. Those open sores people especially are known for their greed and a culture of exploiting others for selfish personal gain. And there are no software companies in the world that are trying to make money in any way other than abusing their own customers, which is why no-one will benefit from any hypothetical competition in the market and any potential reduction in costs of delivering software to users.

There is certainly some Schadenfreude here, but I suspect it would be more fun for millions of Apple customers in the EU if it opened up its walled garden as the law requires so all those users could benefit.