If your thesis is "Complex and/or difficult software is hard to get right.", I agree with it. I don't think any experienced programmer would disagree with it.
If your thesis is -as it appears to be- "Complex and/or difficult software is impossible to get right.", I cannot agree with it. It is often difficult and time consuming to create correct complex software, but far from impossible.
It is technically possible, but improbable enough that, in the absence of direct evidence to the contrary (in this case, a functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine), it may as well not be.
Is the software for an ATM switch that contains more than a million lines of code, runs uninterrupted for twenty years straight, and scales from 10gbit to 160gbit sufficiently complex for you?
(Not to mention that said software isn't available for public scrutiny, and as such I have to take the assertion that it is bulletproof with a grain of salt. I mean, even NASA has had braindead-stupid moments (failing to convert units properly? A casting error? Running out of space on the filesystem?)))
Now you appear to refuse to consider any examples that demonstrate the in-correctness of your claim. Why?
Would you care to amend your claim to restrict it only to JavaScript engines shipping in free-to-use web browsers?
What was meant was "for each <thing X that is done by complex software>, <a piece of software S> doing X correctly is improbable enough that the existence of any piece of software doing X correctly may be considered to be impossible unless there is a piece of software that hasn't been shown to do X incorrectly".
What was taken was "for each <thing X that is done by complex software>, <a piece of software S> doing X correctly is improbable enough that the existence of any piece of software doing X correctly may be considered to be impossible unless there is a piece of software that hasn't been shown to do <any thing Y that is done by complex software> incorrectly".
An important distinction.
Hopefully this makes things clearer.
Here's the thing:
Problems in software are productively classed by their complexity and difficulty. That is to say that if you have two tasks, each of equivalent complexity and difficulty, the software to solve one task is going to be just as expensive to write as the software to solve the other one. [0]
I argue that designing and writing the software system required to run a piece of high-traffic, high-performance, near-zero-downtime networking gear that actually meets its goals [1] is in the same class of difficulty as writing a performant JS engine that has no "exploitable bugs". [3]
[0] For the purposes of this discussion, the cost to write any software used as part of the solution to either task must be included in the analysis of the overall cost.
[1] If you don't consider the existence of at least one production instance of this system being in continuous use for a decade or more proof of its correct design and implementation, I really don't know what else would convince you. You're highly unlikely to be able to evaluate the correctness of the system via manual inspection. [2]
[2] I mean, if you were one of the handful of mutants in existence who could do this, you'd likely not be wasting time arguing on HN.
[3] Actually, for giggles, can you point to a handful of somewhat recent High or Critical severity CVEs for V8 when used in Chrome or Chromium? Remember that you've been laser-focused on the Javascript engine, so failures of things like the browser's sandbox, browser's chrome, or OS process isolation don't count.
(As for the V8 engine, see https://code.google.com/p/chromium/issues/list?can=1&q=Type=.... (Note that Google does not make severe recent bugs publicly available.))
If you're currently starting your career in software, you're sure to -one day- consider the topic in the same way that I do. It's the only rational way to think about it.
Regardless of how you think about the comparability of software complexity between software projects, your statement about the near-impossibility of creating correct complex software was a gross overstatement; one that you're still not owning up to. :)
That bug list is not a list of CVEs. What's more, it's a list of bugs for the entire Chromium project. I assume that you couldn't find any CVEs that only affected V8 the JS engine, as used in Chrome or Chromium. Their absence shoots a really big hole in the foundation of your primary claim, which was: "[There exists no] functional browser that doesn't have bunches and bunches of exploitable bugs in its JS engine.".
Secondly, now that you have actually done that, you'll note I did not said JITters are inherently insecure. I said that "Trying to write a language that is compiled / JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure". And the reason is simple. By the time you take a powerful language and add the optimizations necessary to make it be executed quickly, your execution engine becomes complex. (For instance, the v8 engine is, what, 1.4 million lines of code? And the SpiderMonkey engine is over half a million?) And because you need the engine to compile / JIT quickly, you end up writing code that takes advantage of "bare-metal" features. And as such, you have a nasty combination of an absurd amount of code, most of which is "unsafe" (to use the Rust parlance). And from there, simple probability dictates that you will have bugs, and you will have exploitable bugs.
Now, is this inherent to JS engines? No. You could, in theory, have a JS engine written in a language that checks the code for you. As you said, Erlang, or whatever. However, that is a moot point. Because there is not a single functional browser that uses a JITter that doesn't have these problems.
And as such, here's a good reason, albeit not a technical one: precedent. I am not so... hubristic, shall I say, to assume that even though every current major browser has a large chunk, if not the majority, of exploitable bugs be in the JS engine, that the next one will be any different.
I can hope, but I will not rely on it. Especially not as I am talking about now, not some potentially-mythical time in the future.
And no, I cannot give you a technical reason. Because I suspect that the moment anyone figures out said technical reason, they will be able to design a language and/or engine that doesn't have said reason.