First off, kindly reread what I actually said, as opposed to what you skimmed :)<p>Secondly, now that you have actually done that, you&#x27;ll note I did not said JITters are inherently insecure. I said that &quot;Trying to write a language that is compiled &#x2F; JITted quickly, is executed quickly, is powerful, and is secure, is doomed to failure&quot;. 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 <i>million</i> lines of code? And the SpiderMonkey engine is over half a million?) And because you need the engine to compile &#x2F; JIT quickly, you end up writing code that takes advantage of &quot;bare-metal&quot; features. And as such, you have a nasty combination of an absurd amount of code, most of which is &quot;unsafe&quot; (to use the Rust parlance). And from there, simple probability dictates that you will have bugs, and you will have exploitable bugs.<p>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&#x27;t have these problems.<p>And as such, here&#x27;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.<p>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.<p>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&#x2F;or engine that doesn&#x27;t have said reason.